Build · Pillar 01
Mobile apps for people who are not sitting at a desk.
Drivers, engineers, inspectors and warehouse teams are where the data actually comes from. If the app needs signal, needs two hands, or needs a login every morning, they will go back to paper — and they should.
What makes a business mobile app different from a consumer one?
A business mobile app is used under conditions a consumer app never faces: poor or absent signal, gloves, bright sun, shared devices, and a user who is paid to finish a job rather than to explore an interface. It therefore has to work offline, sync reliably when connectivity returns, and reduce the number of taps a task takes.
- Offline-first: the full job completes with no connection at all.
- Conflict-safe sync, so two devices cannot silently overwrite each other.
- Designed for one-handed use on a device that is not yours.
Why it matters
Field apps fail for predictable, physical reasons.
The pattern is consistent. An app is built, piloted in an office with full wifi, rolled out, and quietly abandoned within two months. Not because of a bug — because a driver lost signal in a steel-framed warehouse and the proof of delivery vanished, or because capturing one job took fourteen taps and paper took three.
Field software is judged by the person using it, and they judge it on a very short timescale. We design for the worst ten minutes of their day: no signal, cold hands, a queue behind them, and a device whose battery is at 8%.
Tested in the real conditions
Where apps actually break
We take builds into the environments they will live in rather than demoing them in a meeting room. These are the failure modes we design against from the start:
- Work is recorded on paper and keyed in again at the depot.
- Jobs completed in a signal dead zone are lost or duplicated.
- Proof of delivery or inspection cannot be produced on demand.
- The office does not know where a job stands until the driver returns.
- The app logs out overnight and nobody remembers the password.
- Photos are taken on a personal phone and sent by WhatsApp.
Scope
What a field app build covers.
The offline and sync work is the bulk of the engineering. Anyone quoting a field app cheaply has almost certainly left it out.
-
iOS & Android build
One codebase where that is right for you, native where the hardware demands it. We will explain the trade-off rather than defaulting to whichever we prefer.
-
Offline-first data layer
A local database that holds the full working set, so every job can be completed with the device in flight mode and nothing is lost.
-
Conflict-safe synchronisation
Queued, retrying, idempotent sync with an explicit conflict policy, so two devices editing the same job produce a defined outcome rather than a silent overwrite.
-
Device hardware
Barcode and QR scanning, camera with annotation, signature capture, GPS, NFC and Bluetooth scales or printers where the job needs them.
-
Device & identity management
Shared-device sign-in that suits shift patterns, MDM-friendly deployment, remote wipe and biometric unlock instead of a password nobody can remember.
-
Back-office integration
Jobs down, evidence up — into your WMS, ERP, job management or the bespoke system behind it, with the audit trail intact.
Deliverables
What changes once it is in people’s hands.
Adoption is the only metric that matters at first. A field app nobody uses is worse than paper, because now you have two systems.
-
Data captured once, at the point of work
The job is recorded where it happens, by the person who did it, with photo and signature attached. The rekeying step at the depot disappears entirely.
-
Nothing lost to a dead zone
A full day of work completes offline and syncs when the van gets back into coverage. Drivers stop carrying a paper backup, which is the real sign it is trusted.
-
The office knows now, not tonight
Job status, exceptions and proof of delivery arrive as they happen, so customer queries are answered first time instead of promised a call back.
-
Evidence you can produce on demand
Timestamped, geotagged, signed records retained for as long as your contracts or regulator require, retrievable in seconds rather than from a filing cabinet.
Is this the right answer?
When mobile apps is worth doing — and when it is not.
We would rather lose a project at this stage than six weeks in. If the right-hand column describes you, say so and we will tell you what we would do instead.
Worth doing when
- Work happens away from a desk and gets recorded again later at one.
- Jobs are completed in places where the signal is unreliable or absent.
- You need evidence — photos, signatures, timestamps — captured at the job.
- The office cannot answer a customer until someone gets back to the depot.
Probably not when
- A responsive web page would do and nobody needs offline or device hardware.
- The real problem is the back-office system the app would have to talk to.
- Nobody has asked the people who would use it whether it would help.
- You want it on both platforms, with hardware integration, in eight weeks.
How we deliver
How field apps get built here.
The pilot group is chosen before anything is designed, and they are the people who decide whether it ships.
-
Phase one
Ride along
We spend a day doing the job — in the cab, on the round, on the shop floor. Nothing in a requirements workshop reveals that the signal drops on that one ramp.
-
Phase two
Offline core
The complete job cycle, working in flight mode, on the actual devices. This is built first because it is the part that cannot be bolted on later.
-
Phase three
Hardware & integration
Scanning, camera, signature and printing, then the connection to the back office with the sync behaviour proven under deliberately bad conditions.
-
Phase four
Pilot, then roll out
A small group of real users for two to three weeks, changes made on their feedback, then phased rollout by depot or round with the old process still available.
What you receive
The things that actually land.
Artefacts, not adjectives. Everything below is listed in the scope document before a phase starts, so “done” is a defined state rather than an opinion.
-
Findings from a day in the field
What we saw riding along: where signal drops, how long a job takes on paper, and the steps nobody mentions in a requirements workshop.
-
The app on both platforms
Built and submitted, or deployed privately through your MDM or Apple Business Manager if it should never appear in a public store.
-
An offline-first data layer
A local store holding the full working set, so the whole job completes in flight mode and nothing is lost.
-
A documented sync and conflict policy
What happens when two devices edit the same job, written down and tested rather than discovered in production.
-
Store accounts in your name
Apple and Google developer accounts owned by you, which matters a great deal the day you change supplier.
-
Pilot results
What the pilot group did, what they changed, and the tap count against the paper process it replaces.
Golden Triangle
Field work in the Golden Triangle.
This corridor is the UK’s distribution heartland, which means an unusual concentration of exactly the work mobile apps are for.
- Distribution density Drivers and depots The M1, M6 and A14 corridor carries a large share of UK freight. Proof of delivery, load checks and driver walkarounds are everyday problems here, at scale.
- Signal reality Steel and concrete Large distribution sheds, basements and rural stretches of the A14 all kill signal. Offline-first is not a nice-to-have in this geography, it is the baseline.
- Engineers on the road Service networks Plant, HVAC, lift and manufacturing service businesses based here cover wide areas from a central depot, so first-time-fix rates and parts visibility drive the brief.
We have scoped field apps for operations running out of Birmingham, Northampton, Leicester, Nottingham, Derby, Coventry and the Magna Park and DIRFT distribution clusters.
Technology
Mobile technology.
The platform choice follows the hardware and the team you will have in three years, not a preference of ours.
- React Native
- Swift / iOS
- Kotlin / Android
- SQLite / WatermelonDB
- Offline sync engine
- Barcode & NFC
- Maps & geofencing
- MDM & biometrics
- Push notifications
- On-device testing
Where we deliver this
Mobile Apps across the Golden Triangle.
35 locations, each with a page written for it — the sectors it is actually built on, and what that means for this work. See all areas we serve.
Northamptonshire 10
Warwickshire 5
West Midlands 5
Buckinghamshire 4
Leicestershire 4
Staffordshire 4
Derbyshire 1
Greater London 1
Nottinghamshire 1
Questions
Mobile apps, answered plainly.
The questions that decide whether a field app succeeds or quietly dies.
How much does it cost to develop a mobile app in the UK?
A business field app with offline working, sync and back-office integration is typically a mid five-figure to low six-figure build. The offline and synchronisation layer is usually a third of the effort, which is why much cheaper quotes almost always turn out to assume a live connection.
Should we build native apps or one cross-platform app?
Cross-platform — React Native in our case — is right for most business apps, because the interface is forms, lists and the camera, and one codebase halves the long-term maintenance. Native is the right call when you depend on specialist hardware, sustained background location, or platform features that appear on day one. We make the recommendation in discovery and explain the trade-off.
Can the app work with no mobile signal?
Yes, and for field work it must. We build offline-first: the device holds the working data set locally, the whole job completes in flight mode, and changes sync in a queued, retrying, conflict-aware way when coverage returns. This is tested in genuinely bad conditions rather than in an office.
How long does a field app take to build?
Three to six months for a first release covering one complete job type, including a pilot with real users before any wider rollout. Additional job types, depots and rounds come much faster afterwards, because the offline store, the sync engine and the device integrations already exist and only the workflow on top of them changes.
Do you handle App Store and Google Play submission?
Yes, including the review process, and for internal apps we can deploy privately through your mobile device management or Apple Business Manager so the app never appears in a public store at all. The accounts are yours, which matters when you change supplier.
Will our drivers and engineers actually use it?
That is the question we design around, and it is why we spend a day doing the job before designing anything, and run a pilot before rollout. The practical tests are whether a job takes fewer taps than paper and whether it still works when the signal drops. If it fails either, people revert, and no amount of training fixes it.
What devices will it run on?
We agree that in discovery, because it shapes the build. Ruggedised handhelds, standard phones, shared tablets and personal devices all have different constraints around battery, screen in sunlight, glove use and sign-in. If you have not chosen yet we will give you a recommendation based on the job rather than on what is cheapest to develop for.
How do updates reach the devices?
Through the stores for public apps, or your mobile device management for internal ones, which is faster and avoids review delays. Either way the app handles a server that has moved ahead of it gracefully rather than breaking, because in a field fleet you will never get every device updated at once.
Can it use the camera, scanner or printer?
Yes: barcode and QR scanning, camera with annotation, signature capture, GPS, NFC, and Bluetooth scales or label printers. Hardware integration is one of the main reasons to build an app rather than a web page, and it is usually what makes the job faster than paper.
What if people just will not use it?
Then it has failed, and no amount of training fixes that. It is why we spend a day doing the job before designing anything and run a pilot before rollout. The two tests are whether a job takes fewer taps than paper and whether it still works when the signal drops. Fail either and people revert on day three.
Related services
Frequently paired with this.
-
Build
Bespoke Software
Operational systems written for one business, not licensed to a whole market.
Explore -
Automate
Workflow Automation
The rules-based work that eats a week, handed to software that does not forget.
Explore -
Connect
API Development
APIs and integrations so data is entered once and moves on its own.
Explore
Next step
Let us spend a day doing the job.
A ride-along tells us more than any specification. We will come out with your drivers or engineers and come back with a design that survives their worst ten minutes.