This is a track from the corporate development block. It comes in as the product grows from MVP to MMP and MLP. The track costs $4700.
For some users an unreliable connection is simply normal: warehouses, building sites, field visits to customers, factory floors, the road between cities. For them offline mode is not a nice extra. It is the condition without which nobody uses the app at all.
The business loses money here on small things that add up. A storekeeper writes a delivery down on paper because the app froze, and in the evening someone types it in by hand. A courier cannot mark a delivery in a basement. A customer on a train closes the shop because the catalogue would not load. An app offline mode and a smooth interface remove those gaps.
What is included
- A unique interface switching scheme tailored to the application logic.
- Data caching.
- Synchronisation when there is no internet.
Interface switching scheme
Smoothness starts with the user not waiting for a page reload after every action. Screens switch instantly, data loads where it is needed, and an action shows up in the interface straight away, even before the server replies. The scheme is built around the logic of the specific app: a warehouse terminal and a customer shop need different ones.
Data caching
We decide in advance which data must always be on the device: reference lists, the catalogue, current orders, tasks for the shift. These are stored locally and open without a network. For each type of data we define how long the copy counts as current and when it must be refreshed.
Offline synchronisation
Actions taken without a connection are queued on the device. When the connection returns, the queue goes to the server in the right order, and the user can see what has been sent and what is still waiting. Resending must never create duplicate orders or payments.
The hardest part of offline is conflicts, not storage
Storing data locally is easy. The hard question is what to do when two people changed the same record while each was offline. The conflict rule is a business decision, not a technical one: it is agreed with the client and recorded just like the other rules in the server-side business logic.
Typical options are that the latest change wins, that the role with wider rights wins, or that the conflict is shown to a person to resolve by hand. Stock levels and the text of a note need different answers, and that has to be settled before development.
How this connects to earlier stages
Preparation for a PWA (iOS, Android) is laid down during front-end markup. If it was skipped then, part of the work has to be redone here. It is one of the few cases where saving money at an early stage turns directly into rework.
What the business gets
- Field and warehouse staff work in the app instead of on paper that has to be retyped later.
- Customers can browse the catalogue and build an order even on a poor connection.
- Data entered offline is neither lost nor duplicated.
- The app feels fast, because it does not wait for the server at every step.
Cost and what it depends on
The track costs a fixed $4700 and covers the interface switching scheme, caching and synchronisation. Before work starts, the consultation establishes which scenarios must work offline, which data is kept on the device and how conflicts are resolved. If PWA preparation was not done during the markup stage (priced from $0 to $2400), that work is costed separately.
What breaks if you cut corners
- The connection drops, and the data entered disappears along with the open form.
- Once the connection is back, an order is sent twice or lost.
- Two employees overwrite each other's changes, and nobody knows which version is right.
- The user cannot tell whether their actions were sent and repeats them by phone.
Examples from our work
The PWA mobile application for customer communication installs on a phone without an app store and works without the internet. It caches the main data, lets users browse products, options and orders and build a basket offline. As soon as the connection is restored, actions are synchronised with the server, and order data goes to the CRM.
A counter-example is just as useful. In Goal Decomposer the plan is stored in the browser, with a copy on the server under an anonymous device identifier: if the browser copy is cleared, the plan is pulled back from the server. But the plan itself is built by an AI model, so without a network the app cannot create one. That is an honest boundary: "installed as a PWA" does not yet mean "works offline", and the scope of offline mode is set by the scenario, not by the technology.
Where to go next
Related track: server optimisation. The map of the series is in the app development strategy.
If your staff or customers work where the signal drops, book a free consultation with an architect. We will work out which scenarios must work without the internet, and after the consultation we will send a price and timeline broken down by stage.
