Canvassing that works without signal

Where signal actually dies

Not where people expect. The obvious case is a rural route where coverage simply runs out. The more common cases are mundane:

• Apartment interiors and stairwells — concrete and steel, one bar, requests that hang for thirty seconds and then fail.
• Dense neighbourhoods at peak hours — the tower is up, but contended. Latency, not absence.
• Events and rallies — hundreds of phones on one cell. This is the classic case where everything appears fine until it doesn't.
• The edge of a plan — a canvasser on a throttled prepaid plan two-thirds through the month.

"Intermittent and slow" is the normal condition of field work, and it is harder to build for than "completely offline." A system that is offline knows it. A system on one bar keeps trying.

What breaks in a cloud-first app

A conventional web app assumes the server is reachable. When it isn't, the failures are specific and expensive:

• Silently discarded entries. A canvasser taps a result, the request fails, the interface moves on. The door is marked done on screen and nowhere else. This is the worst failure mode because nobody discovers it until reconciliation.
• The walk list will not load. The canvasser is standing on the street with nothing to work from.
• Spinners instead of doors. Each tap waits on a round trip. At one bar, a door that should take four seconds takes forty, and people start batching results in their head — which is how a shift's worth of detail gets lost.
• A blank map. Tiles come from a server. No server, no map, and a routed list becomes an address column.

Caching pages is not a fix. It makes the app appear to work while entered data quietly fails to persist, which is strictly worse than a visible error.

Offline-first means the device is the source of truth

The inversion is simple to state and involved to build: the device records the result locally and treats the server as something to catch up with later. Nothing in the canvasser's workflow waits on a network round trip.

In ProCanvasser a door result passes through several independent layers of durability before it is considered safe:

• Live form state — what is on screen right now.
• Local storage — survives an accidental tab close or a browser crash.
• On-device database (IndexedDB) — structured storage that survives the app being closed and the phone restarting.
• A sync queue — durable record of what has not yet reached the server, with retries.
• The server — the shared copy the rest of the team sees.

Layering looks redundant until you learn why it exists. Mobile browsers evict on-device storage under pressure — iOS Safari is particularly willing to reclaim it. A single-mechanism design loses a day of fieldwork to an eviction nobody saw. Several independent mechanisms mean no single eviction is fatal.

The harder problem is duplicates, not storage

Storing results offline is the easy half. The half that goes wrong in production is sync.

Consider a queue of 40 results uploading over a weak connection. The upload starts, the phone loses signal mid-batch, and the client never receives confirmation. It retries. If the server has no way to recognise results it has already seen, some of those 40 doors now exist twice. Retry a few times and a canvasser's honest shift appears as several hundred doors.

This is not theoretical — it is the characteristic failure of offline-first systems, and it corrupts exactly the numbers you make decisions on.

Every queued result in ProCanvasser carries an identifier unique within the organisation. A replayed or retried batch is recognised and ignored rather than written again. The guard is on the server, because the client is the thing that cannot be trusted to know what arrived.

It is worth asking any vendor directly how they handle a retried batch. The answer tells you whether they have run a real field operation.

One distinction worth being clear about: a duplicate record is a bug, and a repeat visit is the job. Nobody gets a persuasive conversation on the first attempt at a house where nobody was home — going back is how canvassing works, and the software should schedule those returns deliberately. What gets eliminated is the accidental kind: two canvassers unknowingly working the same door on the same afternoon, or one honest shift arriving in the database three times because a retry went unrecognised.

Maps, routes and GPS without a connection

Three separate things, often conflated:

• GPS needs no data connection. It is a satellite receiver. Position works in a canyon with no bars.
• Map tiles do need to have been fetched. Tiles for an assigned area can be downloaded before a shift, so the map still draws with no connection.
• Routes are computed in advance. A walk order is calculated when the list is built, not re-derived at each door, so the route does not depend on connectivity at the doorstep.

What genuinely requires connectivity

Being straight about the limits, because "works offline" is often oversold:

• Seeing other people's work in real time. Coordination is inherently shared state. Offline, a canvasser sees their own progress; the team view catches up on sync.
• Getting a newly assigned list. A list has to reach the device before signal is lost. Assign before the shift, not during it.
• Sending anything outward. Messages and follow-ups queue and go when there is a connection.
• Map tiles never fetched. Wander well outside the downloaded area and the map has nothing to draw.

The honest summary: everything a canvasser does at a door works offline. Everything involving other people catches up on sync.

Common questions

Test it the way it will actually fail

Put a walk list on a phone, turn on airplane mode, record a few doors, then turn it back on and watch them arrive. That test takes two minutes and tells you more than any feature list.

Start Free Trial