Your engineers are filling in paper. Somebody types it up on Monday. By then the job’s been invoiced wrong, the part that was fitted isn’t on the record, and the customer has already rung up to ask why.
Everyone knows the answer is an app. What stops it is the assumption that you’d need a new system first.
You don’t. The app talks to the database you already have. ☎
Four apps built for one client, in daily use by their engineers. Distributed privately to their staff rather than listed publicly — which is how a field app should work. → see what we built
Already live on the App Store and Google Play — four apps we’ve built for one client, publicly listed.
What it looks like in practice
[IMG-1] — Phone mockup showing a real job screen: today’s job list, one job open, big touch targets. Anonymised. Not a database form shrunk down — that distinction is the point.
Alt: Mobile job list and job detail screen
An engineer opens the app in the van and sees today’s jobs, in order, with the address, the customer history and what they’re expected to do.
They do the work. They tick off what was done, add parts used, take photographs, scan the asset they worked on, and get a signature on the screen.
It lands in the office system as they finish, or as soon as they’ve got signal again. The job is closed, the parts are off stock, and the invoice can go out that afternoon instead of next week.
Nobody types anything up on Monday.
Offline, which is the bit that decides everything
This is where most mobile projects fail, and it’s the question to ask anyone quoting you.
Engineers work in basements, plant rooms, lift shafts, rural sites and industrial units with no signal and no guest wifi. A web page in a browser stops dead. A properly built app doesn’t.
The day’s work is on the device before they leave. Jobs, customers, asset history, parts, price lists.
Everything they do is recorded locally, whether there’s signal or not. Photographs and signatures included.
It syncs when a connection comes back, on its own, without anyone pressing anything.
Conflicts are handled deliberately — two people touching the same record is a design decision, not a crash.
Nothing is lost if the battery dies mid-job, which it will.
If an app only works with a connection, it’s a website in a costume, and your engineers will stop using it within a fortnight.
Using what’s in the phone
The reason to build an app rather than a web page:
- Camera — photographs of completed work, damage, serial plates, meter readings, filed against the job automatically
- Barcode and QR scanning — assets, parts, stock, plant. Scan rather than type a fourteen-digit code with cold hands.
- Signature capture on screen, with a timestamp, so proof of completion stops being a piece of paper in a van
- GPS — where the job was actually done, and how long the engineer was there
- Push notifications for urgent callouts and reallocated jobs
- Phone and navigation built into the job, so nobody’s copying a postcode into another app
→ barcode and scanning integration
Who we build these for
Field service and maintenance engineers · delivery and transport · surveyors and inspectors · installers and fitters · plant and equipment hire · stocktaking and warehouse · compliance and safety checks · anyone whose work happens away from a desk and ends up on paper.
The pattern is nearly always the same: a job is assigned, someone does it somewhere else, and evidence of it has to get back into the system without being retyped.
Three questions worth settling early
Whose phones? Company devices are simpler to manage and cost more. Personal phones cost nothing and raise questions about what you’re allowed to put on them and what happens when someone leaves. Both work. It changes the design, so decide it early.
What happens when a phone is lost? It will happen. The answer should be that the data on it is encrypted, access can be revoked centrally, and the device can be wiped — not that somebody now has a copy of your customer list. Where you’ve got Intune or similar, we work with it.
Who’s on the other end of it? An app that goes wrong at 7am on a Monday needs somebody to ring. We build in crash reporting and monitoring so we usually know before you do, and we stay on afterwards → support
How it’s built
React Native, for both platforms, from one codebase.
That’s a deliberate choice, not a shortcut. It means iOS and Android get the same app rather than two that slowly drift apart, a fix lands on both at once, and — the part that matters most over five years — you’re maintaining one thing rather than two. For a business running a field app, the build is the small cost. Keeping it working through OS updates, new devices and changing processes is the real one, and that bill halves.
It also does everything a field app actually needs: camera, barcode and QR scanning, GPS, signature capture, push notifications, background sync and full offline storage. The idea that cross-platform can’t handle that is about a decade out of date.
And because a lot of changes ship over the air, a tweak to a form doesn’t mean waiting on app store review to get it to your engineers.
- An API over your existing database, so the app never talks to SQL Server directly → SQL Server integration and APIs
- Entra ID sign-in and MFA, so a leaver loses access with their account
- Published to Google Play and the App Store, or delivered straight to your staff’s devices through Apple Business Manager, managed Google Play or your MDM — no codes to hand out, no setup for the engineer to get wrong. Public listing for anything customer-facing, direct distribution for anything internal, and often both for the same system.
- Crash reporting and monitoring from day one, so we usually know about a problem before you ring
We build native Swift and Kotlin where there’s a specific reason to — and we support native apps somebody else built, which is a fair bit of what we get asked to take on. But for a business system that needs to work on whatever phone an engineer happens to have, React Native is where we’d steer you.
Where the data currently lives in Access, it usually wants moving to SQL Server or Azure SQL first — a job in its own right, and worth doing anyway → Access migration and upgrades
In stages
One workflow first. Usually job completion, because that’s where the paper is.
Get it into the hands of two or three engineers, find out what’s wrong with it while it’s cheap to change, then widen it. The office system runs unchanged throughout, and the people still on paper carry on until the app has earned their switch.
Case studies
Aire Valley Catering: four mobile apps, an Access business system, and engineers with no signal
Engineers working on customer sites across the UK can't count on having a signal, and the job still has to be recorded. Four production apps across both app stores, an Access and SQL Server business system behind them, and a roadmap that keeps offline working rather than trading it away.
View case study →Recovering audit and customer data across multiple corrupt SQL databases
Several customer databases became damaged and wouldn't open, putting audit records, operational data and customer information at risk of permanent loss. A structured recovery programme rebuilt usable datasets from the corrupt files and returned multiple customer systems to service.
View case study →ACC Worldwide: a faster SQL Server platform, noticed on day one
A business-critical system was working but slow, and staff felt it every day. Work on the SQL Server environment behind it delivered an immediate speed increase, and left ACC's own IT team with the logging and monitoring tools to keep developing it.
View case study →What's still being done on paper?
Tell us what your engineers fill in and what happens to it afterwards. We'll tell you what an app would involve, whether the data needs moving first, and what it costs.
Send us the details → See the apps we've built →