Designing for uncertainty

Chapter 1

The system we were actually building

The difficult part was not building individual modules. It was deciding what guarantees the overall system could make when those modules interacted under imperfect conditions.

Sync connects orders, tables, Host Stand, reservations, kitchen routing, delivery, menu and pricing, customer records, reporting, and staff permissions. Each area has its own interface, but none of them is operationally independent. Seating a table changes the context for an order. A sales channel changes pricing. A delivery address can become a dependency of a transaction. A role determines whether an action is permitted at all.

The operating environment adds more constraints. A workspace may switch between Arabic and English, right-to-left and left-to-right layouts, SYP and USD, several employee roles, different device types, degraded connectivity, restaurant-operated delivery, and multiple restaurants under one account.

This changes the product question. Instead of asking only whether a feature works, we have to ask what it knows, which state it is allowed to change, whether that state is current, and what should happen if confirmation becomes impossible halfway through the operation.

Chapter 3 · Case II

The request can fail even when the operation succeeds

A lost response creates a different kind of uncertainty: the client does not know whether it is safe to try again.

The ambiguous outcome

The device sends a Create Order request. The server successfully creates the order, but the network drops before the response reaches the device. From the device's point of view, the request appears unsuccessful. The system now has to distinguish between an operation failure and a response failure.

If the application retries by creating a brand-new order, it may produce a duplicate. A retry must instead represent the same intended operation.

Replay also has dependencies

Queue recovery is not simply “send everything again.” A new delivery address may need to synchronize before the order that references it. A temporary Host Stand identity may need to be remapped before a later action can be replayed. Actions for another restaurant under the same account may need to wait until that restaurant is selected.

The queue therefore preserves identity, ordering, restaurant scope, and partial dependency progress. Transport failures, authentication failures, business-rule failures, and inventory conflicts also remain distinguishable because they require different recovery behavior.

Visible recovery

Sync does not treat “internet restored” and “all operations synchronized” as equivalent statements. Pending work may still be waiting, retrying, completed, failed, blocked, conflicted, or awaiting review. Failed and conflicted entries remain visible rather than disappearing from the queue.

Reliability is not only preventing failure. It is making failure understandable.

Weak connection is not the same as offline

A device may report internet connectivity while the backend path is slow, unstable, intermittently unreachable, or recovering. Treating that state as simply online can cause repeated loaders, duplicate refreshes, and unnecessary retries.

On a degraded path, Sync keeps cached content visible, reduces background work, coalesces duplicate refreshes, and prioritizes the active operational surface. Recovery requires confirmed backend reachability rather than a change in the device's connectivity icon alone.

Chapter 4 · Case III

Shared state does not require a shared interface

The owner, floor manager, cashier, waiter, receptionist, kitchen operator, and driver work with the same restaurant state, but they do not need the same abstraction over it.

Roles

The product decision was to keep shared data underneath role-specific operational surfaces. A host needs table capacity, arrival state, and active sessions. A cashier needs order and payment decisions. A driver needs assigned work and delivery progress. An owner needs broader control and inspection.

Permissions are therefore more than navigation restrictions. They determine which actions are safe. Offline cash orders, for example, are deliberately limited to owners, floor managers, and cashiers; a waiter, receptionist, kitchen account, or delivery account cannot enter the same queue flow.

Permission design is part of workflow design.

Arabic and right-to-left operations

The same workflow may appear in English left-to-right or Arabic right-to-left. Localization changes more than labels: it affects navigation, reading order, typography, form alignment, currency presentation, mixed-direction content, action placement, and printed output.

English · LTR

العربية · RTL

Platforms change the environment

Sync runs across mobile, PWA, and desktop environments, but the same capability does not imply the same interaction conditions. Installation, lifecycle, notification behavior, update delivery, storage, background work, and offline startup differ by platform.

Offline data was not enough—the application itself had to boot offline

An installed PWA can retain valid restaurant data and still fail offline if the application shell, graphics engine, core bundle, session path, or required deferred code cannot start. Offline support therefore has two layers: the data must survive, and the application capable of reading that data must survive too.

Physical-device testing exposed conditions that browser-based acceptance had not reproduced. A same-origin engine dependency, offline PIN recovery, deferred loading, and version handoff all affected whether a previously installed application could reopen in airplane mode. The boot architecture evolved to keep the shell, Flutter engine, core bundle, default dashboard, fonts, and locales inside the boot package while preserving explicit session and update checks.

Chapter 5

What remains a product decision

The architecture now has explicit answers for several uncertain states. Closed beta still has to establish whether those answers match sustained restaurant use.

Trade-offs we chose

Current beta status

Sync is currently in closed beta in Syria. The current product demonstrates implemented system behavior, not yet validated adoption or commercial performance.

What is still unanswered?

1. Which offline workflows are genuinely valuable in day-to-day restaurant use?
2. How often does manager reconciliation occur in practice?
3. Is Sync Center understandable enough for nontechnical restaurant staff?
4. Which role boundaries work in real teams, and which need adjustment?
5. How much onboarding complexity is acceptable before restaurant owners lose interest?
6. Which platform becomes the dominant operational surface in practice?