How to Add Maps to an AI-Built App
The map itself is the easy part. Tiles, geocoding and autocomplete price separately, and the free tier you were promised usually applies to only one of them.
Ask an AI app builder for a map and you will get one in about a minute. It will render, it will have pins, and it will work in the demo. The problems arrive later and all of them are commercial: map tiles, geocoding, autocomplete and directions are four separately metered products, the generous free tier usually covers one of them, and the licence on the tiles you are rendering may not permit what you are doing. Here is the version that survives contact with real traffic.
The four things people call a map
Component | What it does | Typical metering |
|---|---|---|
Tiles or vector basemap | Draws the map itself | Per map load or per tile request |
Geocoding | Turns an address into coordinates | Per request, often the priciest line |
Autocomplete | Suggests addresses while typing | Per keystroke session, not per result |
Directions and matrix | Routes and travel times | Per route, and matrix pricing scales badly |
The autocomplete row is where the surprise usually is. A user typing an address generates a session, not a request, and implementations that fire on every keystroke without a session token can multiply the cost of that one field by a factor most people never check.
Pick the licence before you pick the library
Two decisions that are hard to reverse later:
Can you cache geocoding results? Several major providers forbid storing coordinates you got from their geocoder beyond a short window. If you geocode 50,000 customer addresses once and store them, check the terms first, because that pattern is explicitly prohibited by some and explicitly fine with others.
Can you use the basemap outside their SDK? Rendering a provider's tiles inside a different map library breaks the terms for some providers. This is the most common accidental violation in AI-generated code, because the model will happily wire a tile URL into whatever library it picked first.
Neither of these produces an error message. They produce a letter, months later.
The pattern that keeps costs flat
Geocode once, at write time, and never at read time.
When a record with an address is created or edited, geocode it and store latitude and longitude on the row.
Serve every map view from the stored coordinates. No geocoding on page load, ever.
Re-geocode only when the address field changes. A cheap dirty-check on the address string is enough.
Cache autocomplete sessions properly, with a session token, so a user typing 30 characters is billed as one interaction rather than thirty.
This turns geocoding from a traffic-proportional cost into a data-proportional one, which is the difference between a bill that grows with users and a bill that grows with rows. The same instinct applies across the board in how to reduce AI API costs.
Radius search without PostGIS
The most common map feature is "show me things near here", and you do not need a spatial extension for it at small scale. Stored coordinates plus the haversine formula in plain SQL will comfortably handle tens of thousands of rows:
select id, name, lat, lng,
6371 * acos(
least(1.0,
cos(radians($1)) * cos(radians(lat)) *
cos(radians(lng) - radians($2)) +
sin(radians($1)) * sin(radians(lat))
)
) as km
from places
where lat between $1 - ($3 / 111.0)
and $1 + ($3 / 111.0)
and lng between $2 - ($3 / (111.0 * cos(radians($1))))
and $2 + ($3 / (111.0 * cos(radians($1))))
order by km
limit 50;Two details AI-generated versions of this usually miss. The least(1.0, ...) guard stops floating point error from pushing the argument above 1 and making acos return null for a point compared against itself. The bounding box in the where clause is what lets the query use an index on lat and lng; without it you compute a distance for every row in the table. Add a composite index on those two columns and this stays fast well past the point where you should have moved to PostGIS anyway.
If you are still choosing where this data lives, how to choose a database for an AI-built app covers the tradeoffs, and how to add search to an AI-built app covers the sibling problem of text search over the same rows.
What to tell the builder
Prompts that produce a maintainable result rather than a demo:
Name the provider and the exact library, so the model does not mix a tile source from one with an SDK from another.
Say explicitly that coordinates are stored on the record and geocoding happens only on write.
Ask for the autocomplete session token by name. Models omit it unless prompted, because the simple example in the docs omits it too.
Require a fallback render when the map fails to load. A blank grey rectangle with no error is the default behaviour and it looks like a broken app.
For the wider build, see how to build an app with AI and the running costs breakdown in how much does it cost to run an AI-built app.
Frequently asked questions
Is there a genuinely free option?
Open basemaps exist and are viable, with attribution requirements and usage policies you must actually read. The tile hosting is the part that is rarely free at volume, even when the data is.
How accurate is storing coordinates as plain numbers?
Six decimal places gives roughly 11 centimetres, which is far more precision than any consumer geocoder provides. Double precision columns are fine.
When should I move to PostGIS?
When you need polygons, real spatial indexes, or distance queries over hundreds of thousands of rows. Below that the query above is simpler and fast enough.
Do I need a map at all?
Often not. A sorted distance list answers "what is near me" for most users, costs nothing to render, and works better on a phone. Add the map when someone asks for it.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
