“The interesting constraint wasn’t technical sophistication. It was knowing which problem not to solve.”

A passport application that works where there is no internet

Passport and ID card issuance for a national identity authority: agents go out to people, the most sensitive data a government holds is captured on a phone in a village, and it waits on the device until the network returns.

Get in touch

National identity body, West Africa · full-stack, involved in every feature · 2024 · 6 months · direct for the client

No network

application, photo and biometrics captured offline

1 working day

the longest offline window per device

Play Store

app in production, publicly available

The problem

A national identity management body issues passports and ID cards, and some applicants never reach a counter — agents go out to them. The person an agent visits often has no internet, and the application carries a photo of their face, a photo of their document and biometrics.

The constraint

The most sensitive personal data there is has to sit on an agent’s phone for a while. On top of that: the state fee is collected through a channel the regulation recognizes, and the data is checked against the national identity registry — neither is chosen for technical convenience.

What we did

Upload straight to S3, not through the backend
When every byte passes through the instance you need a bigger machine, you pay for transfer that never had to exist, and uploads fall over as soon as several arrive at once. In a system where every application is a photo upload that is not a detail, it is the main path. A pre-signed URL removes the bottleneck and the cost at the same time.
S3 + pre-signed URLs
Offline-first, with a known boundary
The application, photos and biometrics are written to secure storage on a company phone and sent when a connection appears. We did not build a full synchronization system, because the scenario it would serve does not happen: the agent returns the phone to the office at the end of the day, so the offline window is one working day.
Secure storage · remote wipe
One flow for both documents
A passport and an ID card go through the same procedure at a different price. Two separate flows for what is essentially one procedure means double the maintenance and double the places to get it wrong — in a system where getting it wrong means somebody does not get a passport.
One flow, two prices
Fees through the state gateway
The fee is paid through the national payment gateway that covers government payments and the single treasury account, with PayPal for applicants outside the country — the system also serves people in the process of acquiring citizenship. In the public sector the payment partner is dictated by regulation, not by the quality of its documentation.
State gateway · PayPal
Registry access behind keys and addresses
Communication with the national registry is secured with API keys, digest authentication and tokens, and the registry only accepts calls from verified IP addresses — a stolen key on its own does not open the door.
IP allowlist · digest

A FIELD APPLICATION — FROM DEVICE TO REGISTRY

In the field — no network

The agent collects the application, a photo of the face and a photo of the document — or an application with no prior document at all. All of it goes into secure storage on a company phone that can be wiped remotely if it is lost. Had these been agents’ personal phones, this design would not have been acceptable.

An application is not real until the server accepts it — the device never decides on its own.

The result

The system is in production and the app is publicly available on Google Play. Applications, photographs and biometrics are captured with no connection at all, on devices that can be wiped remotely; the offline window is bounded to one working day; fees are collected through the channel the state recognizes, and access to the national registry sits behind keys, digest authentication, single-use tokens and IP allow-listing. Six months, direct for the client, involved in every feature.

Two numbers that shaped the design

1 day

the longest window without a connection — agents return devices at the end of each shift

one fact about the working day

protections on registry access: keys, digest authentication, single-use tokens, IP allow-listing

a stolen key alone opens nothing

A bounded window is not a general synchronization solution. It is one fact about the working day, used deliberately.

What we’d do differently

We never tested what happens on the day the assumption breaks — an agent who doesn’t return, a phone that stays out for a week. The bounded window was the right design, but a design that depends on a routine should be tested against the routine failing.