Case study / Construction

A job app for site teams that works without signal

A mobile app that puts each job in the operative's hand, works with no signal at all, and feeds the contractor's existing back-office system without replacing it.

Industry
Construction, refurbishment and maintenance
Used by
Site operatives and contract managers
Our part
Advise, design and build
Built with
React Native (Expo), AWS Lambda, Terraform
Status
In testing with the client

01 / The industry

Construction happens where the signal is worst

Building contractors working for councils, housing associations and other property owners take on new build, roofing, refurbishment, adaptations, and planned and responsive maintenance. Much of it happens in occupied homes, basements, stairwells and blocks of flats, where mobile signal is weak or missing.

Every job needs evidence: photos, arrival and departure times, the work done against a schedule of rates, and notes for the client and for invoicing. The people doing it are a mix of in-house operatives, contract managers and subcontractors.

02 / The problem

The back office worked at a desk, not on site

The contractor ran on a no-code back-office system, with a web portal for its operatives and subcontractors and a layer of integrations on AWS. It worked well in the office. On site it did not: there was no offline support, and the platform's own mobile option could not work without signal either.

So some operatives printed their documents before setting off, photos and updates went by WhatsApp and email for the office to re-key, and the office rang subcontractors to ask how jobs were going. Updates arrived late.

The app had to work with the back office, not replace it.

03 / What we built

The whole job, on the phone, signal or not

We started with a feasibility study, then designed the app with the client over five rounds of reviews before building it: one codebase for iOS and Android.

  • Jobs. A job list and calendar, and for each job the residents, access notes, correspondence, schedule of rates items by location, purchases with receipts, and attachments.
  • On site. Book appointments, check in and out, and complete the job on the phone.
  • Messages. Threads for each job, with a type for each message (a query, a variation, extra works, access or materials) and photos attached.
  • Photos that count as evidence. The in-app camera tags each photo with the stage and location, then names and watermarks it on the phone. Imports from the gallery are left out on purpose, so the watermark can be trusted.
  • Snagging. Contract managers record snags against each item, with photos.
  • Notifications. A push notification when a new job arrives.

The design goal was that every flow can be finished end to end in aeroplane mode, including completing a job and sending a message with photos.

04 / How it works

Offline first, then sync

On the phone

Each phone holds an encrypted database of the operative's jobs, with the key kept in the phone's secure keychain. Everything a user does is saved on the phone first and shows straight away, then joins a queue that sends changes in order whenever there is a connection, retrying with growing gaps between attempts. The queue survives the app being closed. Signing out wipes the key first, then the data and photos.

Photos are resized, stripped of their location metadata and watermarked on the phone, then uploaded straight to storage, picking up where they left off if the connection drops.

Between the phone and the back office

The app never talks to the back-office system directly. A gateway on AWS Lambda, defined in Terraform, handles sign-in, syncing and every write, and only makes the kinds of change on its allow-list. Sync fetches only what has changed since the phone last checked, when the app opens, every few minutes, in the background and when a notification arrives.

When the office and the phone have both changed the same detail, a rule for that kind of change decides. Where it matters, such as an appointment time, the phone shows which fields changed and lets the operative choose. Overriding the office's version is logged.

Security

Operatives sign in with their existing portal account and a text message code, then Face ID or a passcode. Sessions are short-lived and renewed automatically, every device is registered, and sign-ins are rate-limited and recorded. Signing in on a phone never signs anyone out of the desktop portal.

05 / Where it is now

In testing with the client

The build went from first commit to a feature-complete beta in about nine weeks, against a fixed plan. The client began acceptance testing in October 2026, with test builds on iPhone and Android and updates delivered over the air. Release to the app stores follows testing on real phones.

  • 19agreed user flows
  • 80+designed screens and states
  • 9 weeksfrom first commit to beta
  • 1,900+automated tests

06 / More work

Other case studies

Manufacturing

Keeping machine know-how when engineers move on

Machine knowledge lived in manuals nobody could search and in a few senior engineers' heads. We built an assistant that answers from the manuals and breakdown history, cites the exact page, and refuses rather than guesses.

AI · Search · AWS

Vehicle leasing

Salary sacrifice car leasing, joined up end to end

A vehicle leasing provider ran salary sacrifice schemes on a CRM, with manual steps at every stage. We built the pricing engine, portal, partner integrations and automation that take a deal from first quote to monthly mileage.

Platform · Integration · AWS

Commercial fit-out

Live dashboards from a decade-old project system

A commercial fit-out contractor's project and finance data sat in a decade-old system with fixed reports. We built live dashboards into it for forecasting, work in progress and daily changes, plus wallboards in its offices.

Data · QuickSight · SQL

07 / Contact

People working where your systems cannot reach?

Tell us what your people do on site today, and what happens to the information afterwards.