Installer and customer apps
Two very different users share one codebase: the installer who touches the app for ninety seconds per device, and the customer who opens it for years afterwards. Designing for both at once is the interesting part.
Provisioning is where fleets get lost. If the installer flow has six screens and needs signal, devices get half-commissioned, records go missing, and someone drives back out to a site that is four hours away.
What the work actually involves
The installer app
- Scan, claim and configure over BLE with no cloud connection required
- Queued commissioning records that sync when the van reaches coverage
- Signal and placement check before the installer leaves the roof
- Photo and location capture attached to the device record automatically
- Big targets, high contrast, one-handed operation with gloves on
The customer app
- Current state and history for the devices that person is allowed to see
- Push notifications tied to the same rules engine the console uses
- Household or site sharing with sensible permission defaults
- Offline-first reads so the app still opens something useful on a train
- One codebase, both stores, with the release pipeline set up for your team
What you get to keep
- React Native application with store submission configured
- BLE provisioning protocol documented on both sides
- Offline sync strategy with the conflict rules written down
- Field trial report from real installers, not from the office
Because these apps are mostly forms, lists and a BLE session. Two native codebases doubles the cost for very little gain at this scope. Where a specific capability needs native code we write a small module and keep everything else shared.
What this normally sits next to
These capabilities come up in almost every engagement that includes the one above.
Device firmware and edge software
Sensor drivers, power budgets, local buffering and store-and-forward for sites with bad connectivity. Signed over-the-air updates from the first prototype, not bolted on later.
React operator consoles
The screen your team actually uses: live fleet map, per-device history, alarm rules, firmware rollouts and role-based access. Built for a shift supervisor on a ten-year-old browser, not for a demo.
Talk to the engineers who do this work
The first call is with whoever would lead the build, not an account manager. Bring the constraint you think is going to be a problem.