Nova Google Autocomplete Field Laravel Package

Product Decisions This Supports

• Admin-side address capture quality. It solves a narrowly scoped, real problem: replacing free-text address entry in a Laravel Nova admin panel with Google Places autocomplete plus structured metadata (street components, city, region, postal code, country, lat/lng). The product value is fewer keying errors, cleaner downstream records, and geocodes available without a second pass.
• Feature vs. tooling distinction. This is back-office tooling, not a customer-facing capability. It supports decisions like "how do ops enter orders/customers/shipments?" — not "what does our checkout address form look like?"
• Build vs. buy, reframed. The honest framing is not "adopt this package or write code." It is a two-part decision: (a) Google Places as the address data source, and (b) whether to own ~100 lines of Nova field glue ourselves. The package is a shortcut on (b); it does not reduce the strategic weight of (a).
• Roadmap placement. Best treated as a spike/prototype enabler with a short half-life. Because it is archived, the durable roadmap item is "own an internal address-autocomplete field," with this repo as a starting reference implementation.
• Use cases worth validating: order entry and dispatch, customer onboarding, shipping/billing normalization, territory or distance logic that needs coordinates, and any workflow where bad addresses create rework (failed deliveries, duplicate accounts).
• Data governance decisions it forces early: whether place data may be stored, for how long, and where the API key lives. These are policy decisions, not implementation details, and they usually outlast the package itself.

When to Consider This Package

Consider it when:

• You are already on Laravel Nova and want address autocomplete working in days, not sprints.
• The surface is internal and admin-only — low traffic, low blast radius, reversible.
• You are willing to fork it and accept ownership; treat the repo as source material rather than a dependency.
• Google Places billing, quota, and key restriction are already set up and the per-request cost is quantified against expected admin volume.
• Your legal review confirms the Places terms permit your intended caching/storage of returned metadata.

Look elsewhere when:

• Maintenance risk is disqualifying. 20 stars and an archived state mean no security patches and no guarantee of compatibility with future Nova majors. If a Nova upgrade is on the roadmap, this becomes a migration liability.
• You need customer-facing or high-QPS autocomplete. Use Google's own Places widget or a maintained JS component; a Nova field is the wrong layer.
• Vendor portability matters. Swapping geocoders later means re-implementing the field and re-checking storage terms — budget for that.
• You need true address validation (deliverability, standardized postal formats, correction of ambiguous input), not just suggestion-and-fill. That is a different vendor category.
• You are in an audited or compliance-scoped environment where an unmaintained third-party dependency with an embedded API key path fails review.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source add-on that gives our admin team address autocomplete, which reduces data-entry errors and gives us clean, structured addresses and coordinates. The package itself costs nothing and can be trialed in a week, but it is archived and has almost no community around it — so it should be treated as a prototype or a code reference we fork and own, not a long-term dependency. The actual recurring cost and the real lock-in sit with Google Places API usage, not with this code. Recommendation: run a short, contained spike, quantify Places spend against admin volume, and decide on a fork-or-reimplement path before anything depends on it.

For engineering (short): A thin Nova field wrapping the Google Places API and returning full address metadata. No lock-in at the PHP layer, meaningful lock-in at the API layer via Google's caching and storage terms. The repo is archived with 20 stars, so plan for ownership: either fork it or spend a couple of days writing an equivalent. Watch Nova version pinning, prefer proxying requests server-side or tightly restricting the browser key, and confirm how much of the returned place payload we are permitted to persist before designing the schema around it.