Web and mobile apps that run your IoT systems
Bespoke dashboards, portals and mobile apps to monitor and control connected devices, for the people who run, use and pay for them.
In short
A connected product is only as good as what people can do with it. We design and build the bespoke web and mobile apps that control IoT systems: fleet dashboards for operations teams, portals for customers and partners, and mobile apps that put a device's status and controls in someone's pocket. Because we also build the firmware and the cloud, every screen is designed around the data the devices really send and the commands they really accept, not guessed at from a spec.
What we build
Everything a person touches
The screens are where a connected product earns its keep. These are the pieces we design and build, on their own or together.
- 01
Operations dashboards
Live status, usage and alerts across every device, site and region, so an operations team sees the whole fleet at a glance and knows where to send someone.
- 02
Mobile apps
Cross-platform apps built with Flutter from a single codebase for iOS and Android: balances, status, alerts and controls, where your users already are.
- 03
Customer and partner portals
Secure portals where each customer, store or estate sees only its own devices and data, with the accounts and roles behind them.
- 04
Notifications that arrive in time
Warnings designed to be acted on, like Unimet's low-credit warnings, which arrive days ahead rather than when the lights go off.
- 05
APIs and integrations
Typed APIs between devices, cloud and apps, plus connections to the payment, email and reporting services your business already runs on.
- 06
Design systems
One shared set of components, colours and rules, so every screen behaves the same way and the product still feels like one thing as it grows.
End to end
One team, from the chip to the screen
Most app agencies start where the API ends. We start at the device. One team builds the firmware, the cloud and the app, so every screen is designed around what your devices can actually tell your users.
That is what lets us build things like a resident app that tops up a prepaid meter in seconds, a portal where each customer sees their own usage and statements, or a dashboard that tells your operations team which device needs a visit before anyone complains. When a device goes quiet, the app says what happened in plain words, not an error code.
We build for the people on both ends: your customers on their phones, your staff in the field and your team at a desk. And we stay on after launch, so new features ship without breaking what people already rely on.
How we build
Engineered to be trusted
Apps on connected products handle money, access and data that people rely on. These practices are built into every one.
- 01
Secure by default
Passwords are hashed with scrypt, sessions and tokens are stored hashed, security headers are on, and every callback from a payment or email provider is signature-checked.
- 02
Nothing lost, nothing doubled
Requests are idempotent, so a retry on a bad connection never charges or sends twice, and a transactional outbox makes sure no email or event is lost.
- 03
A full audit trail
Security events and financial movements are written to append-only logs that can be added to but never changed, so every action can be traced.
- 04
Tested and repeatable
Hand-written database migrations with automatic drift checks, end-to-end tests with Playwright, and containerised releases that run the same everywhere.
- 05
A working slice in days
Our prototype phase puts a live slice of the product in your hands, running on real device data, before you commit to a full build.
- 06
Documented as it's built
Documentation is generated from the code and kept current, and our engineers review it, so handover never means starting from scratch.
The Handee Method
From brief to fleet, in four steps.
Discover
We map the devices, the data they must produce, the systems they plug into and the conditions they must survive.
You get
A scoped build, a plan and a price.
Prototype
We build a working slice first: real firmware on real hardware, a live cloud and a first screen. You hold it in days.
You get
A working prototype on real hardware.
Build
We take it to production: device, cloud and apps, built in short reviewed loops, tested and documented as we go.
You get
Production firmware, cloud and apps.
Run
After launch we run the fleet: device health, anomalies, over-the-air updates and dashboards for your team.
You get
A live fleet, monitored and updated.
Related work
Apps we've built
Two platforms where the app is what people see and use every day.
Your app
Tell us what your users need to see
Tell us what your users need to seeA few lines is enough: who the app is for, what devices or data sit behind it and what exists already. We'll come back with an honest view of what to build first.
- 01Talk directly to the engineers who will design and build it
- 02One team for the app, the cloud and the devices behind it
- 03A clear next step, whether or not we end up working together
What happens next
- 01We read your briefWe come back to you, usually with a few questions about your users and your data.
- 02A first callWe talk through the journeys, the devices and what the app must never get wrong.
- 03A clear proposalScope, timeline and cost for a first phase, so you know exactly what you're committing to.
Questions
Web and app questions
What buyers usually ask us before an app project starts.
01Native or cross-platform: which should we choose?
For most connected products we recommend cross-platform. We build mobile apps with Flutter, so iOS and Android share one codebase and get new features at the same time. Where your app needs something a cross-platform framework handles poorly, we'll say so in discovery and explain the trade-off before you commit.
02Can the app talk to our devices directly, over Bluetooth?
It depends on the device and what the app has to do. Many products are better served by the app talking to the cloud, which already holds each device's latest state, while the device reports in over Wi-Fi or mobile data. Where direct pairing is the right call, for setup or where there's no signal, we plan it into the firmware and the app together, because we build both.
03What happens when users lose signal?
Connectivity is patchy in places, and loadshedding can take a site's network down with it. We decide early what must work offline, what can wait and how the app shows that data is out of date, so nobody is shown a stale reading as if it were live. Requests are idempotent, so a retry after a dropped connection never charges or sends twice.
04We already have devices in the field. Can you build just the app?
Yes. We start by understanding what the devices send today and how, whether over MQTT, AMQP or HTTP, or through a platform such as AWS IoT or ThingsBoard. If the data needs work before an app can use it well, we'll tell you, and because we also build firmware and cloud, we can fix it at the source rather than working around it.
05Do you publish the apps to the App Store and Google Play?
Store publishing is planned as part of the build, including the listings and the review requirements each store has, so launch day isn't held up by a rejection. We recommend publishing under your own developer accounts, so the listings stay in your hands, and we'll agree how that works with you at the start.
06Who hosts and supports the app after launch?
Every service is packaged in Docker containers, so it can run on the cloud that suits you, such as AWS, Azure or Railway. After launch, the Run phase of the Handee Method has us watching health, anomalies and updates, with our engineers accountable for it. The shape of ongoing support is set out in the proposal, so you know what's covered.
07How do you keep user data safe?
Security is built in from the start: passwords hashed with scrypt, sessions and tokens stored hashed, security headers on, and every callback from a payment or email provider signature-checked. Security events and financial movements go to append-only logs, so every action can be traced. We'll also work through where data is hosted and what POPIA asks of your product with you.