Product Decisions This Supports
- "Near me" roadmap feature: this package lets you evaluate and ship proximity search as a scoped feature rather than a platform project — a trait on an Eloquent model gives you radius filtering and distance ordering without PostGIS, a search cluster, or new infrastructure. That changes the effort line in a roadmap conversation from weeks to roughly a day.
- Build vs. buy vs. defer: it gives you a legitimate cheap third option alongside "stand up PostGIS / MySQL 8 spatial indexes" and "buy an Algolia or Meilisearch geo tier." Useful input to a cost comparison where the expensive options are hard to justify before you have usage data.
- Scope negotiation: because the package's ambition stops at radius + sort by distance, it's a clean forcing function. If the ask includes polygons, geofences, delivery routes, isochrones, or geo combined with full-text relevance ranking, that's a signal the requirement is a search-platform initiative, not a sprint ticket — and the package tells you that early and cheaply.
- Discovery validation: good enough to test whether users actually use distance sorting before you commit to a platform. Instrument the feature, measure adoption for a quarter, then make the invest/don't-invest call with data.
- Data-model/portability decision: separate indexed lat/lng decimal columns keep you portable across MySQL, MariaDB, and SQLite (tests, single-tenant deploys) instead of locking you to a Postgres geography type.
- Adjacent pricing/logistics decisions: service-area gating, delivery-radius tiers, and shipping estimates all reuse the same primitive, so the marginal cost of the second and third use case is near zero.
When to Consider This Package
Adopt it when:
- Your dataset is modest and read-heavy relative to writes — low hundreds of thousands of rows or fewer — where an indexed bounding-box prefilter plus distance ordering is sufficient.
- You're on MySQL/MariaDB and don't want the ops burden of a spatial extension or a separate search service.
- The requirement is literally "within X km of a point, ordered by distance, paginated."
- You're prototyping, or location is a low-stakes differentiator rather than core to the product.
- You have Laravel-capable engineers willing to pin a version, fork if needed, and own the dependency.
Look elsewhere when:
- Maintenance reality: last release was April 2021 and the project has ~41 stars. Laravel 10/11 compatibility, PHP 8.x support, and any CVE response are on you. Validate against your target framework before it enters a sprint; assume a fork.
- You need polygons, geofences, routes, isochrones, or geo plus faceted/full-text ranking — that's PostGIS, Meilisearch/Typesense, Algolia, or Elasticsearch.
- Write throughput or geo-index churn is high, or you operate globally where bounding-box math near poles and the antimeridian needs care.
- You require vendor SLAs, security policy, or a maintainer to escalate to.
- Your team has no appetite for owning a dependency that may not survive your next Laravel major.
Adoption gates I'd actually enforce: (1) a maintained fork or a written exit plan behind an interface; (2) a composite index on lat/lng with a tested bounding-box prefilter; (3) a benchmark at your real row count and expected QPS; (4) distance units and pagination behavior written into acceptance criteria.
How to Pitch It (Stakeholders)
For executives: we can validate "find locations near me" — a recurring customer ask and a differentiator in our category — for roughly a day of engineering instead of a platform project. It's MIT-licensed, adds no infrastructure, and ships behind a feature flag with a usage metric attached. Recommendation: use it to prove demand this quarter, then decide with data whether a real geo/search platform is worth funding.
For engineering: it's a small Eloquent trait providing radius scopes over indexed latitude/longitude columns with bounding-box prefiltering and distance ordering — no PostGIS, no search cluster, works with our existing MySQL and SQLite test suite. Be explicit about the caveat: ~40 stars, no release since April 2021, so we treat it as vendored code we own. We wrap it behind a LocationSearch interface so a PostGIS or Meilisearch implementation is a drop-in replacement later, and we own version bumps and patches.
The ask: one engineering day, a feature flag, and one adoption metric. Decision point at end of quarter — keep, replace, or remove.