Custom Software for Transportation — Built for the Field, Built Real-Time, Built to Ship

Fleets do not pause for a clean schema. Vehicles stream GPS and engine telemetry continuously, drivers log Hours-of-Service against FMCSA rules, dispatchers reassign loads as conditions change, and customers expect a live tracking link that actually tracks. Off-the-shelf TMS software is rigid where you need flexibility and silent where you need an audit trail. A code base built by a contractor who has never handled an out-of-order GPS point will fall over the first time a truck drives through a dead zone.

We build for those realities from the first architecture diagram. Telematics lands on a streaming ingestion path and persists to a time-series store designed for high write volume. Position updates fan out to dispatcher dashboards and customer pages over WebSockets. Driver actions queue locally and sync when coverage returns. ELD and Hours-of-Service data is pulled from your certified provider and surfaced where safety staff can actually use it. The system stays correct when the network does not cooperate — because in transportation, it never fully does.

Most industries deal with request-response software and tidy database rows. Transportation deals with a moving physical fleet that never stops emitting data. A single mid-size operation streams position, engine-diagnostic (J1939/OBD-II), and ELD telemetry from every vehicle, every few seconds, all day. That is a time-series ingestion problem, not a CRUD app — and a naive schema with one row per ping buckles inside a quarter once you start querying historical movement or computing IFTA mileage across state lines.

The regulatory perimeter is specific and enforced. FMCSA and DOT set the rules: the ELD mandate, Hours-of-Service limits, DVIR (driver vehicle inspection reports), IFTA fuel-tax reporting, CSA safety scores, and hazmat handling where it applies. Passenger and transit operators add ADA paratransit and accessibility obligations on top. And the environment itself is hostile to clean engineering — trucks drive through cellular dead zones, telematics devices buffer and replay points, and your software has to stay correct when GPS arrives late, out of order, or in a burst after twenty silent minutes. We have wired telematics providers, handled the buffering, and built the HOS and routing surfaces repeatedly, and we know where the time gets eaten on a build.

FMCSA, DOT, and the ELD mandate. If you run commercial motor vehicles, the ELD mandate and Hours-of-Service rules apply. We do not certify ELD hardware — that is a device-vendor function. We build the operational layer: HOS status, available-hours logic, edit-request surfaces, and the reporting safety staff and DOT auditors expect, pulled from your certified provider's API.

IFTA and DVIR. The International Fuel Tax Agreement requires mileage-by-jurisdiction reporting, and we aggregate it from telematics data rather than odometer guesswork. Driver vehicle inspection reports (DVIR) get captured, stored, and tied to defect tracking so a roadside inspection or audit has a clean trail.

CSA scores and safety data. Compliance, Safety, Accountability scores ride on inspection and violation history. We surface the inputs — HOS violations, maintenance defects, inspection outcomes — so your safety team can manage the BASICs that drive the score rather than reacting after the fact.

Telematics and API security. Ingestion is an attack surface. Device tokens, webhook endpoints, and the API gateway need authentication, rate limiting, and replay protection. The live-location feed is a theft and stalking risk if exposed, so tracking links are scoped and signed. We harden the ingestion path the same way we harden any internet-facing API.

Account takeover and access control. Driver and dispatcher accounts are high-value targets — a compromised dispatcher can reroute freight or expose the whole fleet's movements. MFA on dispatcher and admin surfaces, role-based access, and audit logging on assignment and routing changes are wired in by default.

Hazmat and passenger accessibility. Hazardous-materials transport carries its own documentation and routing rules, and passenger or paratransit operations carry ADA accessibility obligations. We do not give legal advice — but we build the disclosure capture, manifest handling, and audit trails your compliance staff and counsel will need.

Next.js 16 on the App Router with React 19 and TypeScript end-to-end. Postgres for the system of record — usually Neon, Supabase, or RDS — paired with a deliberate time-series strategy for telematics: TimescaleDB or native partitioning so the firehose of position and engine pings stays queryable instead of grinding the database to a halt. Prisma or Drizzle as the type-safe ORM. Redis for live-location state and streaming fan-out, with WebSockets pushing updates to dispatcher dashboards and customer tracking pages. Routing and mapping through Mapbox, Google Maps, or HERE depending on coverage and cost.

Telematics providers — Samsara, Geotab, Motive — are integrated through their fleet APIs and webhooks, normalized into one model so downstream tools do not care which vendor a vehicle reports through. Background and routing jobs run on BullMQ over Redis or on Inngest, depending on the SLA — route optimization, IFTA aggregation, and nightly reconciliation all run off the queue. The driver app is React Native or an installable PWA, built offline-first so field actions survive dead zones. Sentry plus Datadog for observability, with PII-aware redaction on location data in the logs. The web tier deploys to Vercel; the ingestion and data plane run in a hardened VPC when the volume or security posture calls for it.

Three patterns repeat. First, teams store one database row per GPS ping in a vanilla table and watch query times collapse within months. Historical movement reports, IFTA mileage, and replaying a trip become impossible without a rewrite. Telematics is a time-series workload — partition or use a purpose-built store from the start, not after the database is on fire.

Second, the driver app is built assuming a live connection. The first time a truck spends thirty minutes in a dead zone, proof-of-delivery is lost, status updates vanish, and the dispatcher is flying blind. Field software has to be offline-first — actions queue locally, sync on reconnect, and resolve conflicts sanely. Treating connectivity as guaranteed is the single most expensive assumption in transportation software.

Third, operators overscope the first release. A new platform gets pitched with route optimization, three telematics providers, customer tracking, IFTA reporting, and a paratransit module all at once. The realistic build is one workflow — dispatch with live tracking — shipped in eight weeks, run by real dispatchers, and learned from. We push hard for that scoping discipline because the alternative is a 9-month build that ships late and matches nobody's actual operation.

What gets a fleet operator in trouble is rarely a cosmetic bug. It is the laptop in another country with your routing logic and customer locations on it, or the live-tracking endpoint left wide open so anyone can watch every vehicle move. Movement data is sensitive — it reveals where your customers are, where your trucks are, and where the cargo sits. That is precisely why we are US-based, founder-led, and engagement-first on every project.

William Beltz writes or reviews every line of code that touches your fleet data, your dispatch logic, or your tracking surfaces. NDAs are mutual and signed before discovery. Source code lives in your GitHub organization, not ours. The handoff is documented for either ongoing collaboration or in-house ownership — your call.

Fleet platforms expose surfaces most web apps do not: a telematics ingestion pipeline taking webhooks and device feeds, a live-location API, and driver and dispatcher accounts that control physical assets. We run web application pentests and full-scope penetration testing against the app, the APIs, and the ingestion path — testing for account takeover, broken access control on tracking links, replay and injection on device feeds, and the data-exposure risks specific to a moving fleet.

For operators running their own network and ingestion infrastructure, network penetration testing covers the perimeter and internal segmentation between IT and the OT-adjacent telemetry plane. Findings map to concrete remediation, and ongoing coverage is available through managed security services so the pipeline stays watched after launch, not just at assessment time.

The ingestion-and-fan-out pattern. Telematics and GPS feeds land on a streaming path, get written to a time-series store (Timescale or partitioned Postgres) for history, and simultaneously push live state through Redis to WebSocket subscribers — dispatcher dashboards and customer pages. Writes are idempotent so a device replaying buffered points after a dead zone does not corrupt the trail. This is the backbone of every real-time fleet build we ship.

The provider-abstraction pattern. Rather than coupling the app to Samsara or Geotab directly, we normalize every provider into one internal model for position, engine diagnostics, and ELD events. Adding a provider — or migrating off one — becomes an adapter change, not a rewrite, and downstream dispatch, tracking, and reporting code never has to care which vendor a given vehicle reports through. It complements the warehouse and freight-side concerns covered on our logistics page.

The offline-first field pattern. The driver app treats the network as unreliable by default. Trip data caches locally, proof-of-delivery and status changes queue in a durable local store, and a sync engine reconciles on reconnect with clear conflict resolution. The result is software that keeps working through the dead zones every real route contains, then catches the back office up the moment coverage returns.