Google Map Laravel Package

Product Decisions This Supports

• Build vs. buy for internal location capture. Any roadmap item that needs an operator to pick a real-world place — store/warehouse onboarding, event venues, property listings, delivery zones, field-service dispatch — currently implies a custom Nova field: Google Maps JS embed, Places autocomplete, lat/lng hydration, validation, and error states. This package collapses that into a composer require plus a field definition in the Nova resource. That is roughly 1–2 engineering weeks (plus ongoing maintenance of custom JS) traded for an afternoon of integration.
• Unblocking operations tooling without backend scope creep. The data model impact is just nullable address, latitude, longitude columns. That means geo-capture can be added to an existing admin resource as a low-risk slice rather than a schema-heavy epic, which makes it a good candidate for a "quick win" slot in a sprint or a between-epics filler.
• Roadmap sequencing for geo features. This is an enabler, not a feature. Adopting it early lets you validate demand for location-based capabilities (radius search, nearest-branch routing, territory assignment) using admin-entered data before committing to a geospatial backend (PostGIS, spatial indexes, geocoding services). Cheap way to test the hypothesis before the expensive build.
• Vendor and cost decisions. It forces an explicit decision on Google Maps Platform as a dependency: API key provisioning, billing account, quota alerts, and ToS review (caching/attribution rules). That's a decision the PM should own, not discover at launch. It also creates a clean seam — because the field is MIT and isolated to the admin layer, replacing Google with Mapbox or a self-hosted geocoder later is a contained change, not a rewrite.
• Prioritization signal on adoption risk. 8 stars and 0 dependents mean this is a convenience, not an ecosystem standard. That should not block adoption, but it should shape how you adopt it: pin the version, and treat the source as forkable in-house.

When to Consider This Package

Consider it when all of the following hold:

• You are on Laravel Nova 4 or 5 — this is an admin-panel field and does nothing outside Nova.
• The requirement is operator-entered location in the back office, not a customer-facing map, store locator, or live tracking UI.
• You need address text and coordinates together (Places autocomplete gives you both, which is the real value over a plain text field).
• You have, or can quickly get, a Google Maps Platform API key with billing enabled — the field is a thin wrapper; the cost, quota, and terms exposure is Google's.
• Your team lacks spare frontend capacity and the alternative is a bespoke Vue field inside Nova.
• Low bus factor is acceptable because MIT licensing lets you fork and own the ~few-hundred-line field if the maintainer disappears. The release history is current, which is a positive signal, but 8 stars is not a support contract.

Look elsewhere when:

• You are not on Nova. If the admin panel is Filament, plain Blade/Livewire, or a separate SPA, this is irrelevant — use the Google Maps JS API directly or a framework-native component.
• The map is customer-facing. This is an input widget; it does not give you rendering, clustering, or performance for public traffic.
• Privacy, residency, or cost rules out Google. GDPR-sensitive address data, on-prem requirements, or Maps Platform pricing at scale point to self-hosted geocoding (Nominatim/Pelias) or Mapbox — different package, different tradeoffs.
• You need real geospatial queries. This stores coordinates; it does not give you proximity search, polygon containment, or spatial indexing. If those are the actual requirement, the build is PostGIS + a search layer, and the field is the trivial last mile.
• A single-maintainer, near-zero-adoption dependency fails your supply-chain policy. Then copy the field into your codebase under MIT and own it — don't skip the capability, just skip the dependency.

How to Pitch It (Stakeholders)

For executives: This is a small, free (MIT) admin-panel component that lets our operations team type an address and have the map and coordinates filled in automatically. It replaces roughly one to two weeks of custom engineering on a capability that at least one roadmap item depends on, at effectively zero licence cost. The only real commitment is a Google Maps Platform billing account, which we would need for any location feature regardless — and because the code is MIT and lives only in the admin layer, we are not locked in; if Google becomes expensive or non-compliant, swapping the provider is a contained change. Recommend approving it as a contained pilot behind a version pin, with the caveat that it is a small open-source project, so we should be prepared to fork it internally if it goes unmaintained.

For engineering: Drop-in Nova field for v4/v5 using Places autocomplete. Integration is a field declaration plus three nullable columns; no custom Vue, no custom JS build step. Two things to own on our side: API key and quota management (restrict the key by HTTP referrer, set billing alerts), and a deliberate decision on where we store the geocoded result versus re-querying Google — the latter has cost and ToS implications. Pin the version in composer and review on each Nova major upgrade; the dependency is thin enough that forking it into app/Nova/Fields is a reasonable fallback if upstream stalls. Do not extend this to public-facing surfaces without a separate design and caching discussion.