Contents
An offline order-taking app stores the rep’s customers, catalog and prices on the device, saves orders locally and sends them as soon as the network returns. Offline mode counts for about $1,200 (€1,000)excl. VAT in my estimator, within a complete app of $6,800 to $22,400 (€6,000–€20,000)excl. VAT.
A sales rep who cannot enter an order because there is no signal in a store’s back room, a warehouse basement or a rural area goes back to paper. Then to re-entry, and errors. Offline mode is therefore not a nice-to-have: it decides whether the app gets used every day. Here is how it works in a web app, its pitfalls, and what it costs.
What a rep must be able to do without a network
- open the app and find the day’s customers;
- view the customer record, history and terms;
- browse the catalog with the customer’s prices;
- enter an order and get it signed;
- clearly see what is waiting to be sent.
As soon as the network returns, the app sends pending orders, fetches updates (prices, stock, new customers) and confirms to the rep that everything went through.
How offline works in a web app
An installable web app (PWA) relies on two mechanisms:
- a service worker, which caches the app itself so it opens without a network;
- a local database in the browser, which holds the rep’s data and a queue of orders.
On launch, or at regular intervals when the network is available, the app syncs this database with the server. There is a background sync interface, but MDN lists it as “limited availability” because it does not work in several widely used browsers (checked October 2026). So I do not rely on it: sync runs when the app is open and the network comes back.
Pitfalls to plan for
| Pitfall | What can happen | How we avoid it |
|---|---|---|
| Stale data | A price changed since the last sync | Sync time shown, price revalidated on submit |
| Conflicts | A customer record edited in two places | Merge rule defined per type of data |
| Duplicates | An order sent twice on an unstable network | Unique ID generated on the device |
| Storage cleared | The browser deletes local data | App installed, persistent storage requested, frequent sync |
| Volume | Catalog too heavy for the device | Data limited to the rep’s territory, optimized images |
Storage deserves a closer look. Browsers can delete a site’s data in some cases. Safari, for example, deletes script-created data from a site with no user interaction for seven days of browser use; web apps added to the home screen have their own counter, and WebKit says it does not expect their first-party data to be deleted (WebKit blog). Browsers also let a site request persistent storage, protected from automatic eviction, as explained in MDN’s documentation on storage quotas (sources checked October 2026). In practice: we have reps install the app on their home screen, request persistent storage, and sync often, so an order never stays only on the device for long.
Budget and timelines
Offline mode is not a module added at the end: it changes how the app is designed. So it is decided during scoping. These ranges exclude VAT and are based on my public price list.
| Scope | What it includes | Indicative budget | Timeline |
|---|---|---|---|
| Order taking with offline mode | Customers, catalog, prices, offline ordering and signature, sync | $9,000 to $15,700 (€8,000–€14,000)excl. VAT | 1 to 2 months |
| Connected order taking | The above + ERP connection, conflict handling, dashboard | $15,700 to $22,400 (€14,000–€20,000)excl. VAT | 2 to 3 months |
| Complete sales tool | The connected app + visit tracking, routes, CRM | $22,400 (€20,000)excl. VAT and up | 3 to 5 months |
In my estimator, the “notifications and offline” block counts for $1,200 (€1,000)excl. VAT; it is the design around it that takes care. The estimator calculates a complete range, and the page on the order-taking app for field sales reps describes the full feature set.
When offline mode is not needed
- Reps who always have coverage, in cities and offices: a simple fallback (clear message, draft kept) is often enough.
- A read-only app: a cache of the last pages viewed may be enough, without full sync.
- Occasional use: if the app is used once a week, the complexity of full offline mode is not always justified.
In other cases, especially for reps in rural areas, large retail or warehouses, I recommend it from the first version.
How the project works
- A 30-minute call (free): your reps, their working conditions, your ERP.
- Scoping (1 to 2 weeks): data to carry on the device, sync and conflict rules, fixed quote.
- Clickable mockups tested on your reps’ devices.
- Development in batches, with real-world testing: airplane mode, unstable network, full device.
- Rollout, training, three months of included support.
For the technical side, see also the PWA page.
Frequently asked questions
Can a web app really work without a network?
Yes. A PWA uses a service worker to keep the app available and a local database in the browser for data. Once loaded, it opens and works without a connection, on iPad and Android alike.
What if two people edit the same customer offline?
That is a sync conflict. We define a rule in advance for each type of data: orders never contradict each other because each one is new, whereas a customer record change can be merged or sent for approval.
How long can a rep stay offline?
Technically, several days. In practice, I recommend syncing at least daily so prices, stock and orders stay reliable, with a visible indicator of the last sync time.
Can orders be lost?
The risk exists if the device is lost or reset before syncing. We reduce it with automatic sync as soon as the network returns, a clearly visible counter of pending orders and a request for persistent storage from the browser.