Should you build a companion app for your hardware product?

We build both halves of this — firmware and the app that talks to it — so we see the decision from both sides. And the pattern is consistent: companion apps split cleanly into ones that made the product better and ones that became a permanent tax on the business.

Four questions decide which you are about to build.

1. Does the app do something the device genuinely cannot?

This is the question that eliminates most bad companion apps. There are four honest reasons for one to exist:

• Display. The device produces data too rich for onboard controls — a graph, a history, a live readout. A screen in your pocket is cheaper than a screen on the product.
• Configuration. There are more settings than physical buttons can reasonably express. Anyone who has configured a device by holding two buttons and counting LED flashes knows the value here.
• Updates. Firmware needs to reach devices already in the field. This one alone often justifies the build.
• Connectivity. The device needs the internet and has no radio of its own; the phone is the bridge.

If your reason is not on that list — if the app mostly mirrors buttons the device already has — you are adding cost, a support channel, and a permanent obligation in exchange for a screenshot on the packaging.

2. Can the product still do its job with no phone nearby?

The answer must be yes. Phones get left behind, run flat, get replaced, and eventually stop being able to install your app at all. If the hardware is inert without it, you have coupled the lifespan of a physical product to the lifespan of a software platform you do not control.

The rule that follows: push logic into the firmware. Anything the device can decide alone keeps working forever. The app should be a window onto the device, not its brain. This is also the cheaper architecture, because firmware you ship once outlives several generations of mobile OS.

3. Have you budgeted for Bluetooth being harder than the demo?

BLE has an easy happy path, which is exactly what makes it dangerous to estimate. Connecting to a device sitting on the desk with the app in the foreground works almost immediately. Then the real work starts:

None of this is exotic; it is simply where the hours are. An estimate built on the desk demo will be wrong by a multiple. This is also the case where cross-platform frameworks stop saving money: debugging BLE edge cases through an abstraction layer routinely costs more than writing the connection layer natively twice.

4. Are you prepared to maintain it for as long as you sell the hardware?

This is the question that gets skipped, and it is the expensive one. An app is not a deliverable; it is an ongoing obligation:

• iOS and Android ship major versions every year, and periodically break assumptions your app relies on.
• App stores change submission requirements and privacy declarations on their own schedule.
• Signing certificates and provisioning profiles expire.
• An app left untouched for two years may simply stop being installable.

If your hardware has a five-year sales life, you are committing to five years of app maintenance. That is entirely manageable when it is planned — a retainer, or at minimum an annual compatibility pass — and genuinely painful when it arrives as a surprise, usually as a support ticket saying the app no longer opens.

What good looks like

The companion apps that work share a shape: the device is fully functional alone; the app makes it better at something specific; the connection layer is treated as the hard part and budgeted accordingly; and maintenance is a line item from day one rather than an afterthought.

That is roughly the shape of the racing ECU work — the engine management system does its job with no phone present, and the app exists because half-second live telemetry is something no dashboard readout could show. The app adds a capability rather than relocating one.