Google Maps
Was Not Built for You.

We want to be fair about this from the start. Google Maps is an extraordinary piece of engineering. Mapbox is too. Both products have been refined over many years by very large teams with very serious resources, and for the people they were built for, they are close to perfect.

The problem is not the quality of those products. The problem is who they were built for. And it was not you.

Who the big map platforms were actually built for

Google Maps exists to serve billions of people navigating cities, finding restaurants, estimating commutes, and checking traffic before they leave the house. That is the use case behind every engineering decision, every product investment, and every feature on the roadmap. When Google improves their turn-by-turn routing, they are thinking about a driver at a junction in Jakarta or Mumbai or Lagos, not a captain approaching a port berth in Batam.

Mapbox sits a layer up from that. It gives developers the tools to build beautiful, customisable maps for consumer products, logistics apps, real estate platforms, and delivery services. Their customers are measured in the thousands of companies and millions of end users. It is a good business built on a big market.

Maritime freight is not that market. Not even close.

The numbers that explain the silence

There are roughly 90,000 merchant vessels operating worldwide at any given time. The number of shipping companies, freight forwarders, and port operators that would ever need map software is orders of magnitude smaller than the number of restaurants a single city-level Google Maps team handles in a week.

This is not a criticism. It is just arithmetic. A product team at Google or Mapbox has to decide what to build next, and they build for the largest possible impact on their largest possible user base. Maritime operators are not that user base. They never were. They probably never will be.

The result is not that those platforms are bad. The result is that they simply never built what ships actually need, because there was never a strong enough reason to.

What ships actually need that those tools do not have

A road navigation product needs to know about streets, traffic lights, speed limits, and real-time congestion. That is a well-understood problem with decades of investment behind it.

A maritime operator needs something different in almost every dimension.

Sea depth matters. A route that looks perfectly reasonable on a standard map can send a loaded vessel through water too shallow to sail. Google Maps does not know your vessel's draft. It was not designed to. The information is not even part of the data model.

Narrow passages are invisible at standard resolution. Rivers, straits, and harbor approach channels that real vessels use every day can simply disappear in the coastline data that consumer map tools rely on. We have written about this in detail elsewhere: a navigable river can register as solid land, and two real ports a short distance apart can collapse onto the same point on the map.

The relevant data is not street-level, it is sea-level. Ocean currents, tidal windows, anchorage areas, berth availability, and port-specific approach corridors are not the kind of information that flows naturally into a platform built around roads and buildings. You can layer some of it on top, with enough custom work. But you are fighting the product's assumptions the entire time.

The routing logic was designed for vehicles that stop at red lights. A vessel that has committed to a passage through a strait cannot simply pull over and recalculate. The planning horizon is different, the consequences of a bad suggestion are different, and the data inputs required to make a good suggestion are different. None of that is accounted for in a product designed for drivers.

The customisation trap

The common response to this is that both platforms are highly customisable. You can add your own data layers, write your own routing logic, override the defaults. That is true, and teams have tried it.

What they find is that the further your use case sits from the intended one, the more of the platform you end up fighting. Every maritime-specific requirement becomes a custom layer on top of a foundation that was not designed with it in mind. At some point you are not using the platform anymore. You are using the map tiles and doing everything else yourself.

At that point, paying for a product whose core assumptions do not match your problem is a choice worth questioning.

What we use instead, and why

We have written a separate post about the specific map technology we use and the reasoning behind that choice. This post is not about that. This post is about the upstream question: why we could not simply reach for the obvious tools that the rest of the software world uses.

The honest answer is that Google Maps and Mapbox were built for a market that is not ours. They have been optimised, refined, and invested in for that market. They are excellent at what they do. What they do just does not include routing a vessel through the Mahakam River delta, or accounting for a port whose coordinate sits three nautical miles from where the water actually is.

Nobody at Google is going to fix that. Not because they cannot. Because there are not enough ships in the world to make it worth their while.

That is not a complaint. It is just the reason we had to build our own.