Technology · Resilience
A garage is a
network test.
Below-grade concrete, elevator cores, and a curb crowded with phones make connectivity uneven by default. Parking software should treat that as an operating condition, not an exceptional outage.
The reframe
Offline is not a blank screen. It is a state with rules.
Keeping an old list visible is useful, but it is not offline operation. The harder question is whether a valet can do new work without creating a duplicate ticket, losing a photo, or promising a guest that a request reached someone when it did not.
Good offline design separates what the device knows, what it has queued, and what the server has confirmed. The interface should never blur those three states.
Three truths
Cached, queued, and confirmed are different
Name the state the operator is looking at
Cached
Known before the drop
Active tickets and stand context remain useful, but may be stale. Show their age and avoid treating absence as proof.
Queued
Accepted by this device
A check-in can be recorded locally for later delivery. It needs a durable identity and a visible pending state.
Confirmed
Accepted by the authority
Only the server can resolve cross-device conflicts and complete work that depends on shared state.
→An honest product can say “saved on this phone” without pretending that means “everyone has it.”
Queue facts, not gestures
A tap is temporary. The durable unit should describe the intended operation well enough to replay safely.
→Valletto's current iOS and Android check-in clients use this queued-write shape for transport loss. That does not mean every feature works offline.
Ask vendors for a failure map
A single yes-or-no offline claim hides the decisions a buyer actually needs to understand.
A vague promise
OFFLINE READY- No list of supported actions
- No distinction between local and server state
- No conflict or retry demonstration
A useful answer
FAILURE MAP- Names what can be read and written
- Shows pending work in the interface
- Demonstrates recovery with two devices
The field test
Do the work, cut the network, then create a conflict.
Check in one vehicle while offline on one phone, change the same session elsewhere, and restore service. Watch which truth wins, how the operator is informed, and whether the system produces a duplicate.
The takeaway: resilience is not the absence of an error message. It is preserving intent without inventing certainty.
