Short version. A telematics platform is not a map with dots on it; it is device decoding, ingest, storage, derived logic, multi-tenancy, reports and a mobile app, and every one of those keeps needing work after launch. Almost nobody should build all of it. The real choice is which layers to own: rent decoding from a gateway such as Traccar or flespi and build the application; license a finished white-label platform such as Wialon or Navixy; or start from an open-source application and own the code from day one. Build from scratch only when the platform itself is what you sell and you can fund a team to keep it alive.
What building a telematics platform involves
Before comparing options, it helps to name the parts. Each one below is a separate piece of software with its own failure modes.
Device protocol decoding. Trackers speak hundreds of binary and text protocols, mostly vendor-specific. Traccar supports more than 200, and its repository holds 272 protocol decoder classes. The cost is not writing a decoder; it is keeping up. That one directory has taken 240 commits since 1 January 2026, as manufacturers ship firmware and new models.
Ingest. Idempotent writes, device-to-vehicle mapping, sensor normalisation, backfill after an outage, and alerting when nothing arrives. We have listed that work in detail elsewhere; none of it is hard, and all of it takes time.
Storage. Positions arrive every few seconds per vehicle and must stay queryable for months. Getting this wrong is cheap at fifty vehicles and expensive at five thousand; the storage write-up covers the trade-offs.
Derived logic. Trips, stops, idling, fuel fills and drains, harsh events, driver scores. This is where your customers’ arguments come from — a trip split in the wrong place, a fuel drain that was a slope — so it is where the product is judged. Fuel drain detection and driver scoring are each a post of their own.
Multi-tenancy and permissions. If you serve more than one customer, every query must be scoped to an organisation, and access usually has to reach down to a single vehicle. Retrofitting this is a rewrite.
Reports, alerts and exports. Scheduled reports in the formats customers’ finance teams accept, email delivery, geofence and threshold alerts, push notifications, an API and outbound webhooks for the integrations every larger customer asks for.
Mobile. Fleet managers want the fleet on a phone. That is a second client, with its own release cycle and app-store review.
The long tail. Geocoding, maps, maintenance schedules, an administration console, upgrades, backups, security patches, and on-call when ingest stops at 3 a.m.
What it took in one codebase
We can only measure our own, so here it is. Routly is well over 150,000 lines of TypeScript, tests included, across the API, the web app, an administration console, an Expo mobile app and shared packages, with more than 200 test files and 46 database models.
The backend modules map almost one-to-one onto the list above: ingest adapters for flespi, Traccar and a generic JSON webhook; normalisation and de-duplication; calculators for trips, fuel, idling, geofences, harsh events and eco scoring; retention; alerts and push notifications; scheduled reports in CSV, Excel and PDF; geocoding; maintenance; API keys and outbound webhooks; and organisation scoping throughout the schema.
And it contains no device protocol decoders at all. That was a deliberate decision: decoding is a solved problem with excellent existing implementations, and it was the layer we least wanted to maintain. The line count is not a claim about how long any of this takes you. It is a list of what a working platform turned out to need.
Five ways to get a telematics platform
1. Build from scratch
You write all of it, decoders included. You own every line and every decision, and you carry every protocol update forever. This is the option that makes sense only when the platform is the product — a hardware company that needs deep control of its own device, or a business whose differentiation lives in the data layer itself.
2. Traccar plus your own UI
Traccar is Apache-2.0, decodes the 200-plus protocols, stores positions and exposes an API. You build the customer-facing application on top. This removes the hardest maintenance burden for free. What you still build is most of the list: derived logic beyond Traccar’s own reports, multi-tenancy in the shape your business needs, reports, mobile. Past a certain size you will also be tuning Traccar itself.
3. flespi plus your own app
flespi is a hosted telematics gateway: it ingests from more than 1,000 device types and hands you messages in one normalised JSON format. It is priced by usage; flespi’s own pricing page says a typical middleware user at around 1,000 devices pays roughly €0.20 per device per month. Decoding and device management become a small line item. Storage beyond its buffer, and everything above it, is yours — the database question is covered here.
4. License a white-label platform
Wialon and Navixy both sell a finished platform you put your own brand on. Navixy offers its web and mobile applications with your logo, theme and custom domain; Wialon is sold only through partners, supports more than 4,100 device models, and on Wialon Local offers branding as licensed modules such as personal design and extra sites. You build nothing and launch fastest. In exchange the fee tracks your unit count and the roadmap is theirs. The Navixy comparison and Wialon’s pricing model go into both.
5. Open source with a commercial licence
Start from a complete open-source application and own the code. Routly is one; it sits on top of a gateway (option 2 or 3) rather than replacing it, so decoding stays somebody else’s maintenance. Under AGPL-3.0 it is free for a fleet hosting itself. A provider serving customers over a network either publishes its modifications or buys a commercial licence, which removes that obligation — the AGPL post explains exactly where the line falls. The trade is that you run it, and the community is small.
Telematics platform build vs buy: the decision table
| Build from scratch | Traccar + own UI | flespi + own app | Licensed white-label | Open source + commercial licence | |
|---|---|---|---|---|---|
| Decoding | You | Traccar | flespi | Vendor | Traccar or flespi |
| Application layer | You | You | You | Vendor | Provided, yours to change |
| Source code | Yours | Traccar’s is open; UI yours | Your app only | None | Complete |
| Fee shape | Team and infrastructure | Infrastructure | Usage-based gateway fee | Per unit, from the vendor | Infrastructure; licence quoted, not per unit |
| Time to first customer | Longest | Long | Long | Shortest | Short |
| Roadmap | Yours | Yours above Traccar | Yours above flespi | Vendor’s | Yours |
| Who you call | Your team | Your team, or Traccar’s managed hosting | flespi for ingest, your team above | Vendor | Your team, or a commercial agreement |
We have not put effort or cost figures in the table because none that we could find are sourced well enough to print. Your own estimate, made against the component list above, will be more honest than anybody’s average.
When building is the right answer
Building is a legitimate choice, and sometimes the only one:
- The platform is your product. If your margin comes from what the software does rather than the service around it, outsourcing the software is outsourcing the business.
- Your device is unusual. A proprietary tracker, unusual sensors or edge processing may need decoding and logic no gateway offers.
- You have the team, permanently. Not a project team for launch; engineers who will still be maintaining ingest and fixing trip logic in five years.
- Your requirements are narrow. A single customer with a single use case — cold-chain temperature, say — may need a fraction of the component list, and a small focused system can beat a general one.
If none of those holds, building usually means spending the first year reproducing what options 2 to 5 already have, before you can work on anything that differentiates you.
When buying is the right answer
- You want to sell next quarter, not next year, and a licensed white-label gets you there.
- You have no engineering team and no intention of hiring one.
- Your volume is low enough that a per-unit fee costs less than a single engineer — the margin arithmetic shows where that stops being true.
Vendor-by-vendor comparisons, each with the case for the other side, are on the comparison hub.
The middle options — a gateway plus an application, whether written or adopted — are where most providers who outgrow a licence end up, because they keep the decoding rented and the product owned. Open the demo, which needs no account, to see what the application layer looks like before deciding whether to write one.
Frequently asked
What are the best alternatives to in-house telematics development?
Licensing a white-label platform such as Wialon or Navixy, building only the application on a gateway such as Traccar or flespi, or adopting an open-source application such as Routly on top of a gateway. Which is best depends on whether you want to own the code and how fast you need to launch.
Is it cheaper to build a telematics platform than to license one?
At small volumes, rarely: a team costs more than a per-unit fee on a few hundred vehicles. At large volumes the per-unit fee can exceed what owning the software costs. The cost worksheet shows how to find your crossover.
Do I need to write device protocol decoders?
Rarely. Traccar and flespi decode hundreds of protocols between them, and building on either removes the most maintenance-heavy layer.
Can I resell an AGPL platform under my own brand?
Yes, if you publish your modifications under the same licence, or buy a commercial licence that removes the obligation. The plain-language AGPL guide covers both cases.
