Software That Lives in a Truck: What Changes When Your App Ships Inside a Vehicle

A consumer app has a generous safety net. If it hangs, the user closes it. If a release is bad, you ship a fix in hours. If connectivity drops, you show a spinner and wait — the user is standing still, holding a phone, and will forgive you.

None of that is true in a vehicle.

The screen in a truck cab can’t be closed and reopened. The device may be hours from a usable network. The person using it is driving, or loading, or wearing gloves in the rain. And the vehicle will still be on the road in fifteen years, long after the phone in your pocket has been recycled twice.

We’ve built in both worlds — the unified digital layer for Battle Motors covering configuration, tracking and management of next-generation electric trucks, and the real-time battery monitoring platform for Romeo Power surfacing health, voltage, temperature and charge-cycle data for an EV battery manufacturer. Here’s what’s genuinely different.

Offline isn’t an edge case, it’s the architecture

Consumer apps treat connectivity loss as an exception state. Vehicle software treats connectivity as an occasional bonus.

Trucks operate in yards with no signal, on routes through dead zones, inside depots with metal roofs. If your application needs the network to function, it doesn’t function.

That inverts the design. Data is captured and stored locally as the normal path, and synchronised opportunistically when a connection appears. Which means confronting the genuinely hard questions early: what happens when the same record is edited in the cab and in the back office while they’re disconnected? Which side wins, and can you explain that rule to an operations manager? How much history does the device hold before it starts discarding, and what does it discard first?

These aren’t features you add in a later sprint. They shape the data model, and retrofitting offline-first onto an online-first application is close to a rewrite.

You are a guest on someone else’s hardware

Vehicle software runs on hardware chosen for cost, durability and supply chain — not for your framework’s convenience. Modest processors, limited memory, storage with real write-cycle limits, and a screen specified for daylight visibility and glove operation rather than pixel density.

Working on AOSP rather than consumer Android changes the posture too. You get deeper control — boot behaviour, system-level integration, lifecycle management — and in exchange you own responsibilities the consumer platform normally handles for you.

The most valuable habit here is engaging the hardware team early and treating their constraints as fixed inputs rather than negotiable preferences. Romeo Power’s feedback on our IoT work for their Saber power packs came down to exactly that: understanding the hardware constraints, and shipping on time because of it rather than despite it.

Power cycles are the normal shutdown

Phones are rarely fully powered off. Vehicles are switched off constantly, sometimes mid-operation, sometimes mid-write.

So every write has to be safe to interrupt. Anything held only in memory is assumed lost. Startup has to be quick — a driver isn’t waiting ninety seconds for a boot sequence before they can work — and it must recover cleanly from an unclean shutdown, every time, without a technician.

“Have you tried restarting it?” is not a support strategy when the device is in a truck two hundred kilometres away.

Updates are a logistics problem

Shipping a fix to a consumer app is a store submission. Shipping a fix to a fleet is an operation.

Vehicles are distributed, often offline, and out of contact for long stretches. Updates have to be delivered over the air, resume after interruption, verify integrity before applying, and — critically — roll back cleanly if something goes wrong. A failed update that bricks a display costs a service visit and a vehicle out of use.

There’s a fleet-management dimension too: staged rollouts so a bad release reaches ten vehicles rather than a thousand, and version reporting so you know what’s actually running out there rather than what you think you deployed.

Telemetry is the product, not the instrumentation

In most software, telemetry exists so engineers can debug. In vehicle systems, the data frequently is the value.

Battery health, voltage, temperature and charge-cycle history aren’t developer diagnostics — they’re what lets a manufacturer understand performance in the field, anticipate failures, and support warranty decisions with evidence. That changes the engineering: the pipeline needs to be reliable, the timestamps trustworthy, the data structured for analysis rather than log-scraping, and the volume manageable when thousands of units report continuously.

Design the data model for the questions the business will ask in two years, not just the dashboard someone specified this quarter.

Everything lives longer

This is the difference that catches software teams out most.

Consumer software has a short horizon. A commercial vehicle is a fifteen-to-twenty-year asset. The software in it will outlive the framework versions it was built on, probably the hardware revision it shipped with, and quite possibly the team that wrote it.

That argues for boring, well-understood technology choices, minimal exotic dependencies, genuinely thorough documentation, and clean separation between the parts tied to specific hardware and the parts that aren’t. The clever solution that requires a specialist to maintain is a liability on a decade-long horizon.

Why it’s worth doing

None of this is an argument against building in-vehicle software. It’s an argument for going in clear-eyed, because the constraints are unusually unforgiving and unusually rewarding — the resulting systems do real work in the physical world, and they last.

The teams who struggle are the ones who approach a truck like a phone with a bigger screen. The teams who do well start from the constraints and design outward.

---

Building for vehicles or connected hardware? See our automotive and EV work, how we build mobile and embedded, or tell us what you’re building.