Build vs. buy a GPS tracking platform

The comparison people make, and the one that matters

The usual framing is licence cost against engineering cost, which makes buying look expensive and building look free. Engineering time is not free; it is the scarcest resource a young tracking business has, and it is already committed to something.

The comparison that decides it is different: how long until you can invoice a customer, and how much of the roadmap you need to own. Those pull in opposite directions. Building maximises control and delays revenue. Buying does the reverse. Everything else is detail.

What building actually costs

The first version is cheap and encouraging. A single protocol, a socket listener, dots on a map — a competent engineer gets there in a few weeks, and it demos well.

The costs arrive later, and they are recurring rather than one-off:

• Every additional manufacturer is a new decoder, written from packet captures because the documentation describes intent rather than behaviour.
• Firmware revisions move fields without notice. Decoders are maintained, not finished.
• Ingestion cannot go down during a deploy. Devices that fail to reconnect become support tickets about missing vehicles.
• Multi-tenancy is nearly impossible to retrofit. Get the account model wrong early and it is a rewrite, not a refactor.
• Retention, replay and reporting are unglamorous and turn out to be most of the code.

Budget protocol work as an ongoing operating cost, not a project phase. It is the line item that outlives the launch.

What buying actually costs

A per-device fee, and a dependency. The fee is easy to model — ours starts at $1.49 per device per month for ingestion and the API, and the full range is published rather than quoted.

The dependency is the real question, and the honest answer is that it depends entirely on where the platform stops. A platform that only gives you a finished portal owns your product. One that exposes normalized telemetry over an API leaves you building whatever you want on top, and the dependency is confined to the layer you did not want to write anyway.

What buying does not solve

A platform decision is not a business decision, and vendors are not motivated to point that out. Whichever way you go, these stay yours:

• The hardware relationship — sourcing, pricing, failure rates, RMA terms, and the working capital tied up in stock.
• Connectivity — SIMs, data plans, and the margin between what you pay per device and what you charge.
• Installation — finding, training and paying people to fit devices, or persuading customers to self-install.
• Support — when a customer says a vehicle is missing, the answer is yours to find whether or not you wrote the decoder.
• The customer relationship, the pricing and the positioning.

Buying removes the engineering from that list. It does not remove the business. Teams that expect a platform to make them a tracking company are disappointed for reasons that have nothing to do with the platform.

When to build

Genuinely sometimes the right answer:

• One protocol, one customer, and no plausible second of either.
• Tracking is a small feature inside a larger product you already run.
• The data model itself is your differentiation.
• Engineers are idle and no customers are waiting.

The four things you are actually building

"GPS tracking software" reads as one system. It is four, and only one is the part people picture when they scope it.

• Ingestion — a socket server holding thousands of long-lived TCP and UDP connections from devices that reconnect on their own schedule and cannot be told to wait while you deploy.
• Decoding — turning each manufacturer’s binary frames into positions and events. Never finished; see the separate guide.
• The platform — accounts, inventory, provisioning, permissions, geofences, alert rules, trips, reports, retention. Unglamorous, and the majority of the code.
• The interface — a live map and a device list. Scoped first, smallest slice of the work.

Storage is a decision, not a detail

A tracker reporting every thirty seconds produces roughly 2,900 positions per device per day. A thousand devices is about three million rows a day, and they arrive whether or not anyone opens the map.

That number decides your architecture more than any feature does. It forces a retention policy, and retention is a commercial decision disguised as a technical one — how far back can a customer replay a trip, and what do you charge for the difference. Teams that defer it end up either paying for storage nobody uses or deleting history a customer assumed was permanent.

It also decides your database. Position history is append-heavy, queried by device and time range, and almost never updated. That is a different shape from the rest of the application, and discovering it late usually means a migration under load.

Multi-tenancy is the decision you cannot defer

Nearly everything else in a tracking platform can be retrofitted. The account model cannot.

If your first customer is a single fleet, the obvious schema has devices belonging to users. The moment a distributor arrives wanting sub-accounts, dealers beneath those, branding that inherits down the tree and permissions that do not, every query you have written needs a tenant boundary threading through it. That is a rewrite wearing the costume of a refactor.

Build it on day one even if you have one customer, or accept that you are choosing never to sell to a distributor. Both are legitimate; drifting into the second by accident is not.

Of everything on this page, the account model is the decision that is cheapest to get right early and most expensive to change late.

The costs that appear in year two

First-year budgets capture the build. What they miss is that a tracking platform is an operational commitment, not a delivery.

Devices report continuously and forever. That means someone is on call for the ingestion tier, because a socket server that dies at 2am is a fleet with no visibility until someone notices. It means storage grows monotonically — positions arrive whether or not anyone looks at them — so retention policy becomes a cost decision rather than a preference.

And it means every manufacturer firmware release is a potential regression in code you own. None of this is difficult. All of it is permanent.

A realistic timeline

Rough shape, assuming one experienced engineer who has not done this before:

• Weeks 1–3: one protocol decoded from a packet capture, positions landing in a database, a map that renders them.
• Months 2–4: a second and third protocol, at which point the abstraction you chose in week 2 either holds or gets rewritten.
• Months 4–8: accounts, permissions, provisioning, geofences, alert rules — the platform rather than the tracker.
• Ongoing: firmware regressions, new device families, retention and cost tuning.

The demo arrives in week three and the product arrives in month eight. Most build-versus-buy decisions are made in week four, on the strength of the demo.

Questions that decide it

If you can answer these, the decision usually answers itself:

• How many device families will you support in two years — one, or an unknown number?
• Is your differentiation the tracking data, or what you do with it?
• Who is on call for ingestion, and what happens when they are on holiday?
• What is the cost of being six months later to your first customer?

When to buy

Devices are in hand, customers are asking for logins, and the hardware margin only works at volume. Here the build is not beyond you — it is simply the wrong use of the quarter, and the opportunity cost is measured in customers who went elsewhere while you wrote a parser.