Building the App Around a Transportation or Fleet Product

A fleet app fails differently from a consumer app. Nobody rates it in an app store, the person using it did not choose it, and it runs in a moving steel box with intermittent cellular coverage, a phone mounted on a windshield in direct sun, and a user whose hands are supposed to be on the wheel. If your product is a telematics unit, a trailer sensor, a refrigeration controller, a dash camera, an EV charger, or a piece of aftermarket vehicle hardware, the app is not a companion feature. It is how the product delivers most of its value, and it is usually where the schedule and budget go.

This article covers what actually changes when a product app has to live in a vehicle and a fleet operation.

You Are Not Building One App

The single most common planning error is scoping a fleet product as "an app." Transportation products almost always need three or four distinct interfaces, because the people involved have nothing in common except the vehicle.

Trying to serve all of these from one build produces an app that is cluttered for the driver and underpowered for the dispatcher. The split between the everyday user interface and the service interface is worth deciding at the start, and the tradeoffs are laid out in when you need both a user app and a technician app.

Background Location Is the Hard Platform Problem

Almost every transportation app needs position while the app is not in the foreground. Both mobile platforms treat that as a privileged capability, and getting it wrong is the most common cause of a fleet app that "loses trips."

On iOS, continuous background location requires the Always authorization, which the user must grant through a two-step prompt, plus the location background mode in the app's capabilities. Apple reviews the justification, and an app that requests Always without a clear operational reason gets rejected. On Android, the equivalent path is a foreground service with a location service type, a persistent notification the user cannot dismiss, and a separate background location permission that Google Play reviews with a required demonstration video. Both platforms also aggressively suspend apps to save battery, so any design that assumes a timer will fire reliably in the background is wrong.

Practical guidance:

• Design the permission request flow as a product feature, with an explanation screen before the system prompt. Denial rates drop sharply when users understand why.
• Never depend on background execution for correctness. Buffer on the device and reconcile on the server.
• Use significant-change and geofence triggers where full-rate tracking is not required. Continuous GPS at one-second intervals will drain a phone in a few hours.
• Expect enterprise deployments to configure battery-optimization exemptions through mobile device management, and document how.

The permission mechanics for both location and Bluetooth are covered in more detail in what iOS and Android ask users for Bluetooth and location.

Offline Is the Normal State, Not the Exception

Rural highways, parking garages, loading docks, tunnels, and border crossings all produce dead zones lasting minutes to hours. A fleet app that requires connectivity to record an event will lose data every single day.

The architecture that works is store-and-forward with a local database: every event is written locally first with a device timestamp and a monotonic sequence number, then synced opportunistically. Two details matter more than they appear to. First, the device clock is not trustworthy, so records need both the device time and the server receipt time, and the server must be able to reconcile them. Second, conflicts are inevitable when a dispatcher reassigns a job while the driver's phone is offline; decide the resolution rule up front rather than discovering it in the field. The general patterns are covered in offline mode in a companion app.

Getting Data Out of the Vehicle

The app is only as good as its data source, and there are three common ones.

OBD-II dongles

Cheap, self-installed, and universal on light-duty vehicles. Limitations are real: the data available varies by manufacturer, some parameters require proprietary requests, dongles can be unplugged by drivers, and a poorly designed device can keep the vehicle bus awake and drain the battery.

Heavy-duty bus access

Commercial trucks use SAE J1939 over a nine-pin or type-two connector, with a much richer and better-standardized parameter set than light-duty OBD. If your product serves Class 7 and 8 vehicles, plan for J1939 specifically rather than assuming OBD-II compatibility.

Purpose-built hardware

A hardwired telematics unit with its own GNSS receiver, accelerometer, and cellular modem removes the dependency on the driver's phone entirely and lets the app become a thin client over your own backend. Positioning accuracy, antenna placement, and receiver selection are decided at this stage, and the tradeoffs are covered in GPS tracking device design. The wider vehicle-environment requirements, including temperature range, vibration, and load dump on the power rail, are covered in automotive electronics development.

Compliance Changes the Requirements

If your product touches regulated commercial vehicles in the United States, the app inherits federal requirements that are not negotiable.

• Electronic logging. FMCSA rules under 49 CFR Part 395 require most commercial drivers to record hours of service electronically. The device must meet a detailed technical specification, and the manufacturer self-certifies and registers it with FMCSA. Data transfer to roadside inspectors must work by the prescribed methods. This is a serious engineering scope, not a screen.
• Driver distraction. 49 CFR 392.82 restricts handheld mobile phone use by commercial drivers while driving. Your driver interface must be operable with a single touch or by voice while the vehicle is in motion, or it must lock out entirely above a speed threshold. Build the lockout; do not rely on policy.
• Inspection reports. Driver vehicle inspection reports are a common companion feature, with photo capture and defect workflows that must survive offline operation.
• Fuel tax reporting. Interstate operators need mileage by jurisdiction for IFTA, which means your position data has to be accurate enough to attribute miles to the right state.

What Fleet Managers Actually Buy

The reporting layer sells the product. Utilization, idle time, cost per mile, driver safety scoring, and maintenance due are the metrics fleet managers use to justify the purchase internally. Maintenance in particular converts sensor data into money saved, and building that well is a data problem rather than an app problem, described in turning product data into failure warnings. At scale, the operational burden shifts to managing the devices themselves, which is its own discipline covered in IoT fleet management.

Alerting deserves specific design attention. A fleet product that sends a notification for every event trains users to ignore all of them. Thresholds, batching, quiet hours, and escalation rules belong in the requirements document, not in a later release, and the mechanics are covered in push notifications from a connected device.

Budget and Timeline

A driver app plus a dispatcher web console plus a backend is not a small project. A realistic first release with live tracking, assignment, offline capture, and basic reporting runs roughly six to ten months and $120,000 to $400,000 depending on how much of the compliance scope is included. Adding certified electronic logging can add several months and a significant testing burden on its own. Cellular data, map tiles, and cloud costs then run monthly per vehicle for the life of the product, which needs to be in the pricing model from day one.

Projects House builds connected products end to end, including the vehicle hardware, the firmware, the driver and dispatcher applications, and the backend that ties them together. Tell us about your fleet product through our contact form.