HowWeBuildaFleetTrackingSystemfor30,000+Vehicles
An IoT fleet platform with custom GPS hardware, MQTT to AWS IoT Core, fuel-anomaly detection, driver scoring, and geofence alerts we design to fire in under two seconds.
This is the playbook we build with our team for live vehicle tracking at scale. We run a real IoT fleet platform on this exact shape, and it holds 30,000+ vehicles today. The numbers above are how a build like this usually shapes up. The rest of the page is the engineering underneath it, the calls we made, and the things the field taught us the hard way.
The Problem We Keep Seeing
A fleet runs on guesses. The dispatcher with 200 trucks under them genuinely cannot say where any single one is right now. Tracking means phone calls and check-ins and a driver's word. Route deviations surface only when somebody admits to one, which (no surprise) is not often. So the operation runs blind and everyone has made peace with it.
Fuel is where the money quietly leaks. Industry estimates put fuel theft at somewhere around a tenth to a sixth of total fleet fuel spend, and for a big operator that is real money walking out the gate every month. Siphoning on an overnight stop. A refuel claim that does not match the receipt. A detour to sell a tank on the side. None of it shows up unless you have sensor readings tied to GPS positions, and most fleets simply do not.
Driver behavior is invisible too. Hard braking, jackrabbit starts, speeding, an engine left idling for an hour. All of it burns fuel and bends the accident curve the wrong way, and nobody sees a shred of it until someone hand-compiles a report from paper logs at the end of the day. Hours of it, every evening. By then the thing you would have wanted to catch already happened.
How We Build It
We build the whole stack, hardware included. That last part is the unusual bit. Custom GPS units with a fuel sensor sit on the vehicle and push data over MQTT into AWS IoT Core. A Flutter app puts live access in the hands of drivers and managers. A React dashboard gives dispatch the wide view: every vehicle, every route, every anomaly worth a second look. None of it is a bolt-on. It is one system that happens to span a circuit board and a browser tab.
The pipeline does the heavy lifting. Each vehicle ships GPS coordinates, speed, heading, fuel level, and accelerometer data on a short cycle. That stream flows through MQTT into a processing layer that runs geofence checks, fuel-anomaly detection, and driver scoring as the data lands. We design the alert path so a flagged event reaches the manager's phone in roughly a couple of seconds, because an alert that arrives after the truck has gone is just a log entry.
Geofencing is more than circles on a map. Operators draw polygons that trace the real edges of a thing, a loading yard, a restricted zone, a customer site, a fuel station. Cross a boundary and the system logs the event with a timestamp, how long the vehicle dwelt, and the change in fuel level. That fuel-level delta at a fuel station is the tell. It is how the system separates an honest fill from a number that does not add up.
Flutter, Node.js, MQTT, AWS IoT Core, TimescaleDB, PostgreSQL, Redis, WebSocket, React dashboard, Google Maps API, custom GPS hardware with fuel sensors
The Decisions That Mattered
MQTT over HTTP was the first call and the one that shaped the most. Tens of thousands of devices reporting on a short cycle is a steady firehose of messages with nasty peaks at rush hour. HTTP wants a fresh TCP handshake for every message, which falls over fast at that volume. MQTT holds a persistent connection with almost no overhead per message. The protocol was built for exactly this. We did not fight it.
TimescaleDB for the time-series data was the second big one. Plain PostgreSQL chokes on an insert-heavy load at this scale. TimescaleDB hypertables partition by time on their own, so writes stay quick and the queries people actually run (last 24 hours, last week) come back near-instant. Old data compresses itself, which kept storage from spiraling. That last bit is not glamorous, but storage is where IoT bills quietly go to die.
Building our own hardware instead of bolting onto off-the-shelf trackers was the call people question the most, so here is the why. No stock device we found put GPS, a fuel sensor, and an accelerometer in one unit with the three streams correlated on the board. We needed that correlation at the source to catch fuel theft with any confidence. Stock gear meant two or three boxes per vehicle, which triples the install time and the failure points. So we built the unit.
Redis carries the real-time layer. Every vehicle's current position, speed, and status lives there with a short TTL. Open the dashboard and you see the live fleet without ever touching the main database. WebSocket pushes the updates out to the screen and the app as they happen. The dashboard does not poll for changes. It just listens, and the new position arrives.
What Gets Built
Real-Time Vehicle Tracking
Every vehicle sits on a live map, accurate to a few meters once the filter has done its work. Positions refresh on a short cycle. Kalman filtering smooths the noise so a parked truck does not appear to twitch around the lot. Click any vehicle and you get its speed, heading, nearest address, fuel level, and who is driving. At fleet scale the map would be unreadable as raw pins, so it clusters at low zoom and breaks out into individual markers as you zoom in.
Fuel-Anomaly Detection
The system reads fuel level against GPS position on every cycle. A sharp drop while the vehicle is parked and nowhere near a registered station gets flagged on the spot. It also catches the patient stuff: a slow siphon over hours, a refuel that does not match what the sensor saw go in, a burn rate that runs hot for the distance covered. The aim is to surface the leak while a manager can still do something about it, not three weeks later in a report.
Driver Behavior Scoring
The accelerometer feeds a score that watches for hard braking, sharp acceleration, speeding, aggressive cornering, and long idles. Each driver lands on a daily number. The point is coaching, not a stick. A manager opens the score before a conversation and has something concrete to talk about instead of a hunch. The behavior that moves the score also moves fuel use and the accident curve, which is why the score is worth keeping honest.
Polygon Geofencing
Managers draw the boundary they actually mean, not a circle that sort of covers it. Real polygons that hug a facility edge, a loading dock, a no-go zone. Entry and exit fire alerts by push, SMS, or email, whichever the operator picks. The system logs dwell time at each fence, and that dwell number is quietly useful. It is the kind of data that turns up a slow loading bay nobody had thought to blame.
Automated Reporting
Daily, weekly, and monthly reports build themselves. No more evenings lost to stitching paper logs together by hand. The reports cover distance per vehicle, fuel burned against what was expected, geofence events, behavior scores, mileage-based maintenance flags, and route efficiency. They export as PDF or land in an inbox on a schedule. The hours a manager used to spend compiling go back to actually running the fleet, which is the whole point.
Mobile App for Drivers
The driver gets a Flutter app that earns its keep on their side, not just management's. Their route, the next stops, arrival estimates, and their own score. They can log a vehicle issue, photograph a fuel receipt, and message dispatch without leaving the app. It works offline and syncs when the signal comes back, which matters more than it sounds when half the day is spent in dead zones. Build the app so it helps the driver and adoption stops being a fight.
What the Build Is Engineered to Do
These are the design targets we hold the system to, the engineering it takes to track a large fleet in real time without the platform buckling. They describe the architecture and the proven scale of our own IoT fleet platform, not a measured saving for any one operator.
| Capability | Target | How |
|---|---|---|
| Fleet scale | 30,000+ vehicles | Live on our real IoT fleet platform today |
| Position accuracy | A few meters | A-GPS plus Kalman filtering on the signal |
| Device messaging | Persistent | MQTT to AWS IoT Core, built for IoT volume |
| Alert path | Around 2 seconds | Stream processing on the way in, not batched |
| Sensor history | Compressed | TimescaleDB hypertables, auto-partitioned by time |
| Live state | Off the database | Redis with short TTL, pushed over WebSocket |
What a Build Like This Costs in the Market
For planning, a full custom fleet platform with hardware tends to run in the low-to-mid six figures in the market right now, with a basic GPS-and-dashboard build coming in well under that. Add fuel analytics, driver scoring, and polygon geofencing and you climb back up. The vehicle hardware is a separate per-unit cost, usually somewhere in the tens to low hundreds of dollars per GPS-plus-fuel-sensor device, paid once at install. These are market ranges to budget against, not a Geminate Solutions quote.
Running it scales with how many devices are talking and how much history you keep. At fleet scale, cloud cost lands in the low thousands a month across the IoT connections, the TimescaleDB storage, and the Redis layer, and more if you never archive. The honest way to frame the number is against the alternative. Per-vehicle SaaS fees look small on one truck and enormous across thousands, every year, forever. Whether the custom math works for your fleet size is exactly the conversation we would rather have up front than oversell.
Build It, or Buy Samsara?
Most fleets start on a SaaS tool, and for a small operation they should. Samsara, Geotab, and the rest are good, and you are live in weeks. The pinch comes when the fleet grows, because per-vehicle fees compound, and when you need rules or hardware the platform will not bend to. Here is the honest comparison, with costs you can plan against.
| Approach | Cost | Timeline | Customization | Best For |
|---|---|---|---|---|
| Custom Fleet Platform | $100K to $200K upfront | 5 to 8 months | Full control | Large fleets needing custom rules and hardware |
| Samsara | $30 to $40 per vehicle a month | 2 to 4 weeks | Moderate (their hardware plus API) | US-focused fleets under a couple thousand vehicles |
| Geotab | $25 to $35 per vehicle a month | 2 to 4 weeks | Moderate (open platform, SDK) | Data-heavy fleets wanting third-party integrations |
| Fleet Complete | $20 to $30 per vehicle a month | 1 to 2 weeks | Low | Small fleets wanting basic GPS and driver behavior |
So when does a custom build make sense? Run the arithmetic. A per-vehicle fee that looks trivial on one truck turns into a large recurring line across a big fleet, and you pay it again every year whether or not you use a single new feature. A platform you own has a real upfront cost and a modest monthly bill to run, and after that the curve flattens. Below roughly a thousand devices, SaaS usually wins on simplicity. Above it, owning the stack tends to win on cost and on control of your own data.
The pipeline underneath this is not fleet-specific either. The same MQTT-plus-real-time shape powers manufacturing floors watching machine sensors, agricultural rigs reading soil and equipment, and connected medical devices reporting from the field. If you are weighing a build against a per-device subscription, the tipping point is what to look for. Find where the recurring fee crosses what it costs you to run your own, and the decision mostly makes itself.
What We've Learned Building These
GPS in the lab lies to you. Our early prototype tracked beautifully across an open field, and we felt good about it for about a day. Then it went into a city. Signal bounced off glass towers and the dot leapt fifty, a hundred meters at a time, marking phantom trips that never happened. Kalman filtering fixed it. It cost us a week and it was the week between a product people trust and one they quietly stop opening.
Fuel sensors are fussy, and they are fussy per vehicle. A sensor that reads true on a sedan goes sideways on a truck, because the tank shape bends the capacitance curve it relies on. We built a calibration step into the install. The technician fills the tank, drains it in roughly ten-percent steps, and the system learns that specific tank's curve. It adds half an hour at install. It also kills the false fuel-theft alerts that would otherwise train everyone to ignore the real ones.
MQTT quality-of-service levels matter more than we expected going in. QoS 0 is fast and drops messages the moment the network hiccups. QoS 2 guarantees exactly-once and roughly triples your bandwidth doing it. We settled on QoS 1, at-least-once, with deduplication on the server side. Reliable delivery, none of the QoS 2 tax. Boring middle path, correct answer.
And drivers decide whether any of it works. The best tracking system on earth fails if the people in the cab treat it as the enemy and go looking for the unplug. We learned to give the driver something they want out of the app, their score, a cleaner route, a maintenance nudge before a breakdown. Do that and the same tool management uses to watch becomes a tool the driver uses to get through the day. That flip is the whole game.
Frequently Asked Questions
How long does it take to build a fleet tracking platform?
Plan on six to eight months for a full platform with custom hardware, a driver app, a dispatcher dashboard, and the real-time pipeline behind it. A first version with live GPS and basic alerts lands sooner. The long pole is almost always the hardware, because firmware and field testing run on their own clock and a tank-sensor calibration that has to behave in the rain is not something you rush.
How do you get GPS accuracy down to a few meters?
We combine the raw GPS fix with assisted GPS and network positioning, push it over MQTT to AWS IoT Core, and run a Kalman filter to smooth the noise. Raw GPS in a city is messy. The signal bounces off buildings and the dot jumps fifty or a hundred meters. The filter is what turns that into a vehicle that tracks where it actually is, in town and out on open road.
How does fuel-anomaly detection work?
We line up the fuel-sensor reading against the GPS position on every cycle. A sudden drop while the vehicle is parked and nowhere near a registered station gets flagged. So does a refuel that does not match the level the sensor saw, and a burn rate that runs hot for the distance. Per-vehicle calibration keeps false positives down. We design the alert path to fire in roughly a couple of seconds so a manager can act while it still matters.
Can a platform like this scale past 30,000 vehicles?
Yes, and the architecture is built for it. MQTT was made for fleets of devices holding persistent connections. TimescaleDB partitions the time-series data by time so writes stay fast as the table grows. Redis keeps the live state. We design and load-test these systems to take far more concurrent connections than the live fleet, because headroom is the point of choosing IoT-native pieces in the first place.
What technology stack runs a build like this?
Flutter for the driver and manager apps. Node.js for the backend and the real-time pipeline. MQTT to AWS IoT Core for the devices, TimescaleDB for the sensor history, Redis for live state, and WebSocket to push updates to the screen. A React dashboard for dispatch, Google Maps for the map, and custom GPS hardware with a fuel sensor on the vehicle side.
Should you build a custom fleet platform or buy a SaaS tool?
Buy when the fleet is small and the off-the-shelf feature set fits, because tools like Samsara and Geotab are good and you are live in weeks. Build when per-vehicle fees compound past what a custom platform costs to run, or when you need rules and hardware those tools will not give you. The same math shows up in delivery tracking, campus transport, and equipment monitoring, and the tipping point usually lands around a thousand devices.
What does a fleet tracking platform cost to run once it is live?
Cloud cost scales with how many devices are talking and how much history you keep. At fleet scale, hosting tends to sit in the low thousands a month across IoT connections, time-series storage, and the real-time layer, and more if you never archive. The vehicle hardware is a one-time cost per unit. These are market ranges to budget against, not a Geminate Solutions quote.
What catches teams off guard when they build fleet software?
The hardware reality, mostly. GPS that looks perfect in an open-field test falls apart between buildings. Fuel sensors read differently on a truck than on a sedan because tank shape bends the sensor curve, so you need per-vehicle calibration or you drown in false alerts. And driver adoption decides everything, because the best tracking in the world fails the moment the people in the cab find a way around it.
Can Geminate Solutions build a fleet tracking platform for us?
Yes. The hardware design, the MQTT pipeline, the fuel-anomaly logic, and the dashboards are patterns we build with our team. We run a real IoT fleet platform that tracks 30,000+ vehicles, and Geminate Solutions has shipped 50+ products. Tell us the fleet size and what you are trying to catch, and we will tell you honestly what it takes. Start at geminatesolutions.com/get-started for a free project assessment.
Why Teams Bring This to Us
An IoT fleet platform needs Flutter, Node.js, real-time pipeline work, and embedded firmware in the same room, and that mix is genuinely hard to assemble in a hurry. More often the issue is not skill at all. The in-house engineers are already buried in the core product, and pulling them onto a tracking build would stall the roadmap for months. Building it with our team keeps the product moving while the platform comes together in parallel, with people who have shipped this exact shape before.
The hardware is the other reason. Most software teams have never specced a GPS unit or fought a fuel sensor that reads fine on the bench and lies on a truck, and that gap is where a fleet project quietly dies. We build with you as a product partner, not a code shop taking a spec over the wall. So the calibration wizard, or the QoS 1 deduplication, or the choice to filter the GPS noise before it ever hits the map, often comes from a suggestion on our side, because we have already learned which of those the field punishes you for skipping.
Related Resources
- IoT App Development Cost GuideMarket pricing for IoT platforms and hardware integration
- Fleet Management Software Development GuideA deeper look at GPS tracking architecture
- Custom Software Development ServicesHow we build and ship products with our team
- Logistics Software DevelopmentTracking, routing, and operations for fleets and delivery
- IoT GPS Tracking System Case StudyAnother IoT build with hardware and software in one stack
Thinking about building one?
The hardware design, the MQTT pipeline, and the real-time architecture on this page are the same ones we build with our team for your fleet. We run an IoT platform that tracks 30,000+ vehicles, and Geminate Solutions has shipped 50+ products. Tell us your fleet size and what you are trying to catch, and we will tell you honestly what it takes.