Software that respects
how site teams really work.

The office–site gap is where software goes to die.

Here's a pattern almost every contractor will recognise. The project manager evaluates a new system, loves it, and rolls it out. For a few weeks the dashboards look beautiful. Then the data quietly stops matching reality.

It isn't that the site team is being difficult. It's that the tool was never built for them. The PM is sitting at a desk with a big screen, a keyboard and a coffee. The site supervisor is on their feet for ten hours, juggling deliveries, subbies and a programme that changed this morning. When the software asks that supervisor to stop, take their gloves off, find signal, and tap through five screens of a form, they do the rational thing: they don't.

So the work still happens - it just gets recorded on a scrap of paper, in a WhatsApp message, or in someone's head. And the moment that happens, your single source of truth becomes a single source of fiction. The office is now making decisions on data that's days old and quietly wrong.

What site reality actually looks like.

If you've never stood on one, it's easy to design software as though a site is just an office with worse lighting. It isn't. The constraints are fundamentally different, and any honest design has to start there:

• Signal is unreliable. Basements, steel frames, rural plots and the inside of a partially clad building all eat mobile data. "It needs a connection" means "it doesn't work where the work happens".
• Hands are full and dirty. Gloves, dust, rain and cold all make fiddly interfaces a non-starter. Big targets and few taps win.
• Time is the scarcest resource. Nobody is going to narrate their day into a form. If logging something takes longer than doing it, it won't get logged.
• Patience for admin is zero. Site teams didn't take the job to do data entry. Every field you make mandatory is a small tax on goodwill.
• The phone is the computer. For most people on site, the only device they'll ever use for your software is the one in their pocket.

None of this is a criticism of site teams. It's just the environment. Software that ignores it isn't being ambitious - it's being naïve.

Design principles that respect the field.

Once you accept the reality above, a short list of design principles falls out of it. These aren't features to bolt on later; they're the foundations that decide whether anyone bothers using the thing at all.

Works offline, syncs later

This is the one that separates field-ready software from office software with a mobile login. If the app stops working the moment the signal drops, the data will always be incomplete - and incomplete data is the thing that quietly erodes trust in the whole system. Offline-first means the person on site records what they see when they see it, and the platform takes care of getting it to the office.

Genuinely mobile-first, not a shrunk desktop

There's a world of difference between an app built for a phone and a desktop interface that technically loads on one. The shrunk-desktop approach gives you tiny tap targets, horizontal scrolling and forms that assume a mouse. A real mobile-first design assumes one thumb, bright sunlight and three spare seconds.

Capture once, reuse everywhere

The fastest form field is the one you never have to fill in. If the system already knows the project, the location, the task and who's logged in, it shouldn't ask. Every detail re-keyed is a detail that can be mistyped, skipped, or resented.

Approvals that move at site speed

Variations, sign-offs and payment applications shouldn't stall because the only person who can approve them is away from a desk. When an approval is a single tap on a phone - with the context attached - work keeps moving and cash keeps flowing.

Role-based simplicity

Showing everyone everything feels generous; in practice it's overwhelming. A subcontractor logging progress doesn't need the commercial dashboard, and burying their two relevant buttons under thirty irrelevant ones is the fastest way to lose them. Give each role a clean, obvious path through their part of the job.

What this looks like in practice.

Principles are easy to nod along to, so here's what they mean in concrete terms on a normal working day:

• Offline snagging and quality control. A supervisor walks a unit with no signal, photographs defects, tags them by location and assigns them - all stored on the device. When they get back to the cabin or the car park, it all syncs. Nobody re-types anything into a spreadsheet that evening. See how this works on our quality control tools.
• Timesheets that track themselves. Instead of asking people to type hours into a grid on a Friday from memory, time is captured from the activity that's already happening on site. The office gets accurate hours without the weekly chase, and people get paid for what they actually did.
• Approvals cleared from a phone. A variation is raised on site with photos attached. The person who needs to approve it gets a notification, sees the context, and taps approve from wherever they are. The job isn't held up waiting for someone to be back at a desk.

In each case the win is the same: the record gets created at the moment and place the work happens, by the person who did it, with almost no friction. That's the only way the data in the office ends up matching the reality on the ground.

The compounding cost of low adoption.

It's tempting to treat poor adoption as a soft problem - a bit of grumbling, a few gaps in the data. It isn't soft, and it doesn't stay small. It compounds.

The first symptom is shadow spreadsheets. When the official system is too painful, people build their own quiet workarounds. Now you're paying for a platform and still running the job on someone's personal Excel file - and the two never quite agree.

The second is stale data. If updates only happen when someone gets back to the office, your live view is never actually live. A report that's three days behind reality looks authoritative and is subtly wrong, which is more dangerous than having no report at all.

The third, and most expensive, is decisions made on bad information. Programmes get re-planned around progress that didn't happen. Payments go out against work that wasn't checked. Risks that were flagged on site never make it to the people who could have acted. To put rough, illustrative numbers on it: if a handful of avoidable issues each month each cost a few hundred or few thousand pounds to put right, the annual figure dwarfs whatever the software licence ever cost. Low adoption isn't a discount on the tool - it's a tax on the whole business.

How DuoApp is built around the field.

DuoApp was built by people who'd worked on sites, specifically to close the office–site gap rather than paper over it. That shows up in the decisions that are easy to skip and hard to retrofit.

The mobile app is a genuine app, not a cut-down web page - and it works offline, syncing automatically when signal returns, so quality control, snagging and site updates carry on regardless of coverage. Data is captured once and reused across projects, invoices and approvals, so the same detail isn't re-keyed five times. Approvals and sign-offs are designed to be cleared in seconds from a phone. Permissions are role-based, so each person gets a clean view of just their part of the job instead of a wall of options.

The result is a platform the office can trust because the site actually uses it. If your team manages handovers and defects beyond practical completion, the same field-first thinking runs right through our aftercare tools too.