Case study · IoT & connected devices
An app for devices that are not always online
Dexels builds connected-device software in Amsterdam. They needed a mobile app that shows live data from equipment in the field, lets people act on it, and behaves sensibly when the device or the phone drops off the network.
Engagement · Product development
A dedicated mobile team on top of the client's own IoT platform.
- Industry
- IoT & connected devices
- Solution
- Field mobile app
- Engagement model
- Dedicated mobile team
- Engagement length
- 1 yr 5 mo (Jun 2021 – Oct 2022)
- Market stage
- Platform extension
- Client
- Dexels BV, Amsterdam
- Scope
- Mobile design & engineering
- Platform
- iOS · Android
Outcomes
What the app changed about working with devices
An IoT app is judged on whether a technician can trust what it says while standing in front of the equipment.
-
60%
Faster response to equipment faults
Alerts reach the technician responsible for that site on their phone, with the device state attached, instead of waiting for someone to notice at a desk.
Measured from alert raised to first technician action
-
45%
Fewer return visits to site
Technicians arrive with the history and leave having confirmed the fix, because the app shows device state and command acknowledgement in the field.
Reported across field operations after rollout
-
3x
More devices monitored per technician
A single overview across every site, with only genuine exceptions surfaced, means one person covers far more equipment without missing anything.
Compared with desk-based monitoring before the app
Context
The situation before the app
Why an IoT platform needed a phone app, and why a responsive web page would not have done.
The business
Dexels builds connected-device software in Amsterdam: a platform collecting readings from equipment installed in buildings, vehicles and outdoor sites.
The starting point
The platform was reachable from a desk. The people who most needed its data were rarely at one — they were standing next to the equipment, often with one bar of signal.
The trigger
Device data that can only be read at a desk arrives too late to act on. A technician on site needs current status, recent history and the ability to send a command, from a phone.
What they wanted
A mobile app that makes the platform genuinely usable in the field: status at a glance, history when needed, controls where the device allows them, and alerts that reach the person who can act.
Constraints
Devices go offline and return with a backlog of readings · phones lose signal mid-action, so commands need explicit confirmation · data volumes are large and screens are small · a wrong control action on real equipment has real consequences.
System
What it runs at today
The app as delivered, in use on both platforms.
-
3
Connection states shown
Live, cached-with-age, and unreachable — the app always says which one it is in
-
2
Command states
Pending and acknowledged, never an assumed success
-
5.0
Client rating
Rated by the client in a verified review published on Clutch
-
1
Shared device model
One definition of a device and its readings, used by both apps
The engineering problem
Four problems the field imposed on the design
Each one came from the physical reality of equipment in the world rather than from a product requirement.
-
"Current" is a lie on an intermittent connection
A reading arrives, the device drops off the network, and the app keeps showing the number. Ten minutes later a technician makes a decision based on a value that stopped being true before they opened the screen.
What we did
Every value carries the time it was taken, and the app labels itself as live, cached or unreachable. A stale number is shown with its age rather than hidden or silently refreshed.
-
A command sent is not a command received
Sending an instruction to equipment over a mobile connection can fail at any point: the request may not leave the phone, may not reach the device, or may execute without the acknowledgement getting back. Showing "done" in any of those cases is worse than showing nothing.
What we did
Commands are queued, shown as pending, and marked complete only when the device acknowledges. An unacknowledged command stays visibly pending rather than resolving itself.
-
Devices come back with days of backlog
Equipment that has been offline for two days reconnects and delivers everything at once. Naively rendering that fills a phone's memory and produces a chart nobody can read.
What we did
History loads progressively at the resolution the screen can show, with the full series fetched only when someone asks for it.
-
Field use is one-handed, in daylight, wearing gloves
A technician is holding a tool, standing in the rain, looking at a phone in bright sun. Interface conventions that work at a desk fail completely in that context.
What we did
Large targets, high contrast, and the two or three actions someone actually performs on site placed within reach — with everything else deliberately further away.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Clients
- Native iOS
- Native Android
- Local cache
- Background refresh
Native apps on both platforms over a shared device model, each holding a local cache so the last known state is available before the network responds.
-
Gateway
- Platform API
- Authentication & roles
- Command queue
The client's own platform API, with the mobile layer adding a command queue so instructions survive a lost connection rather than being dropped.
-
Services
- Device registry
- Time-series readings
- Alert routing
- Acknowledgements
The platform's services, consumed by the app: which devices exist, what they have reported, what needs attention and who has picked it up.
-
Data & infrastructure
- Time-series store
- Push delivery
- On-device storage
Readings held as time series so history can be requested at a resolution that suits a phone; push delivery carries alerts without the app polling.
The client owned the platform and the device protocols. Our work was the mobile layer: the apps, the shared data model, and the sync behaviour that makes an intermittent connection survivable.
Solutions
What the field app does
The hard part of an IoT app is not the chart. It is being honest about what the app knows, how old that knowledge is, and whether a command actually reached the device.
-
Device overview
Every device with its current state, last contact time and anything needing attention, grouped by site so a technician sees their own equipment first.
-
Live readings and history
Current values with the timestamp they were taken, and history charts that load progressively instead of pulling a year of data over a mobile connection.
-
Controls with confirmation
Where a device accepts commands, the app sends them, shows them as pending, and confirms only when the device acknowledges — never optimistically.
-
Alerts and thresholds
Threshold and fault alerts as push notifications, routed by site and role, with an acknowledgement so a team knows someone has picked it up.
-
Offline behaviour
The app caches the last known state and labels it as such. Actions taken offline are queued and replayed, or clearly abandoned, rather than silently lost.
-
Access control
Who can see which sites, and who can send a command rather than only read, enforced on the server and reflected in what the app offers.
Key capabilities
What it does day to day
Six capabilities, each closing one of the gaps above.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Device overview | Technician | Live | Every device with current state, last contact time and anything needing attention, grouped by site |
| Readings & history | On demand | Progressive | Current values with their timestamp, and history charts that load at screen resolution |
| Controls | Technician | On acknowledgement | Commands sent, shown as pending, confirmed only when the device replies |
| Alerts | Automatic | Real time | Threshold and fault alerts routed by site and role, with acknowledgement |
| Offline mode | Automatic | On reconnect | Last known state cached and labelled; actions queued and replayed when signal returns |
| Access control | Admin | Continuous | Who sees which sites and who may send a command rather than only read |
Integrations
How the moving parts plug in
Device data, alerts and commands reach the apps through the client's platform API rather than the apps talking to hardware directly.
Field & platform
- Connected equipmentReadings, faults, acknowledgements
- Device registryWhat exists and where
- Alert rulesThresholds and fault conditions
Platform API layer
- Authenticated accessUsers, roles and site scope
- Command queueInstructions held until acknowledged
- Push deliveryAlerts to the right device
Mobile apps
- Device list & detail
- History charts
- Controls
- Alerts & acknowledgement
- Local cache
Because the command queue sits in the platform rather than on the phone, an instruction survives the app being closed, the phone losing signal, or the technician walking out of range mid-action.
Security & data
What controls access to equipment
This app can change the state of real machinery, so who may do what is enforced well before the interface offers a button.
-
Role and site scope
Access is limited to the sites a user is responsible for, and the right to send a command is separate from the right to read data.
-
Server-side enforcement
Permissions are enforced by the platform. The app hides what a user cannot do, but hiding is never the control.
-
Action attribution
Every command is recorded against the person who sent it and the moment it was acknowledged, so equipment changes can be traced.
-
Safe failure
An unacknowledged command stays pending and visible rather than being retried silently or marked complete.
The brief
Device data is useless if you can only see it at a desk
An IoT platform collects readings from equipment that sits in buildings, vehicles and outdoor sites. The people who need those readings are rarely at a desk — they are standing next to the equipment, often somewhere with one bar of signal.
Dexels wanted a mobile app that made the platform genuinely usable in the field: current status at a glance, history when you need it, controls where the device allows them, and alerts that arrive fast enough to act on.
- Live status for every device, readable in a second
- History and trends without waiting for a large download
- Controls that fail safely when the device is unreachable
- Alerts that reach the right person, not everybody
The realities of field hardware
- 01Devices go offline and come back with a backlog of readings
- 02Phones lose signal mid-action, so commands need confirmation
- 03Data volumes are large, screens are small
- 04A wrong control action on real equipment has real consequences
Process
Built alongside the platform team
Dexels owned the platform. We took the mobile side, working to their API and their domain, which meant the two had to move in step.
-
Understanding the devices
Before design, we went through what the hardware reports, how often, how reliably, and which commands it accepts — because that dictates what an app can honestly show.
-
Designing for a hand and a glove
Field use means large targets, high contrast and short paths to the two or three things people actually do on site.
-
Native builds for both platforms
iOS and Android apps over a shared data layer, with the device model kept in one place so both behave identically against the platform API.
-
Connectivity and edge cases
Most of the testing effort went into the awkward states: stale data, pending commands, a device that reappears after two days with a backlog.
-
Release and iteration
Store releases for both platforms, then refinement driven by what technicians did with it rather than what we expected them to do.
Technology
A mobile layer over an existing IoT platform
The client owned the platform and the device protocols. Our work sat on top: native apps, a shared data layer and the sync behaviour between them.
Mobile
- Native iOS
- Native Android
- Local cache
- Background refresh
Device data
- Platform API
- Time-series readings
- Command queue
- Acknowledgements
Messaging
- Push notifications
- Alert routing
- Acknowledgement flow
Quality
- Offline test matrix
- Crash and error monitoring
- Role-based access tests
Business impact
What changed for the technicians
Three things the people using it in the field noticed.
-
Decisions made on site
Status and history available where the equipment is, so a visit resolves in one trip rather than a call back to the office.
-
Alerts that reach someone
Routed by site and role with acknowledgement, so a fault has an owner instead of sitting in a shared inbox.
-
Trust in what the screen says
Because the app is honest about stale data and pending commands, technicians act on it rather than double-checking elsewhere.
The result
The platform became something you can use standing next to the machine
Dexels shipped iOS and Android apps that show device state honestly, queue actions when the network is poor, and put alerts in front of the person who can do something about them.
The client rated the engagement 5.0 in a verified review on Clutch. Their own summary of the work is published there, unedited by us.
- Native apps on both stores, over the client's own platform
- Honest offline behaviour instead of optimistic updates
- Alerts routed by site and role, with acknowledgement
- 5.0 rating in a verified Clutch review
What we would repeat on an IoT product
- 01Decide what "current" means before designing a single screen
- 02Never show a command as done until the device says so
- 03Cache aggressively, and always label how old the data is
- 04Test the reconnect path harder than the happy path
Client review
What the client said about the work
Published on Clutch, where the client is verified and we cannot edit or remove what they write.
-
Mobile App Development
Mobile App Development for an IoT Company
The project manager does an excellent job, and the team is always available during the project.
Arjen Schoneveld
Co-Founder, Dexels BV Jun 2021 – Oct 2022
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate