Why offline-first matters for field tools

Most form-builder SaaS quietly assumes you have a connection. The signup page, the marketing copy, the demo video, none of it shows you what happens when you walk into a turbine, a basement, or a tunnel and the bars on your phone disappear.

That's not a small omission. For inspectors in construction, wind, technical maintenance, and real estate, "no signal" is not the edge case, it's a regular Tuesday. If your form tool falls over the moment connectivity drops, you're not really using a digital form. You're using a clipboard with a worse UI.

This piece is about what offline-first actually means when you take it seriously, what it costs when you skip it, and what we built into FieldAudit to handle the four things you have to get right.

The connectivity assumption every form builder makes

Open the docs of most form-builder SaaS, the popular ones, the ones with the tasteful illustrations, and search for "offline." Most of them either don't mention it, or describe a thin progressive web app that caches the form definition and crashes the moment you try to upload a 4 MB photo while standing on a tower.

That's because their core assumption is the same one a web app has always made: we'll send the data to the server, the server will respond, and the user will see the next state. When the server isn't reachable, you get a spinner that becomes an error that becomes a lost morning.

For office workflows that's fine. For inspections, it isn't. Inspections happen in places that were specifically built to keep weather, radio, and people out, concrete bunkers, steel cylinders, cellars below the water table. The form is the last thing the inspector wants to think about. It needs to just work.

What "offline-first" actually requires

"Offline-first" is a phrase that's been diluted by half the SaaS industry to mean "we cache the page." A serious offline-first stack has to get four things right:

1. Capture without the network

The form definition, all media (photos, signatures, GPS pings), and all submitted answers must persist locally before any network call is attempted. Not "we'll retry on failure", but "we'll write to local storage first, and the server is a sync target, not a dependency." On a phone with no signal, every button still has to do something useful.

2. A real queue

Submissions, photo uploads, edits, and deletions all need to land in a durable queue that survives an app close, a phone restart, and a switch from 4G to wifi to nothing. The queue has to know what's been sent, what's pending, and what failed and why. The user needs to be able to glance at it and trust it.

3. Conflict resolution that respects the field

Two inspectors can edit the same submission while both offline. When they both come back online, you need a strategy. "Last write wins" is wrong here, losing a fellow inspector's photos because your phone synced one second later is a real failure mode.

The right strategy depends on the field type: text fields can merge, photos accumulate, single-choice answers need a human decision. The system should record conflicts surface them in the back-office, not silently overwrite.

4. Sync that's boring

Sync should happen quietly, in the background, without the inspector ever having to think about it. No "tap to sync" button as the primary affordance. No interstitial with a progress bar blocking work. Just a small, calm indicator that says working, up to date, or conflict, review when you can.

Where Google Forms, Jotform, and Typeform stop working

Each of these tools is excellent at what it was built for. None of them was built for what an inspector actually does in a tower or a substation. The failure modes are concrete:

• Google Forms requires a connection to load a form, can't queue partial submissions, and will lose progress if the page is reloaded mid-fill.
• Jotform has a "kiosk mode" that supports limited offline, but media-heavy submissions (photos, signatures) are unreliable when sync resumes, partial uploads, duplicate entries, and lost attachments are common in inspector forums.
• Typeform assumes a connection and a polished consumer journey; the moment the network goes, the form goes with it.
• Microsoft Forms caches some content but doesn't survive a full app close. Inspectors rebooting their tablet between turbines is a normal pattern.

These aren't edge cases. They're the regular Tuesday for any inspector working below ground or above 80 metres. If you're choosing a form-builder for that audience, "supports offline" in the marketing copy isn't enough. You need to ask what happens to each of the four things above.

What it costs when you skip this

It's tempting to wave this off as a niche concern. It isn't. The cost shows up in three places, and each of them has a number attached:

• Re-entry. When a form fails mid-fill, the inspector either re-enters from a clipboard later, or guesses. Either way, an inspection that took 90 minutes in the field takes another 30 in the office. Across a team of ten doing two audits a day, that's about 100 hours a month of pointless re-typing.
• Lost media. A signature retake or a photo that didn't upload is the most expensive failure, because the moment that compounded with the inspector being back at the office, the only fix is going back to the site. We've heard from teams who've literally driven back two hours up a mountain because a single before-photo didn't sync.
• Trust erosion. The third cost is the worst, because you can't see it on a spreadsheet. Inspectors who've been burned twice stop trusting the digital tool. They start running the clipboard and the app in parallel "to be safe." At that point, you've added work, not removed it.

How FieldAudit handles each of the four things

We didn't get to call FieldAudit "offline-first" until we'd answered each of the four questions above. Here's the short version of each:

Capture: local IndexedDB by default

The PWA stores every form definition, every submission in progress, every photo, and every signature in IndexedDB before it touches the network. Submissions can be opened, filled, edited, photographed, and signed offline, the inspector never sees a network call. The first time we test a tenant's form, we put the tablet in airplane mode and walk through a real submission. If it works there, it'll work in the basement.

Queue: durable, inspectable, resumable

Every action that needs to reach the server lands in a local queue with a UUID, a created-at timestamp, and a state. The queue survives app close, browser cache clears, and OS restarts. Photo uploads chunk and resume, if a 6 MB photo gets to 4 MB before the network drops, it picks up at 4 MB when it comes back, not from zero.

Conflicts: surfaced, not hidden

When two inspectors edit the same submission while both are offline, FieldAudit doesn't pick a winner. Both edits land on the server with timestamps, the back-office sees a "review needed" badge on that submission, and a reviewer decides what's right. This is more work for us to build, but the alternative, silently dropping someone's photos, is the kind of bug that only shows up in court.

Sync: a one-pixel dot, not a button

The inspector never has to "sync." There's no button. There's a small status pill in the corner that says up to date, working, or conflict. If conflict, tapping it shows what's pending. If working, the network and queue are doing their job in the background. The inspector closes the form and walks to the next tower; sync happens whenever the antenna catches.

The short version

If your team does inspections in the field, your form tool's behaviour without a network is not a feature, it's the floor. Tools that don't take that seriously end up costing you re-entry, lost photos, and trust. Offline-first isn't a checkbox you put in the marketing copy. It's four engineering problems you have to solve before you can ship.

FieldAudit was built around those four problems first. The form builder, the PDF reports, the whitelabel theming, they all came after.