What actually keeps working when the signal drops

A reasonable person hearing that a new, small company has solved offline-first field software should be skeptical. Syncing work done with no signal, without duplicating invoices or losing notes, is genuinely difficult — difficult enough that products with hundreds of engineers treat offline as a degraded mode rather than a foundation.

So this is not a claim that we are cleverer. It is an explanation of a structural choice, what it buys, and precisely what it does not.

Why the established products score badly at this

Not incompetence. Legacy.

Almost all business software syncs mutable rows. There is one record for a job, and changing it means overwriting what was there. The moment two people can change that row while disconnected, you are into the hardest problem in distributed systems: whose version wins, how you merge them, and what to do about the invoice that got sent twice because a retry looked like a new request.

There are real answers to that, and they are all expensive. They also require changing the shape of the data at the centre of a product that has been running for a decade with paying customers on it. Nobody authorises that rewrite, and they are not wrong not to.

If you started building in 2015 assuming coverage, you are not one sprint away from offline-first. You are one rewrite away.

The choice that makes it tractable

JobCard does not store a job as a row that gets edited. It stores what happened, in order, and never overwrites anything. "Job 118 scheduled", "arrived 09:14", "part fitted", "completed", "invoice raised" — each one an entry appended to a log.

That sounds like a detail. It removes most of the problem.

Two techs working at the same time is no longer a conflict. They are two entries. Both are kept, both are ordered, neither overwrites the other. There is no merge to get wrong because there is no overwrite to reconcile.

Three mechanisms sit on top of that:

Every queued change carries a key. If the connection dies mid-send and the app retries, the server recognises the key and does nothing the second time. This is the specific guard against the duplicate-invoice failure — the one people are right to ask about first.

The queue keeps its order across a restart. A tech who closes the app with six changes waiting does not get them replayed in a shuffled order. There is a test for exactly this, because "works until you close the app" is not offline support.

Each entry is sealed to the one before it. When the queue lands, the chain is validated on arrival. A gap or an out-of-order delta is rejected rather than quietly absorbed, which means a sync bug shows up as a refusal instead of as a plausible-looking history that is wrong.

What works with no signal at all

Your customers, jobs, equipment records, pricebook, and every note you have saved. Booking a job, starting work, recording labour and materials, completing the work record, taking a cash or cheque payment, and finishing your daily close.

That is a normal service day, and none of it needs a tower. The app itself is stored on the device — including after we ship an update, which is a specific thing we had to build rather than something you get for free.

What honestly needs a connection

Photo uploads. The bytes are large and they belong in encrypted storage rather than living in a camera roll forever. They queue and go up when you have signal.

Customer approval links. The customer opens them on their own phone, so both sides need coverage eventually. There is no way around that.

Anything involving another person in real time.

The rule in the product is that nothing fails silently. If a step needs signal, you are told before you invest effort in it, not after.

What this does not fix

Three limits, stated because a product that hides them is one you find out about in a plant room.

First use needs a connection. The app has to arrive on the device somehow. Set it up on wifi before the first job. No web app can load itself in a dead zone, and anyone implying otherwise is selling something.

A browser can clear its own storage. Safari does so after roughly a week without opening a site, and a tech who wipes their browser data takes the local copy with it. Work already synced is safe on our side and exportable at any time; work written offline and never synced is not. We ask the browser to keep our storage, and adding JobCard to the home screen makes that far more likely — but no web app can make eviction impossible.

Two offline techs land in reconnect order, not clock order. Whoever gets signal first appears first. Reasonable, and not the same as perfectly reconstructing what happened when.

How to test the claim in about a minute

Do not take any of this on trust — including from us.

Open the app, load your jobs, then put the phone in airplane mode. Add a job. Write a note. Record a payment. Close the app entirely and open it again, still with no signal. Then turn the radio back on and watch the queue drain.

That takes a minute and it settles the question better than any amount of copy. Run the same test against whatever you use today. The results are usually informative.

How we prove it to ourselves

An automated browser test drives a real session offline: the network is switched off mid-session, work is written, then the connection returns and the test asserts the queued work landed in order. It runs against changes to the product rather than once for a screenshot.

Whatever tool you are considering, ask them how they prove "works offline." Ask whether it is tested automatically, and what happens after they ship an update. The shape of that answer tells you whether offline is a foundation or a banner.