Filament Leaflet Map Picker Laravel Package

Product Decisions This Supports

• Shipping geo-capture without a geo roadmap. Any feature that needs "put a pin on a map and save it" — store/asset locators, service-area or delivery-zone setup, property and listing records, field-service job sites, event venues, CRM account addresses — can reuse one form field instead of a bespoke map build. That converts a recurring 3–5 day build into roughly half a day of integration.
• Build vs. buy for admin-side mapping. The scope is deliberately narrow: one point, stored as coordinates, inside a Filament form. Because it is a thin wrapper over Leaflet (MIT, small surface area), the honest comparison is not "buy a mapping platform" but "buy ~2–4 engineer-days now vs. own ~300 lines forever." For internal tooling this is usually a clear buy; for a customer-facing map it is the wrong tool entirely.
• Scoping the data model. Adopting it forces the useful question early: are coordinates first-class fields on the entity, or derived from an address? Storing lat/lng unlocks later roadmap items (radius/proximity filters, nearest-location sort, heatmaps) at near-zero cost; treating the map as a UI nicety locks you out of all of them.
• Deferring the expensive geo features. The package covers capture, not search. Address autocomplete/geocoding, reverse geocoding, polygons and route drawing are separate decisions with separate vendor costs. It lets you ship capture now and sequence geocoding as its own roadmap item with its own budget line.
• Consistency across the admin surface. Standardising on one picker avoids each squad hand-rolling a slightly different map widget with a different tile provider, a different coordinate format, and a different set of validation rules.

When to Consider This Package

Adopt when:

• The product/stack is already on Filament — otherwise the component is unusable and you are only buying inspiration.
• The need is internal or back-office: an operator drops or drags a pin and saves one location. No consumer-facing map UX, no SEO/location pages.
• The requirement is coordinates only — no polygons, no multi-stop routes, no drawn service boundaries, no clustering of thousands of markers.
• Time-to-market dominates. A working field this sprint beats a bespoke one next sprint.
• You are comfortable with vendor risk being mitigated by forkability: MIT, small codebase, so the failure mode is "we vendor it" rather than "we are blocked." Note the signals — 40 stars and a single maintainer — and treat them as a diligence flag, not a disqualifier, precisely because replacement cost is low.
• Filament major-version upgrades are tracked. Filament moves quickly; the real ongoing cost is re-testing this component on each Filament bump, not the initial install.

Look elsewhere when:

• You need address search or reverse ge ocoding in the same control — budget for a geocoding vendor (Mapbox, Google, Nominatim with its usage policy) rather than expecting the picker to cover it.
• You need drawing tools (polygons, radii, routes) or many points per record — evaluate a dedicated mapping library or a hosted map SDK.
• It is customer-facing — this is a form component; it is not a public store-locator UI.
• You have strict accessibility, offline/air-gapped, or data-residency requirements. Tile servers receive end-user IPs and requests; that is a privacy/GDPR and network-egress decision you must make explicitly, including tile-provider licensing, attribution obligations, and rate limits (default OpenStreetMap tiles are not a production SLA).
• You need commercial support or an SLA, or your procurement rules bar single-maintainer dependencies in business-critical paths.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT-licensed) component that lets our admin users pick a location on a map and save it, instead of typing coordinates by hand or us paying for a mapping platform. It compresses a recurring multi-day build into roughly half a day per feature and creates the coordinate data we would need later for "nearest to me" and territory features. The risk is deliberately low: it is a thin layer over an open-source map library, so if the maintainer walks away we can absorb the code ourselves at modest cost. Recommended posture: adopt for internal tooling, keep it behind our own form-field abstraction so it stays swappable, and treat tile-provider terms as a separate, explicit decision.

To engineering: Use it as the default geo input in Filament forms; wrap it in a single project-owned field class so upgrades and any future replacement happen in one place. Validate coordinate bounds server-side and store lat/lng as decimals with an explicit coordinate system assumption. Please surface the tile-provider choice (and its attribution, rate-limit and privacy implications) as a config decision, not a hard-coded default, and add a test that the field round-trips coordinates on Filament major upgrades.