Nova Map Marker Field Laravel Package

Product Decisions This Supports

• Sequencing geo-capture ahead of geo-intelligence. The most common roadmap temptation is to scope "location support" as a program (geocoding, distance search, service-area polygons, routing). This field is the cheapest possible first slice: ops picks a point, the record stores it. It lets you ship "we can record where things are" in days, then defer geocoding, geofencing, clustering, and proximity search until a concrete user story justifies them. Frame the decision as capture now, discovery later — and be explicit that later is a separate roadmap line item, not an implied follow-on.
• Turning a build-vs-buy question into a fork-vs-build question. Because the package is archived, last released 2022-06-17, has 128 stars and zero dependents, "adopt a dependency" is not actually on the table. The real options are (a) fork and own it under MIT, or (b) rebuild a native Nova field in roughly 2–5 dev days. Pricing that honestly — including the maintenance tail — is the product decision. The 8.53 opportunity score against abandoned supply is a demand signal, not a supply recommendation.
• Committing to a single-point data model. One {lat, lng} payload per record is a product statement: one location, no multi-stop itineraries, no polygons, no hierarchy of sites. That covers the bulk of back-office geo needs — store locators, asset registries, service-area tagging, CRM account addresses, field-agent check-ins — and it keeps an eventual migration to discrete decimal columns or PostGIS open without renegotiating the schema with stakeholders.
• Forcing the map-provider contract into the open. Google Maps means an API key, a billing account with a payment method, ToS acceptance, CSP and tile-usage review, and a quota ceiling. That's a procurement and legal task with lead time, not a config toggle. Surfacing it at planning time — rather than discovering a blank map in UAT — is a legitimate PM deliverable here.
• Settling the storage contract before anyone writes a migration. Documentation says latitude/longitude fields; implementation notes point to a single JSON {lat, lng} column. That distinction determines whether reporting, indexing, and a future spatial migration are cheap or a re-platform. Get a written answer before the ticket is estimated.
• Deciding location-data governance up front. Coordinates are frequently sensitive — customer home addresses, employee check-ins, property records. Introducing the field is the moment to decide who can view and edit it, whether it appears in exports, and whether it lands in the audit trail. These are far cheaper to decide before go-live than after.
• Managing downstream expectations deliberately. What ships is a click-to-place marker that saves coordinates. What does not ship: address autocomplete, "find nearest," drawing zones, multiple pins per record, or maps on the index view. Stakeholders will assume all of those unless told otherwise in writing.

When to Consider This Package

Consider it when:

• The target app is Laravel + Nova with an active license. Outside that stack the package has zero value and the evaluation ends immediately.
• The use case is internal, back-office, low blast radius — ops, sales, or support geo-tagging records they already own.
• One coordinate pair per record genuinely covers the need. Multi-pin, polygons, geofences, routing, and address search are out of scope by design, not by omission you can patch around.
• You're prepared to treat it as a reference implementation or fork candidate — pinned, vendored, owned, and smoke-tested — rather than a composer require nobody revisits.
• A Google Maps API key and billing account are already in place or can clear procurement quickly, with CSP and tile-usage terms reviewed.
• You can verify Nova version compatibility on day one against a throwaway resource, before scoping anything downstream.

Look elsewhere when:

• You run Nova 4/5 or a modern PHP/Laravel stack. Nova 4's Vue 3 migration broke many Nova 3-era fields; an archived 2022 release is unlikely to install or render cleanly, and no upstream fix is coming.
• The surface is customer-facing, compliance-regulated, or security-sensitive — PII location data, GDPR, accessibility requirements, auditability.
• You need anything beyond a single point, now or within a reasonable planning horizon.
• You want a long-lived dependency with a release cadence, CVE response, or vendor support. Budget the small native build instead; one field class, one Vue component, and a lat/lng column pair eliminate the abandonment risk permanently.
• Your team has no Nova frontend capability and no appetite to acquire it. An unowned fork of an archived package is the worst outcome — worse than not adopting.
• You can't commit a named owner and an annual review date. Without those, don't start.

How to Pitch It (Stakeholders)

To executives. This is a free, MIT-licensed map picker for our Nova admin panel: staff click a point on a map instead of hand-typing latitude and longitude, which unblocks a category of back-office work — store locators, asset registries, territory tagging. It's small and cheap. The caveat is supply, not capability: the package was archived in June 2022, has no downstream users, and nobody is patching it. So the recommendation isn't "install a library" — it's "spend a few engineering days to own a small piece of admin UI," either as a lightly forked field or a clean rebuild. Both cost a fraction of a sprint and a rounding error against the mapping-platform alternative. The decision to make now is who owns it, not whether we can afford it — and we should make it before this touches anything customer-facing or compliance-sensitive.

To engineering. A single Nova field: one PHP field class, one compiled Vue component, a service provider, and a Google Maps key. It stores one {lat, lng} payload per record — confirm whether that's a JSON column or discrete decimals before anyone estimates a migration. Architecturally shallow: no domain models, no routes, no queues, no auth changes, blast radius of one resource definition. The risk is entirely provenance — archived, last release 2022-06-17, 128 stars, zero dependents, so we'd be the only people testing it against our Nova version. Nova 4's Vue 3 migration broke most 3.x-era field packages, so a proof of concept on our exact Nova/PHP version is the first task, not the last. If it doesn't render cleanly, fork cost likely exceeds a native rebuild, and rebuilding is a credible 2–5 day job. Either way: pin versions, pin the key handling, add a CI smoke test asserting the assets resolve (the failure mode is a silent blank field, not an exception), assign a named owner, and set an annual review date. Don't pull it in transitively.

To product and ops teams. What you get: pick a location visually, save it, see it on the record. What you don't get: address search, drawing zones, multiple pins per record, or "find the nearest" queries. Those are separate roadmap items, deliberately out of scope for this slice — so please route those requests to the backlog rather than into this ticket.