Geo Laravel Package

Product Decisions This Supports

• Location-dependent feature scoping. Address autocomplete, store/POI locator, delivery-zone and shipping-cost calculation, CRM address normalization, and "near me" search all hinge on reliable geocoding/reverse-geocoding. This package is a candidate implementation detail under those features.
• Regional go-to-market decisions. If the roadmap includes RU/CIS markets, Yandex.Geocoding is a credible local provider with strong coverage of Russian addresses and Yandex Maps ecosystem alignment. This package makes that integration cheap to prototype, which de-risks a market-entry bet.
• Build vs. buy on the client layer. The package is a thin PHP client over a hosted API — the real "buy" is the Yandex service; the package is a build-vs-adopt decision for the integration code. It saves days of Glue/PHP client work but shifts long-term maintenance onto us.
• Cost/coverage trade-off vs. Google/Mapbox. For RU-centric products, Yandex can be materially cheaper and more accurate locally than global providers, which can change unit economics for high-volume geocoding features (checkout address validation, lead routing).
• Data-quality and compliance decisions. Using a Russian provider affects where address data is processed — relevant for data-residency and privacy review, and a factor in vendor selection.
• Prioritization input. Because the library is stale (last release 2019, 0 dependents), it should be treated as a prototype enabler, not a production dependency, unless we commit to forking/vendoring. That distinction should influence whether a location feature ships this quarter or waits on a maintained integration.

When to Consider This Package

Consider it when:

• The product explicitly needs Yandex.Geocoding (RU/CIS address accuracy, Yandex Maps alignment, or pricing/terms favorable in-region).
• You are in a PHP/Laravel codebase and want a fast spike to validate a location feature before committing to a provider.
• The team accepts a thin, auditable API wrapper and is willing to vendor/fork it — the code surface is small, so patching is realistic.
• Volume or scope is modest enough that a "good enough, locally accurate" geocoder beats a globally maintained one.

Look elsewhere when:

• You need global coverage or multilingual addresses — Google Geocoding, Mapbox, HERE, or Pelias/self-hosted are stronger fits.
• You require actively maintained dependencies with current PHP/Laravel support and security patches. A 2019 release against a modern Laravel/PHP stack is a compatibility and support risk.
• You need an SLA, vendor support, or a documented upgrade path — this is a community wrapper with no dependents and no release cadence.
• You need richer geo primitives (routing, isochrones, places, matrix) — that argues for a broader provider SDK rather than a geocoding-only client.
• You can integrate the Yandex HTTP API directly with Guzzle/Laravel HTTP client in a few hours — often the lower-risk path for a single endpoint pair.

How to Pitch It (Stakeholders)

To executives: We can add location features for Russian/CIS markets — address lookup, store locator, delivery zones — using Yandex's geocoder, which is typically cheaper and more accurate for Russian addresses than global alternatives. The PHP package is MIT-licensed and saves initial integration time, but it hasn't been updated since 2019. My recommendation is to use it to validate the feature quickly, and budget a small amount of engineering to fork/vendor it if we go to production. Net: low cost to test a market-expansion hypothesis, with a known and contained maintenance cost.

To engineering: This is a thin client over the Yandex Geocoding API — easy to read and audit, but stale (2019, no dependents, no release cadence). Treat it as a reference implementation: either vendor/fork it with a pinned PHP compatibility pass, or spend a short spike reimplementing the two calls we need (forward/reverse geocode) on Laravel's HTTP client. Either way, abstract it behind our own Geocoder interface so the provider is swappable if we later need global coverage or a maintained SDK. Flag API-key handling, rate limits, caching of geocode results, and data-residency review as part of the integration.