HowWeBuildanIoTGPSFleetTrackingPlatform

This is how we build a real-time fleet tracking platform with our team, and it is the same engineering that runs Pixytan, where we track 30,000+ vehicles. The numbers up top are how a build like this usually shapes up. The rest of the page is the part under the hood. The protocol choices, the database we landed on, the bits we got wrong the first time and had to redo.

The Problem We Keep Seeing

A fleet of tens of thousands of vehicles, and almost no real-time visibility into any of them. Drivers phone in their own location. Dispatch runs on radio and guesswork. A truck breaks down on a highway and the operations room hears about it whenever the driver gets around to calling, which can be hours. Fuel goes missing. Routes drift. And because nobody is measuring how people actually drive, the accident rate just sits there.

The off-the-shelf GPS boxes on the market tend to fall down in the same three places. The hardware is third-party with locked firmware, so you cannot wire in your own sensors or pull OBD-II engine diagnostics. The dashboards were built for small fleets of fifty or a hundred vehicles and they buckle once you point real volume at them. And the alerts come over SMS with a 30 to 60 second lag, which is a lifetime when a vehicle has just crossed a boundary it should not have.

So the brief runs well past dots-on-a-map. Position updates every 10 seconds. Geofence alerts that fire in under 2 seconds, not half a minute. Driver scoring off real acceleration and braking and cornering. Fuel monitoring that can actually catch a siphon. Maintenance warnings that read engine data instead of a fixed calendar. And a mobile app, because the people running a fleet are rarely at a desk. All of it has to stay up while every device in the fleet reports at once. That last constraint is the one that decides everything after it.

How We Build It

We build it as a full-stack platform. Custom hardware, mobile apps, backend, and a web dashboard, all one system rather than glued-together parts. The GPS device is designed in-house with an OBD-II port for engine data, an accelerometer for driver behavior, and a SIM cellular link to get the data out. Each unit reports its position every 10 seconds over MQTT, which is a lightweight messaging protocol built for exactly this. Tiny devices, thin pipes, lots of them.

The backend is Node.js with a Mosquitto MQTT broker doing the device connections. AWS IoT Core handles registration, auth, and message routing once the device count climbs. Location data drops into TimescaleDB, a PostgreSQL extension tuned for time-series, which squeezes months of GPS coordinates into a fraction of what a plain table would eat. A Redis layer holds the latest position for every vehicle, so when a manager opens the dashboard the whole fleet paints in under a second instead of hammering the database for it.

Two front ends, two jobs. The React web dashboard is the operations-room view. Vehicle clusters on a map, fleet-wide analytics, geofence setup, maintenance scheduling. The Flutter mobile app is for the manager who is out in the field, with live tracking, push alerts, trip history, and driver scorecards in their pocket. Both pull live updates over WebSocket, and both reconnect on their own when the network drops, because on mobile it will.

The Decisions That Mattered

MQTT over HTTP, and the gap is not subtle at scale. Run an HTTP request from 30,000 devices every 10 seconds and you are opening something like 180,000 TCP connections a minute. MQTT keeps one persistent connection per device alive with 2-byte keepalive packets. The overhead drops from roughly 800 bytes per HTTP request to about 4 bytes per MQTT publish. At fleet scale that is the difference between a few hundred megabytes of pure protocol chatter per minute and well under a megabyte. HTTP would have buried us.

TimescaleDB over plain PostgreSQL or MongoDB for the location store, and we would make that call again. GPS data is time-series by nature. Lat, long, speed, heading, timestamp, over and over. TimescaleDB's hypertables split it into time-based chunks automatically, and its native compression knocks storage down dramatically once data ages past a week. A query like "give me every position for vehicle X in the last 24 hours" comes back in milliseconds even with billions of rows behind it. The same query on vanilla PostgreSQL crawls into the seconds, which is the difference between a usable dashboard and a spinner.

Geofencing runs server-side, not on the device. Every incoming coordinate gets checked against the active fences for that vehicle's fleet. A fleet can have thousands of fences, and a naive point-in-polygon sweep across all of them would be far too slow. So we put the fences behind an R-tree spatial index, which turns the check from O(n) into O(log n). A single coordinate tested against thousands of geofences finishes in well under a millisecond. That is what lets the under-2-second alert promise actually hold.

Custom hardware added about 3 months, and it was worth every week. Generic trackers cannot read OBD-II engine data. RPM, coolant temperature, fuel level, trouble codes, none of it. Our device folds GPS, GSM, an accelerometer, and an OBD-II reader into one unit. That sensor data is what driver scoring, fuel-theft detection, and predictive maintenance all stand on. Without the custom board, those features are just marketing words. (We have shipped enough of these to know the off-the-shelf route quietly caps what the platform can ever do.)

What Gets Built

Real-Time Vehicle Tracking

Every vehicle reports its position every 10 seconds. The React dashboard paints them on a map with color-coded status. Green for moving, yellow for idle, red for stopped, gray for offline. Click any vehicle and you get live speed, heading, nearest address, current driver. The map clusters markers when you are zoomed out and breaks them apart as you zoom in, which is the only way 30,000 markers stay smooth in a browser. Historical playback lets a manager replay any route for the past 90 days, with the animation speed under their control.

Geofencing and Instant Alerts

Managers draw fences right on the map. Circles, rectangles, custom polygons. Cross one, in or out, and the alert fires within 2 seconds across three channels at once. Push to the Flutter app, email to the manager, popup on the dashboard. The usual jobs are depot entry and exit, restricted-zone monitoring, route-corridor enforcement, and a heads-up when a vehicle reaches a customer site. We design the engine to run those checks for the whole fleet against thousands of live fences with no lag a human would notice.

Driver Behavior Scoring

The accelerometer reads three axes of motion non-stop. The backend turns that into harsh braking (deceleration past 0.4G), rapid acceleration, sharp cornering, and speeding. Each trip lands a 0 to 100 score weighted on how often and how hard those happen. Drivers see a simplified version of their own. Managers get the full ranking, trend lines for who is improving and who is sliding, and an automatic flag on anyone under 60. The target here is fewer hard stops and steadier driving across the fleet. A score nobody trusts changes nothing, so we build it to be explainable.

Fuel Monitoring and Theft Detection

OBD-II hands us a fuel-level reading every 30 seconds. The system learns each vehicle's normal consumption against distance, engine load, and how it is being driven. When the level drops faster than that baseline says it should, which usually means a siphon, or a refuel shows up that does not match any authorized stop, it flags right away. The manager gets the alert with a timestamp, a location, and an estimated volume. We design this to catch the quiet leakage that a monthly fuel report never surfaces in time to do anything about.

Predictive Maintenance Alerts

The OBD-II feed carries engine RPM, coolant temperature, battery voltage, and diagnostic trouble codes. The system watches those over time and flags the patterns that matter. Coolant creeping up across a week, voltage sagging below a line, a trouble code that keeps coming back. The whole point is to warn before the breakdown, not file a report after it. Managers get a per-vehicle service calendar built from real engine behavior instead of a fixed every-N-kilometers rule that ignores how each truck is actually doing.

Fleet Analytics Dashboard

The React dashboard rolls up the fleet-wide picture. Distance per day, fuel trends, average driver scores, idle-time percentages, maintenance spend. Custom reports run for any date range and export to PDF or CSV. Comparison views stack one vehicle against the fleet average, or one driver against their peers. We design it to load in a couple of seconds even for a large fleet, leaning on TimescaleDB continuous aggregates for the pre-computed metrics and Redis for the views people open most.

Mobile Fleet Manager App (Flutter)

Managers are not at a desk, so the Flutter app carries the essentials. Live vehicle positions on a map, push alerts for geofence events and driver violations, trip history with route playback, driver scorecards. A quick-action button fires a message straight to a specific driver. An offline mode caches the last known position of every vehicle, so even with no signal a manager can still see roughly where the fleet is. We build the mobile experience to a real app-store quality bar, not a wrapped webpage.

What the Build Is Engineered to Do

These are the design targets we hold the system to, the engineering it takes to make fleet tracking fast and dependable at scale. They describe the architecture and the one stat we can state as fact, the 30,000+ vehicles we track on Pixytan. They are not a specific customer's savings figure.

Build Custom, or Use AWS IoT Core?

Custom platform or a managed cloud one? It comes down to device count. Cloud platforms bill per message and per device, which is friendly when you are small and brutal when you are not. A custom stack costs more up front and far less at the margin as you grow. Here is the honest version.

Those are market figures to reason with, not a Geminate Solutions quote. The crossover is roughly a thousand devices. Run 500 devices reporting every 5 seconds and a managed cloud platform's message fees alone can climb into the tens of thousands a year, while a custom MQTT broker on dedicated infrastructure carries the same load for a few thousand. Below the line, cloud wins on speed. Above it, owning the stack wins on cost. (Where your line sits depends on report frequency and retention, so do the math on your own numbers before anyone's slide deck does it for you.)

The time-series pipeline here travels well past GPS. The same shape powers manufacturing sensor systems, energy smart-meter platforms, and agricultural monitoring networks. If you are weighing a partner for an IoT build, the thing to look for is a team that has actually shipped hardware and software together. Pure software teams underestimate the firmware, and the gap between a clean simulation and a device rattling around at 80 km/h is exactly where most IoT projects come apart.

What We've Learned Building These

IoT has a hardware-software feedback loop that pure software never deals with. An early batch of our GPS devices had an antenna placement that lost signal inside metal truck cabins, and no clever code fixes a hardware problem. We could not write our way out of it. It took a board revision and a few weeks we had not planned for. The lesson stuck. Prototype the hardware in the real world early, because a lab bench does not behave like a steel cab doing highway speed.

MQTT quality-of-service levels matter more than they look. QoS 0, fire and forget, drops a tiny fraction of messages under normal load, which is fine for position updates since the next one is 10 seconds out. But losing a single geofence alert or maintenance warning is not fine. So we split it. QoS 1, at-least-once, for the alerts that have to land. QoS 0 for the routine position stream. That keeps the bandwidth lean while guaranteeing the messages that actually matter always arrive.

The data volume from a large fleet reporting every 10 seconds is enormous. We are talking hundreds of millions of location rows a day. Ordinary database hygiene, the vacuums and index rebuilds that work fine for a normal app, just fall over at that scale. TimescaleDB's automatic chunk management and compression were not a nice-to-have, they were the whole reason it stayed affordable and fast. Skip them and storage balloons and queries rot within weeks.

Driver scoring only works if drivers trust it. Our first version flagged every hard brake, including the emergency stop that probably saved someone. Drivers said it was unfair, and they were right. So we added context. Braking near a traffic signal, a stop sign, or a known hazard stopped counting against the score. A hard stop on an open highway still did. That one change is what turned the feature from something drivers resented into something they actually engaged with, which is when fleet managers finally saw driving patterns start to move.

Frequently Asked Questions

What a Build Like This Costs in the Market

For planning, a full-stack fleet platform with custom hardware, mobile apps, backend, and dashboard sits in the $100,000 to $160,000 range in the market right now. The hardware design and manufacturing is what pushes it up. A software-only build on off-the-shelf trackers runs lower, closer to $60,000 to $90,000. Running it lands somewhere around $1,500 to $2,500 a month for hosting, the MQTT broker, TimescaleDB storage, and AWS IoT Core, with a few hundred more on top for firmware work and device-fleet upkeep. These are market ranges to budget against, not a Geminate Solutions quote. The real number depends on device count, report frequency, and how much custom hardware you need.

The more useful comparison is against renting one. Off-the-shelf GPS subscriptions run roughly $15 to $30 per vehicle a month in the market, with locked features and no OBD-II, and you never own the data or the platform. At large fleet sizes that recurring line gets big fast. So the build-versus-rent question is less about the upfront number and more about whether you want fleet tracking to stay an operational cost forever or become an asset you control. That is exactly the trade-off we would rather lay out honestly up front than oversell.

Why Teams Bring This to Us

An IoT build like this needs firmware, cloud architecture, and mobile, all living in the same set of heads at the same time. That mix is genuinely hard to assemble in a hurry, and harder still to assemble in people who have actually shipped IoT at scale rather than read about it. More often, though, the issue is not skill at all. The in-house engineers are already buried in the core product, and pulling them onto a tracking platform would stall the roadmap for months. Building it with our team keeps the product moving while the platform gets built in parallel, by people who have done this exact shape of thing before.

We build it with Pixytan ourselves, so this is not theory for us. We work as a product partner, not a code shop taking a spec over the wall and hoping. That is usually why the suggestion to split MQTT QoS levels, or to put the geofences behind a spatial index, or to score braking with context, comes from our side rather than yours. We have already watched which decisions hold up once real devices are out in the world, and we would rather tell you before you hit them than after.

Related Resources

• Case Study: Fleet Management, 30K Vehicles
• IoT App Development Cost Breakdown
• Fleet Management Software Development Guide
• Fleet Management Software Development Services
• Twings / Pixytan, Full Portfolio Details
• Custom Software Development Services