React operator consoles
An operator console is a tool, not a landing page. The person using it has eight hours of shift left and a specific decision to make. Everything on the screen either helps with that decision or gets cut.
Dashboards get built for the demo: every metric visible, everything animated, everything live. In production the operator wants to know which three of four thousand devices need attention right now, and the interface makes them hunt for it.
What the work actually involves
What we build
- Live fleet view with server-side filtering that stays fast at tens of thousands of rows
- Device detail with real telemetry history, proper zoom and export to CSV
- Alarm rules an operations lead can edit without a deploy, with acknowledgement and notes
- Firmware rollout control: cohorts, progress, failure rate and a visible stop button
- Roles, permissions and an audit trail that answers who changed the threshold at 3am
- Map view when geography matters, and no map at all when it does not
How we keep it fast
- Live only where live matters. A fleet table polls; a single device streams
- Virtualised lists so a four thousand row table renders like a forty row one
- Charts downsampled on the server, not in the browser
- Tested on a mid-range laptop over a throttled connection, because that is the reality
- Playwright end-to-end coverage of the paths an operator uses every day
What you get to keep
- React application in your repository, deployable from day one
- Storybook covering the component library and its states
- Playwright suite for the critical operator journeys
- Accessibility pass to WCAG 2.1 AA on the primary flows
- Design tokens shared with any other surface you run
Yes, and we prefer it. If you have tokens and a component library we build against them. If you do not, we produce a small one scoped to this product rather than importing a large third-party kit.
Where the work happens on a tablet in a van, yes — including offline-tolerant behaviour. We will ask in week one whether that is a real requirement or an assumption, because it changes the architecture.
What this normally sits next to
These capabilities come up in almost every engagement that includes the one above.
Installer and customer apps
Bluetooth provisioning flows an installer can finish in ninety seconds on a cold rooftop, plus the customer-facing app that comes after. One React Native codebase for both stores.
Node.js ingestion and services
An MQTT front door, a device registry, a rules engine and clean HTTP and WebSocket APIs. Written in TypeScript, sized to your message rate, and load tested with a simulated fleet before real hardware arrives.
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.