Offline-first isn't a feature in Bangladesh — it's the requirement

Every demo has wifi. The basement doesn't.

That sentence is most of what we've learned building software for Bangladeshi businesses. The places where the software has to work — a mall's underground parking, a shop counter at peak hour, a coaching centre in a converted flat, a delivery rider's phone between towers — are systematically the places with the worst connectivity.

And the moments when it has to work are exactly the moments when it must not stop: a queue is forming, a customer is waiting, a class is starting.

What offline-first is not

Three things get called offline support that aren't.

• Offline caching. The app shows the last data it fetched but can't accept new input. Fine for a news app, useless for a counter.
• A queue with an error toast. Actions get buffered but the interface still says something has gone wrong, so users stop trusting it and start writing things on paper "just in case".
• Retry logic. Re-attempting a request more often doesn't help when there's no connection for four hours.

Offline-first means the local device is the source of truth for the work being done. The record is real the moment it is saved locally. Synchronisation is a background concern that the user is never asked to think about, and never blocked by.

The test, in ten seconds

Turn on airplane mode. Complete one real task end to end — create a record, save it, close the app, reopen it. Is the record there? Now reconnect. Does it reach the server without you doing anything?

Plenty of apps advertising offline support pass the first half and fail the second. The failure is often silent, which is worse than a visible error: the user believes the work is saved, and it isn't.

Four decisions that make it work

1. The client generates identifiers

If a record's ID comes from the server, nothing can be created offline without a placeholder — and placeholders leak into every relationship, every reference and every bug report. Generate globally unique IDs on the device from the outset. This one decision is close to irreversible later, which is why it has to be made on day one.

2. Decide the conflict rule per entity, in advance

Two devices edit related records while disconnected. Something must decide the outcome, and "last write wins" quietly destroys data in a surprising number of business cases.

The rule differs by entity: for an append-only financial ledger, both entries are kept and nothing is overwritten; for a student profile, last-write-wins is usually fine; for stock levels, the operations must be merged as deltas rather than absolute values. Deciding this per entity, before writing sync code, is the difference between a system that heals and one that corrupts.

3. Never block the interface on the network

Save locally, confirm to the user immediately, sync afterwards. If a user ever waits on a spinner to record a sale, the design has already failed. A small, non-intrusive indicator of sync state is enough — visible if you look for it, invisible if you don't.

4. Make sync state observable, not intrusive

Owners need to be able to answer "is everything backed up?" without interpreting a technical status. One clear indicator — everything synced, or N items pending — is plenty. Detailed logs belong somewhere findable and out of the way.

The goal isn't that the app survives being offline. It's that nobody at the counter ever finds out whether it is.

What it costs, honestly

Offline-first is meaningfully harder to build. Being straight about that:

• More engineering time. A local schema, a sync layer and conflict rules are real work on top of the feature itself. Expect a noticeable premium on the first version.
• Harder testing. You have to simulate partial connectivity, clock skew between devices, and interrupted syncs — none of which appear in a normal test run.
• Migrations get serious. Changing the local schema means migrating databases on devices you can't reach, some of which have been offline for weeks and are several versions behind.
• Some things genuinely can't be offline. Payment authorisation, live availability, anything requiring consensus with a server. Those must fail clearly rather than pretend.

And it is occasionally the wrong choice: a single-user analytics dashboard, an internal tool used only at head office on fixed wifi, or a product where the entire value is real-time collaboration. Offline-first is a response to a specific operating environment, not a universal virtue.

Why we still default to it here

Because the cost of being wrong is asymmetric. If you build offline-first and the connection turns out to be excellent, you've spent extra engineering effort and the user never notices. If you build cloud-only and the connection is poor, the software fails in front of a customer — and the operator quietly reverts to the paper register that never needed a signal.

That reversion is the real risk. Software that fails at the counter doesn't get bug reports. It gets abandoned, politely, and the register comes back out of the drawer.

What to ask a vendor

1. Can I complete a full transaction in airplane mode? Show me, on the actual device.
2. What happens if two people edit the same record while both are offline?
3. How long can a device stay offline before syncing becomes a problem?
4. Where is the data stored, and what leaves the device? (Separate question from whether it works offline.)
5. If your servers were unreachable tomorrow, could my staff still work?

The last one is the most revealing, and the one most likely to produce a pause.