How to Build an App Like Samsara (Fleet Management)

Samsara charges $27 to $33 per vehicle per month. A fleet of 100 trucks pays $32,400 to $39,600 every year, every year, before add-ons. A custom fleet management platform built to your workflows costs $180,000 to $280,000 once. At 100 vehicles, that payback math is 5 to 8 years — which is not always compelling on its own.

The operators who build their own do it because Samsara does not fit their operation. They have proprietary routing rules Samsara cannot encode. Their vehicles are refrigerated trucks, hazmat tankers, or construction equipment — Samsara treats a semi-truck and an excavator the same way. Or they have grown past the point where a generic platform justifies the cost relative to what they actually use.

This guide covers what it takes to build a fleet management platform, which modules matter, the technical decisions that determine whether it holds up at scale, and who should actually do it.

Who builds this instead of buying Samsara

Not every fleet should build. The ROI is clearest in a few specific situations.

Logistics and trucking companies with 50 or more vehicles are the clearest case. The Samsara bill at that size is real money, and the data requirements are often specific enough that generic fleet software leaves gaps. Last-mile delivery companies wanting routing optimization built into dispatch — not bolted on from a third-party tool — are a similar case.

Construction equipment rental companies face a different problem. Samsara tracks vehicles. It does not track an excavator's engine hours, attachment changes, or maintenance cycles the way an equipment rental business needs. Custom software handles all of that in one system.

Utility fleets — water, power, telecom — often need integration with work order management systems. A crew dispatched to a job site needs their vehicle tracked and their work order status updated in the same flow. Samsara integrates with some tools, but not at the depth these operators need.

Municipal fleet operators (city vehicles, police, fire) frequently have data sovereignty requirements. GPS data for law enforcement or emergency vehicles cannot live in a third-party cloud without strict controls. A self-hosted platform solves that.

Refrigerated transport companies need temperature monitoring alongside GPS. When a refrigeration unit fails at 2am on a cross-country haul, the operator needs one alert with one dashboard — not two separate systems.

Core modules to build

GPS tracking: the foundation

Every vehicle carries a GPS hardware device — Calamp, Orbcomm, or Teltonika are the common choices. These devices report location via MQTT or HTTP every 5 to 30 seconds depending on configuration. Each ping carries the vehicle ID, timestamp, latitude, longitude, speed, and heading.

Your backend stores every ping. At 100 vehicles reporting every 15 seconds, you are storing 576,000 records per day. At 500 vehicles, that is 2.88 million records per day. Standard PostgreSQL starts to struggle with range queries over this volume. TimescaleDB — a PostgreSQL extension that partitions data automatically by time — handles this workload at scale without rewriting your query patterns. Every GPS ping goes into a TimescaleDB hypertable.

The MQTT broker sits between the hardware devices and your backend. AWS IoT Core is the managed option. Mosquitto is the self-hosted option. The broker queues incoming messages and delivers them to your processing service. This layer matters for reliability: a spike in vehicle pings during morning dispatch should not drop data.

Real-time vehicle map

All vehicles plotted on a map, updated every 30 seconds. Color coding does most of the communication: green for moving, yellow for idle (engine on, speed zero), red for stopped or off. Click any vehicle to open a detail panel showing the driver name, current speed, last confirmed stop, and next scheduled stop.

Google Maps handles the base map. The vehicle markers are custom SVGs rotated to match heading. The map updates on a 30-second polling interval rather than persistent WebSockets — at 100 vehicles, polling is simpler to manage and the latency difference does not matter in dispatch workflows.

Store the current state of each vehicle in Redis. Redis gives you sub-millisecond reads for the vehicle detail panel and the map marker positions without hitting TimescaleDB for every page load.

Geofencing

Geofences are polygons or circles drawn on the map — customer sites, fuel stations, restricted zones, rest areas. When a vehicle enters or exits a geofence, the system fires a configurable trigger.

Three triggers drive real operational value. First: customer arrival notification. When a delivery truck enters a customer's geofence, the system sends an automated notification to the customer's operations contact. This replaces the "where is my driver" phone call. Second: unauthorized area alert. If a vehicle enters a restricted zone (a competitor's facility, a neighborhood with a weight limit), dispatch gets an alert. Third: automatic time-and-attendance recording. When a driver enters a job site geofence, the clock starts. When they leave, the clock stops. This feeds directly into payroll for hourly field workers.

Geofence evaluation runs server-side on every GPS ping. For each vehicle's new position, your service checks whether the point falls inside any active geofence using a point-in-polygon algorithm. At scale, index geofences spatially using PostGIS so you are not running geometry checks against every geofence in the database for every ping.

Driver safety scoring

Telematics events are captured from the GPS hardware. The key events: harsh braking (deceleration above 0.4g), harsh cornering (lateral acceleration above threshold), speeding (vehicle speed versus posted road speed limit), and rapid acceleration.

Speed limit data comes from HERE Maps, which provides road-segment-level speed limit data. For each GPS ping, your system queries HERE's road data to get the posted limit for that road segment, then compares it to the vehicle's reported speed.

Each event gets recorded with a severity score. A driver scorecard aggregates events per driver per week — total events, events per mile (normalizes for drivers who cover more distance), and a composite score. Managers see the leaderboard. Drivers see their own score in the mobile app.

Insurance companies are increasingly requiring this data. If your clients operate commercial fleets, the driver scorecard report becomes a tool for negotiating insurance premiums.

Hours of Service compliance

FMCSA requires electronic logging devices for commercial trucks in the US. HOS rules define daily driving limits (11 hours driving in a 14-hour window), weekly limits (60 or 70 hours in 7 or 8 days), and mandatory rest periods. The system tracks four duty statuses: driving, on-duty not driving, off-duty, and sleeper berth.

Every status change gets timestamped. The HOS module calculates remaining drive time and on-duty time in real time. Violations are flagged before they happen — not after. A driver approaching their 11-hour limit sees a warning at 10 hours.

ELD certification is a separate track from building the software. If you are selling to regulated carriers, your device and software combination must be registered with FMCSA as a certified ELD. That process includes self-certification, specific data transfer requirements, and ongoing compliance responsibilities. Build the HOS feature first, then pursue ELD certification as a go-to-market step — not a day-one requirement.

Driver Vehicle Inspection Reports

Pre-trip and post-trip inspections are a federal requirement for commercial vehicles. The driver app presents a checklist: lights, brakes, tires, mirrors, fluid levels. The driver taps through each item, marks defects, and submits. If a defect is noted, the system creates a maintenance ticket and notifies the fleet manager. The mechanic reviews, addresses the defect, and clears it in the system. The DVIR history is stored and auditable.

This module is straightforward but often skipped in MVP planning. Do not skip it. Regulators look at DVIR records during audits. Operators who do not have DVIR in their software keep paper logs, which means the paper and the digital records never match.

Dispatch

Dispatch connects the driver and the dispatcher in one workflow. The dispatcher creates a job: pickup location, delivery location, notes, priority. The job is assigned to a driver. The driver app shows the job queue. The driver navigates to pickup, taps "Confirm Pickup," navigates to delivery, taps "Confirm Delivery," and collects a signature on the phone screen. The dispatcher sees status updates in real time.

Two-way messaging between dispatch and driver is built into the same interface. Not SMS — in-app messaging, logged to the trip record.

Fuel tracking

Fuel card integration (WEX and Comdata are the two major networks) pulls transaction data automatically: date, vehicle, gallons, cost, location. Manual fuel entry is the fallback for fleets without fuel cards.

The reporting layer calculates cost per mile per vehicle, total fuel spend by vehicle over any date range, and month-over-month trend. Outliers — a vehicle with unusually high fuel cost per mile — surface quickly. Often the cause is a maintenance issue, sometimes it is a behavior issue. Either way, the data makes it visible.

Tech stack

Dispatcher dashboard: React. Single-page application with real-time map, table views, and reporting dashboards.

Driver app: React Native. Cross-platform for iOS and Android. Handles job queue, navigation deep-links (Apple Maps or Google Maps), DVIR checklists, signature capture, and messaging.

Backend: Node.js. REST API for the dashboard and driver app. Separate MQTT consumer service for ingesting GPS pings from hardware devices.

GPS data storage: TimescaleDB. PostgreSQL extension optimized for time-series data. Automatic partitioning by time bucket. Handles the ping volume without custom sharding.

MQTT broker: Mosquitto (self-hosted) or AWS IoT Core (managed). AWS IoT Core is easier to operate at scale; Mosquitto gives you more control if data sovereignty is a requirement.

Operational data: PostgreSQL. Drivers, vehicles, jobs, geofences, DVIR records, fuel entries.

Real-time vehicle state: Redis. Current position, status, and speed for every vehicle. Updated on each ping. Served directly to the map UI.

Mapping: Google Maps API for the vehicle map and dispatcher interface. HERE Maps API for road speed limit data used in driver safety scoring.

Spatial indexing: PostGIS extension on PostgreSQL for geofence geometry storage and point-in-polygon queries.

Timeline and cost

Timeline: 18 to 22 weeks. The extended timeline compared to standard SaaS products comes from three factors: GPS hardware provisioning and testing, MQTT broker configuration, and TimescaleDB schema design and query tuning. Each of these requires hands-on testing with real devices before the software is reliable.

A typical phasing: weeks 1 to 6 cover the data pipeline (MQTT, TimescaleDB, GPS ingestion), weeks 7 to 12 cover the core dashboard modules (map, geofencing, vehicle management), weeks 13 to 18 cover the driver app and dispatch, weeks 19 to 22 cover HOS, DVIR, fuel tracking, and reporting.

Cost: $180,000 to $280,000. The range reflects fleet size (more vehicles means more load testing), whether ELD certification is in scope, and the complexity of integrations (fuel card APIs, work order systems). Ongoing hosting and infrastructure runs $3,000 to $6,000 per month at 100 to 500 vehicles.

Build versus buy

Buy Samsara if you need AI dashcam features, the Samsara Partner Ecosystem, or your fleet is under 50 vehicles and your workflows are standard. Samsara is genuinely good software for the majority of fleet operators.

Build your own if you have specific requirements Samsara cannot meet: proprietary routing logic baked into dispatch, specialized vehicle types with non-GPS sensor data, data sovereignty constraints, or integration with a work order or ERP system that requires deeper access than Samsara's API provides. At 100 vehicles, the subscription cost alone is $32,400 to $39,600 per year. Over 8 years, that is the full cost of the custom build — before accounting for the features you are not getting from the generic platform.

The decision is rarely purely financial. It is about whether the software can actually support the operation.