Laravel Royalty Laravel Package

Product Decisions This Supports

• Feature viability and roadmap timing for location-aware capabilities. Version 1.4.0 adds Laravel 10 support, which means the package can now be adopted on a current, supported framework version rather than forcing a legacy-stack decision. This de-risks scheduling geospatial features (e.g., store/venue lookup, delivery zones, check-in maps) on the near-term roadmap.
• Build vs buy for point/geometry persistence. The ability to define a custom Point model is an extensibility signal: teams can adapt the package to existing domain models, custom casts, or schema conventions instead of forking or building point handling in-house. That shifts the calculus toward buy/adopt for standard use cases.
• Platform upgrade sequencing. If you are planning a Laravel 8→9→10 upgrade, this release removes the package as a blocker. PMs can sequence the framework upgrade and the geospatial feature work together instead of deferring one.
• Vendor/package risk posture. Laravel 7 through 10 support indicates active maintenance across the versions most teams run, lowering the "abandoned dependency" risk used in architecture reviews.
• Use cases enabled: geo search and radius filtering, mapping and visualization, logistics/territory assignment, proximity notifications, and analytics on spatial data—provided the package's core capabilities match those needs (verify before committing).

When to Consider This Package

Consider adoption when:

• Your application is on Laravel 7–10 and you need a maintained, framework-native way to work with point/geometry data rather than raw SQL spatial functions scattered through the codebase.
• You have domain-specific point semantics (custom attributes, casts, validation, or table conventions) and want to extend a Point model rather than fight an opinionated one—1.4.0's custom model support is the deciding feature here.
• You want a small, single-purpose dependency instead of a full GIS stack, and your spatial requirements are modest (points, distances, bounding boxes) rather than polygons, projections, or routing.
• You are standardizing on supported Laravel versions and treating unsupported-framework dependencies as a governance issue.

Look elsewhere when:

• You are on Laravel 11+; 1.4.0 tops out at Laravel 10, so verify forward compatibility or expect to wait for a release.
• You need advanced spatial operations (complex polygon intersection, coordinate system transforms, routing/traffic) that belong in PostGIS, a dedicated geo service, or a managed maps API.
• Your database layer is not supported by the package's spatial assumptions—confirm driver support (MySQL/PostgreSQL/SQLite) before committing.
• You require strict SLAs, commercial support, or a security review trail; treat this as a community package and plan accordingly.

How to Pitch It (Stakeholders)

For executives: This dependency has just been brought current with supported Laravel versions and made extensible enough to fit our existing data models. Adopting it lets us deliver location-based features on the current platform instead of building point/geometry handling ourselves—reducing engineering effort and long-term maintenance burden. The main caveat is that it stops at Laravel 10, so it should be treated as a near-to-mid-term decision tied to our upgrade timeline.

For engineering: 1.4.0 raises Laravel support from 7 to 10 and allows a custom Point model. That means we can integrate with our existing domain models and schema conventions instead of adapting our code to the package, and it unblocks use on our current framework version. Recommend a short spike to validate database driver support and confirm the custom model hooks cover our casting/validation needs, plus a note in the dependency register that Laravel 11 support is not yet available.