Why OpenFreeMap?
Not Google Maps or Mapbox.

People ask this one a lot, usually from someone who already knows how to use Google Maps or Mapbox and is wondering why we did not just use them too. Fair question. Here is the honest answer.

What Google Maps and Mapbox actually cost

Both are genuinely good products. We are not here to argue otherwise. But both work the same way underneath. An API key tied to a billing account, a card that has to stay valid, and a price that climbs the more your platform actually gets used. Every map that loads, every address that gets searched, is a small transaction against that account.

A free tier exists, and it covers a demo just fine. A real fleet, tracked live, checked constantly by staff and by customers watching their own cargo, moves past that free tier fast. Once that happens, the map is not a nice extra anymore. It is running cost, and it grows with your business whether you planned for that or not.

Why that does not fit what we promised

All-in-One is a one time investment. We say that plainly, more than once, because we mean it. If the map underneath the platform quietly billed someone every month regardless, that promise would only be true on paper. We were not going to build an entire pricing model around a single payment, then hand the keys to a different company that bills you forever for something as basic as seeing your own ships on a map.

What OpenFreeMap actually is

Free, open map tiles, built from OpenStreetMap data. No API key. No billing account. No usage cap sitting quietly in the background waiting to surprise someone at the worst time. It exists specifically because enough people got tired of the exact problem above. You can self host it if you want to, which is exactly the kind of option that fits how we think about a client's own data and infrastructure.

The part that matters more than the price

Our actual routing already runs on real, open geographic data. Real river ways, real coastline data, real depth data, the kind of detail we have written about at length, including when it went wrong and exactly what we did to fix it. If the map someone is looking at were drawn from a different, private dataset than the one the routing engine calculates against underneath, the two could quietly disagree with each other. What you see and what the system actually knows should be the same map, not two maps that happen to look similar.

Using open data for both is not a compromise we settled for. It is the same rigor we already apply to the routing, applied to the picture too.

The honest tradeoff

We are not going to pretend there is no downside at all. Google's satellite imagery and street level photography are genuinely more polished in places, and its place search goes deeper in some cities. For a maritime and logistics platform tracking ports, coastlines, routes, and vehicles, that gap rarely matters in practice. We would rather put that difference toward the routing engine itself than toward imagery nobody tracking a container ship actually needs.

Where this stands

This is the map and tile approach behind the platform today, chosen the same way we choose everything else. Checked against what it actually costs to run at real scale, not just what it looks like in a demo with three test accounts and no real traffic yet.

One investment. Not a monthly bill. That has to be true underneath the platform too, not just on the pricing page.