Design sample Invented courier company, invented addresses, simulated server. The app makes no network requests at all. Read the system design →

Built for the basement car park, not the demo room.

A courier spends half the working day somewhere with no signal — a lift, a stairwell, a village on one bar. For this app the missing network is the normal case, so it never waits for one and never pretends to have had one. Turn the signal off below and keep working.

Today · 6 drops

online

 

What the server actually has

Sync log

    How it is designed

    Almost every delivery app is built as though the network were always there, with an offline mode bolted on afterwards as a courtesy. That gets the priority exactly backwards for the person actually using it.

    The phone is the source of truth until the server catches up

    Every action is written locally and appended to a queue. The screen updates the instant the driver taps, because making somebody in a stairwell wait on a spinner is not a design, it is an apology. The network changes only how soon the action leaves — never whether the work can continue.

    Every queued action carries a key made on the device

    The key is generated before anything is sent, so a resend keeps the same one. The network is allowed to deliver an action twice; the server is required to count it once. Watch the log: this demo deliberately loses about a quarter of the replies after the server has already applied them, which is the exact case that double-delivers a parcel when there is no key. Here the resend is accepted and changes nothing.

    It says “queued”, never “sent”

    A card that has not reached the server is drawn with a dashed border and says so. Optimistic interfaces that show a confident tick the moment you tap are how a driver finishes a shift believing sixteen parcels are signed for when the server has eleven — and the argument about who is wrong happens the next morning, with no evidence.

    The queue is strictly ordered

    Actions flush in the order they were made, and a failure holds the queue rather than letting later ones overtake. Delivered arriving before picked up is a sequence the server would have to reject, and reordering on the client is far cheaper than reasoning about it on the way in.

    Other demos · Hire the developer