Nova Address Field Laravel Package

Product Decisions This Supports

• Build vs. buy for internal tooling. This is a thin, single-purpose Nova field that wraps Google Places Autocomplete into an address form input. The realistic "buy" decision is trivial in cost but non-trivial in maintenance: it replaces perhaps 1–3 days of front-end work in Nova, but it is a 2019 artifact (v1-era Nova, last release April 2019, ~10 stars, effectively a single-maintainer side project). Treat it as a reference implementation to fork or copy, not a dependency to composer require.
• Admin-first vs. customer-facing address capture. The package only helps where the address is entered by an internal operator inside Nova (ops, sales, logistics, back-office onboarding). It says nothing about checkout or signup UX. The PM decision it informs is: where do we invest in address quality first? Usually the answer is the back office, where a handful of staff create the bulk of records that downstream systems depend on.
• Standardizing address data shape. It nudges toward storing an address as discrete components (line 1/2, city, region, postcode, country, lat/lng, place ID) rather than one free-text blob. That is a schema and reporting decision with long tails: geocoding, territory assignment, deduplication, shipping-rate lookup, and CRM sync all get easier. Make this call deliberately — a field like this quietly sets the precedent.
• Roadmap input for the internal admin surface. If address entry is a recurring friction point in ops workflows, the roadmap item is "reduce manual data entry and keying errors in Nova," and this package is one candidate spike. If it's a one-off, it's a 30-minute form tweak, not a roadmap item.
• Use cases that justify evaluation: CRM/lead records with physical locations, delivery or service-address capture for field ops, vendor/customer onboarding forms, territory or region assignment, and any workflow where a human currently copy-pastes addresses from Google Maps.
• Vendor and compliance decision. Google Places terms constrain how long you may cache or store Places-derived data (place ID is durable; other components are not, in the general case). Because the field writes address components straight into your database, adopting it is implicitly a data-retention and licensing decision — the PM should own that, not leave it to whoever writes the migration.

When to Consider This Package

Consider it when:

• You are on Laravel Nova 1.x/2.x (or are willing to fork and port — Nova 3/4/5 changed the field and asset pipeline materially, so a straight install will likely not work on modern Nova).
• Address entry happens exclusively in the admin panel, by trained staff, at low-to-moderate volume.
• You already have a Google Cloud project, a Places API key, and a billing relationship — and you're comfortable with per-keystroke Places billing and quota management.
• The alternative is no autocomplete at all and the status quo is manual keying with visible error rates.
• You have engineering capacity to own a fork: pin it, read the ~few hundred lines, add your API key handling server-side, and add tests. It is small enough that forking is genuinely cheap.
• Accuracy of the selection matters more than validation — i.e., you want the operator to pick the right real-world place, not to enforce postal standards.

Look elsewhere when:

• You're on Nova 3+. The maintenance signal here (no release since April 2019, tiny install base) means you should assume it's dead and budget a port or pick a maintained alternative.
• You need structured parsing, validation, normalization, or deduplication of addresses (libpostal, Loqate, Smarty, Google Address Validation API). This field gives you a picker, not data quality.
• You need address capture on a customer-facing surface — use a JS autocomplete widget directly; a Nova field is the wrong layer.
• You have compliance or data-residency constraints (GDPR, PII retention, on-prem), or need an address provider other than Google (Mapbox, HERE, Pelias/self-hosted).
• Your volume makes Places billing material and you haven't modeled cost per record created.
• You need a supported dependency with a security-response path — 10 stars and one maintainer is a bus-factor of one.

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source add-on for our internal admin panel that lets staff pick a real address from Google instead of typing it. The upside is faster data entry and fewer bad addresses flowing into CRM, shipping, and reporting — a modest but real operational win, typically days of engineering rather than weeks. The caveat is that it's an unmaintained 2019 project, so the honest framing is "we're reusing a small piece of open-source code as a starting point, and our engineers will own it," not "we're adopting a vendor." Cost is limited to Google Places API usage, which should be metered. Recommendation: evaluate as a spike against our current Nova version, expect to fork, and gate adoption on a cost estimate for Places calls plus a decision on how long we retain Google-derived address components. If it doesn't port cleanly in a day, we build the small equivalent ourselves.

To engineering: It's a Nova field wrapping Google Places Autocomplete — tiny surface area, but frozen at the Nova 1/2 era, so treat it as a code sample rather than a package. Concrete asks: (1) timebox a spike porting it to our Nova version; (2) move the API key server-side and proxy the Places call rather than exposing it to the browser; (3) store place_id alongside components and define a retention policy consistent with Google's caching terms; (4) if the port exceeds roughly a day, build in-house — the field is a few hundred lines and we'd rather own it. Don't add it as an unpinned dependency in a production composer.json.