The app your engineers work from

The office system stays on the desk. This is the part that goes out in the van.

A typical business running one of these has 10 to 40 engineers on the app, one office, and 60 to 250 jobs a day passing through it. It is the reason the office stopped keying in paper sheets, and it talks to a link on the office system that somebody wrote alongside it. Whichever generation of app is in the engineers' pockets, the work it does in the van is the same.

In the engineer's words, it shows the day's list, opens a job with the site, the access notes and what was done last time, and takes a tap at each step: leaving, arrived, started, finished. Parts come off the van's stock list. Photos go on the job. The customer signs on the screen and the report goes to them as a PDF before the engineer is back in the van. In a plant room or a basement with no signal it keeps working and sends everything when the signal comes back. In the office, the job's status changes on the diary as the engineer taps.

The rules it holds are the ones the office argued about when it was built:

• A job cannot close without a signature unless the customer is on the no-signature list, in which case a photo of the finished work stands in for it.
• Before-and-after photos are mandatory on insurance jobs, and the app will not close the job without both.
• The parts list the engineer sees is the van's stock, not the whole catalogue, and a part that is not on the van raises a request to the office.
• Travel starts when the engineer taps leaving the previous job, not when the van moves, because that is how the customers' contracts define chargeable travel.
• After a spell offline, the office copy wins on any conflict except the times and the signature, which the phone wins.

The agency documented none of it. The app is the record.

Built between 2012 and 2017 by an agency or a contractor, as the companion to an office job system that was already a few years old. The screens are web code wrapped in PhoneGap or Cordova, or an Ionic app on the same shell, and where the budget stretched to it, a native pair in Objective-C and Java. Builds came out of PhoneGap Build or one developer's Mac, and the store accounts were opened in the agency's name. It runs on the Android phones and older iPhones already in the vans.

Adobe closed PhoneGap Build in 2020, and the Mac with the working setup left with the developer. The camera and signature plugins it leans on stopped being maintained long ago. So the app keeps running on the handsets it was installed on, and nothing about it can be changed.

The same app built between 2018 and 2022, usually by an agency, in React Native against an office system with a Node API the same agency wrote, or put together in Power Apps or FlutterFlow by someone in the office who wanted the paper gone. From the office it looks current: one project for iPhone and Android, push notifications when a job is added, and a status screen showing who has arrived where.

The sync is what holds it. The offline queue and its conflict rules were the hardest part to write, and the one developer at the agency who understood them left before the agency itself wound down. The last release, meant to add a job type, lost signatures captured in basements and was pulled within days, so nothing has shipped since, and the listings and build pipeline still sit under the agency's login. From 2023 a few offices tried an AI app builder for a replacement, and most stalled at offline working, which a demo in the office never tests. Years younger than the wrapped app, and stuck on the same handsets.

The job sheet is in the office before the van has left the car park.

That is the whole case for it. The engineer finishes, taps, and the times, the parts, the photos and the signature are on the job in the office system while the engineer is still in the customer's car park. The invoice can go the same day. The customer has a report with photos in their inbox before they are back at their desk, and a query about what was done is answered by opening the job.

The office gets the day as it happens. The diary shows who has arrived where and who is running late, without a phone call. The parts used are recorded when they are used, so the van stock is close to right and the parts bill lands on the right job. And a new engineer picks the app up in a morning, because it only shows them the next thing to do.

The app still runs on the phones in the vans. It just cannot be changed.

The stores moved and the app did not. Since 28 April 2026 the App Store has needed uploads built with Xcode 26, and since 31 August 2026 Google Play updates have had to target Android 16. A wrapped app last built in 2016 meets neither, and nor does a React Native project last built in 2021. A fix, however small, cannot ship until the project builds on current tooling, and the agency that had the tooling has gone.

The keys are somewhere else. The Apple Developer account is in the agency's name. The Android signing key was on the agency's laptop, or in PhoneGap Build, which Adobe closed in 2020. Whether Play App Signing was ever switched on decides whether the existing listing can be updated at all, and nobody in the office knows.

New phones, old plugin. New handsets arrive and the camera plugin stops working after the next operating system update. The engineers now send photos over a messaging app and the admin attaches them to the job by hand, which is the paper problem coming back through the side door.

The app is freezing the office system. Every change to the job system has to keep the old app's API exactly as it was, because the app cannot follow. New fields, a new job type and the rules for a new account customer all wait on an app nobody can build.

An app that ships again, in your own accounts, and then gets better one screen at a time.

Each builds on what the app already does.

A build the stores accept. Store accounts and signing keys in the business's name, a project that builds on what the stores now require, and a test release on a few engineers' phones first. The fix the engineers have been asking for is the first thing through.

The screens kept, the shell replaced. An app that installs on the phones the engineers carry today and can be updated when the stores change their rules. Where the app is web code in a shell, the screens carry across and each plugin is mapped to a maintained one or rewritten. Where it is a native pair or an ageing framework project, bringing it current is weighed against one fresh build on the same office system. The assessment chooses the route and prices both.

Offline that holds. A queue that survives a plant room and a basement, with the conflict rules written down and tested, not discovered.

Photos and signatures as records. They land on the job and the asset in the office system, where the history is searchable and the report is built from them, not in the app's own database or an email.

Any handset. iPhone or Android, company phones or the engineer's own, so a new handset is a purchase rather than a project.

The office system free to change. A version on the link between app and office, so a new field or job type does not break the app in the vans, and a new screen does not wait on the office.

The old app is not switched off for any of this, whichever generation it is. It keeps working until the last handset has swapped.

Save the typing and the scrolling on site: the data plate read from a photo, the site's history read for the engineer.

AI is worth having wherever the engineer would otherwise type on a small screen or scroll back through notes. Two places:

The data plate read from a photo. Every boiler, panel and unit carries a label with the make, the model and the serial, usually in a cupboard with poor light. The engineer squints and types it, or skips it and the office chases it later. With AI the engineer photographs the plate, the model and the serial are read into the asset record, and the engineer confirms them with a tap. At 60 to 250 jobs a day, with a plate to record on perhaps one job in three and a couple of minutes lost to each, that is typically an hour or two of typing a day taken out of the vans across the team.

The site's history in three lines. A site on a long contract has years of notes behind it: what was fitted, what was quoted and turned down, which door the key opens, the site manager who wants a call before anyone arrives. The engineer scrolls, or rings the office to ask. AI reads the history the office system already holds and puts a plain-words summary at the top of the job, to read in the van before going in. If one job in ten prompts a call to the office, that is between 6 and 25 calls a day at a few minutes each, and most of them stop.

Not worth doing: regenerating the app from the old one with an AI code tool. That produces another codebase nobody owns, with the same store problem attached.

An app that cannot ship a build cannot ship an AI feature either, so both wait for the first stage and an office system that takes changes safely. The assessment maps where AI would pay back on the app and the office system as they stand.

Keys first, then a build, then the shell, with the old app on the old phones as the fallback throughout.

1. Accounts, keys and a build. The Apple and Google accounts into the business's name, the Android signing key found or Play App Signing established, the project building on what the stores now require, and a test release on the stores' test tracks. This goes first because nothing can reach an engineer's phone until it exists.
2. The waiting fix. Shipped through the old shell to a test group of engineers, then to everyone. The office sees the first update in years.
3. The shell, or the rebuild. The screens carried into a maintained shell with the plugins mapped, or the app built again on the same office system, screen by screen, to the test group first.
4. Offline, then photos and signatures into the office records. Each a stage, each priced on its own.
5. A version on the link between the app and the office, so the two move independently from here on.
6. Retire the old app when every handset has the new one. The last to go is usually the engineer with the old phone who likes it.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an engineers' app that means getting the project building in a clean environment, listing what the stores reject, establishing whose name the accounts and keys are in, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work, what drives the price and the payment terms each have a page, and so does each technology an app like this is built on: PhoneGap and Cordova, Ionic and native iOS and Android, and for the newer generation React Native and the agency's Node API behind it.