Product Decisions This Supports
- Roadmap enablement for location-based features. If the roadmap includes anything that needs a stored point on a record — store locator entries, service/delivery zones, property and listing addresses, field-service job sites, event venues — this field is the cheapest way to let ops staff capture that coordinate in the Nova admin without a custom build.
- Build vs. buy on internal tooling. The realistic alternative is a custom Nova field (~1–2 dev days plus review) or a different community field. This package makes "buy" (i.e., install) the default for a narrow, well-understood UI need: click a map, persist lat/lng.
- Scope calibration: single point vs. geo platform. Adopting this implicitly scopes the feature to point capture, not geocoding/address search, polygon drawing, multi-stop routing, or distance queries. That is a legitimate MVP scope decision — but it should be made deliberately, because teams often assume "map field" means "address search," and this is not that.
- Data model commitment. It pushes toward two nullable numeric columns (latitude/longitude) on the resource table. Cheap now, mildly annoying to migrate later if you move to PostGIS geometry columns for radius queries — worth flagging before schema sign-off.
- Dependency governance / maintenance posture. With a last release in 2020 and a small star count, adopting it is a decision to accept an unmaintained dependency in the admin layer. That is a defensible call for a back-office convenience feature and an indefensible one for anything customer-facing.
When to Consider This Package
Consider it when all of the following hold:
- You are on Laravel Nova, and on a version the field's 2020-era code actually supports — verify against your Nova major version before anything else. Nova's field API has moved since; a broken field in the admin is a support ticket, not a feature.
- The need is internal and low-stakes: an operator picks a location by hand, a handful of times a day, on a resource that already exists.
- A single coordinate is genuinely sufficient. No geocoding from a typed address, no reverse lookup to display a street address, no radius queries, no polylines or polygons.
- You already have (or will accept) a Google Maps API key and its billing/quota implications — map provider dependencies and their cost model should be an explicit line item, not a surprise on the first invoice.
- You can absorb the risk of an unmaintained dependency: pin the version, isolate usage to one or two resources, and accept that a Nova upgrade may force a fork or replacement.
Look elsewhere when:
- The requirement includes address search/geocoding, autocomplete, or reverse geocoding — the map field alone will not deliver the UX stakeholders picture, and you will end up building the rest anyway.
- You need geometry beyond a point: service-area polygons, routes, clustering, distance filtering. This is a geo-platform conversation, not a field-install conversation.
- You are on a recent Nova major and the field is incompatible out of the box — the migration cost then equals or exceeds writing a thin custom field, which you would own and could maintain.
- The mapping is customer-facing or business-critical (pricing by zone, dispatch). Unmaintained code in a revenue path is not a trade worth 113 stars.
- You are not on Nova at all — the package has no value outside that ecosystem; treat any "let's use this" suggestion as a signal the team may be conflating it with general Laravel mapping libraries.
A pragmatic middle path: timebox a spike, confirm it renders and saves on your Nova version, and if it fails, fall back to a custom field. Either way the decision is a day, not a sprint.
How to Pitch It (Stakeholders)
For executives — one paragraph: This is a small, free admin-panel component that lets our operations team drop a pin on a map to store a location against a record. It unlocks the location-based items on the roadmap at roughly zero build cost instead of a one-to-two-day custom build, and it is confined to the internal back office — customers never see it. The trade-off is that the package has not been updated since 2020 and has a small user base, so treat it as a tactical accelerator, not a platform bet: it is cheap to adopt, cheap to replace, and should not be allowed to become load-bearing for anything revenue-critical. Recommended decision: pilot it on one low-risk resource, with a one-day timebox and a documented fallback to a custom field. If it works, we save the build; if not, we have lost a day and learned something about our Nova version.
For engineering — the short version: Nova map field, single lat/lng point, Google Maps key required, last release 2020, ~113 stars. Compatibility with our Nova major is the gating question — verify it before we plan around it. Keep the blast radius to one or two resources, pin the version, and assume we may need to fork or replace on the next Nova upgrade. If the requirement grows to geocoding or radius search, stop and re-scope: that is a different project and this package is not the foundation for it.