Product Decisions This Supports
- Admin-side address capture (feature-level). This package adds a Google Maps-backed field to Laravel Nova resources, so operators can pick or verify an address on a map (pin placement, geocoded coordinates) instead of typing free-text. It supports features like store/branch locators, delivery-zone setup, property or asset records, and customer onboarding forms inside the Nova admin.
- Build vs. buy for internal tooling. The scope is narrow — a single Nova field wrapping the Google Maps JS API. It is a "buy (free) or clone in an afternoon" decision, not an architectural one. The real cost is not the package; it is the Google Maps API key, billing account, and the ongoing compatibility surface with Nova majors.
- Roadmap input for geo features. If geospatial data (lat/lng, place IDs, formatted addresses) is on the roadmap for internal ops tooling, this is a cheap way to validate the workflow before committing to a schema or a paid geocoding provider. Treat it as a prototype enabler, not a platform dependency.
- Data-model decision. Adopting it forces a stance on what gets persisted: a single free-text address column, or discrete lat/lng/place_id fields. The latter is what makes later features (radius search, map clustering, routing) possible, so this choice should be made deliberately even if the field itself is swapped out later.
When to Consider This Package
Consider it when all of the following hold:
- The application is on Laravel Nova and the need is limited to an admin/back-office form field. It has no value outside Nova.
- You already have (or will provision) a Google Maps JavaScript API key with billing enabled; without it the field renders nothing useful, and key restrictions/quotas become a product-ops concern.
- You are comfortable vendoring or forking: 3 stars, 0 dependents, and a single maintainer mean you should assume no support SLA. Read the source (it should be small), pin a version, and be ready to own it.
- You need a fast pilot and the alternative is weeks of custom Nova field work. For a two-week validation of a locator feature, this is a reasonable shortcut.
Look elsewhere (or build in-house) when:
- The address capture is customer-facing or revenue-critical. A near-zero-adoption package is not a defensible dependency for anything with uptime expectations.
- You need non-Google providers (Mapbox, OpenStreetMap/Leaflet, Here) — cost, licensing, or regional coverage often rules Google out, and this package is Google-only.
- You need server-side geocoding, batch address validation, or routing — this is a UI field, not a geocoding service.
- Nova major-version churn is a concern. Small Nova field packages commonly lag behind Nova releases; verify compatibility against your pinned Nova version before committing, and assume you will patch it yourself on the next upgrade.
- Your team has no appetite to own a fork. With this adoption profile, "we'll maintain it ourselves" is the actual contract.
How to Pitch It (Stakeholders)
For executives: This is a free, MIT-licensed add-on that lets our internal admin team pick addresses on a map instead of typing them — useful for store locators, delivery zones, or asset records. The package cost is zero, but adoption is very low (3 stars, no downstream dependents, single maintainer), so we should treat it as a pilot, not a foundation. The only real spend is a Google Maps API key with billing enabled, which we would need for any map feature regardless of package. Recommendation: use it to prototype the workflow behind a feature flag, keep the integration isolated, and budget roughly a day of engineering to fork and own it if the feature graduates.
For engineering: Small Nova field wrapping the Google Maps JS API, MIT licensed, trivially readable and forkable. Pin the version, vendor it into our repo, and wrap it behind our own field class so the dependency is a one-file swap. Two hard prerequisites: a restricted Google Maps API key (HTTP-referrer and API restrictions, quota alarms) and explicit verification against our Nova major version, since packages this small typically do not track Nova upgrades. Do not let it define our address schema — decide lat/lng/place_id persistence independently so a future swap to Mapbox or in-house is a field change, not a migration.