Does a Small Business Web App Need to Work Offline? What to Specify Before You Commission It

The short answer

A small business web app needs offline behaviour only for the tasks where work actually happens without a connection. If everyone uses it at a desk on stable internet, a clear error message may be all you need. If someone records data in a place with poor signal, you need to decide, task by task, what the app may do with no connection and what it may promise the person using it.

Either way, decide on purpose. Whatever the app does when the connection drops is a business decision, and it is better written down before the build than discovered afterwards. This article is practical guidance for writing that brief. It is not a standard, and it does not claim any particular feature exists in any particular product.

I use a hypothetical example throughout: a small team that walks through a rented storage building doing condition inspections and stock counts, where signal is weak in some rooms.

Five levels of offline, and what each really promises

Think of offline support as a ladder. Each step changes the scope of what has to be designed, built and tested, and each step makes a bigger promise. Choose the lowest step that protects your actual work.

Level one: a helpful connection error

The app notices it cannot reach the server and says so plainly: what failed, whether anything was saved, and what to do next. Nothing is stored for later. For many office tasks that is sufficient, provided the message is honest. The risk to avoid is a person assuming their work went through when it did not.

Level two: reading previously saved data

The app keeps a copy of chosen records so they can be viewed with no connection. Be careful to separate two things. According to MDN's guide to offline and background operation, a service worker, once installed, can fetch the resources for the pages it controls and add them to a local cache. When the needed resources are cached and the offline logic is implemented, that lets screens open without a network. It says nothing about your business data. An app can open offline and still show an empty inspection list, because nobody specified which records to keep.

This level raises the stale information question. The same MDN guide notes that a cache first approach is more likely to return a stale response, and that the best caching strategy depends on the particular app and how it is used. In business terms, a person reading yesterday's stock level may act on it. Decide which screens may show saved data, and require a visible last updated marker on each.

First time offline access needs preparation. A device that has never loaded those records has nothing to show, and no setting changes that. If staff will work in a weak signal area, the routine should include opening the app online beforehand, and the app should show whether the day's records have been loaded.

Level three: local draft capture

The person can fill in a form with no connection and the app holds the draft on that device. This protects typing effort, but it is not a submission. The label should say something like "saved on this device only", never just "saved".

A browser copy is not a backup. MDN's page on storage quotas and eviction explains that stored data is best effort by default: it persists while the site is under its quota, the device has enough space, and the user does not delete it in browser settings. A site can ask for persistent storage, though browsers handle that request differently. The same page says browsers may evict data in some situations, that private browsing data is usually deleted when the session ends, and that Chrome's own research found deletion to be very rare for regularly visited sites. So the right stance is neither panic nor trust. A local draft is a convenience copy with no promise of permanence. Your brief should say how long a draft is expected to last and what staff should do with a draft they care about.

For a local only design like this one, where drafts are not sent or synced anywhere, a draft is not expected to appear in a different browser profile or on a different device. If that matters to your team, say so in the brief, so staff know a draft typed on a phone will not be waiting on a laptop.

Level four: queued submission with server confirmed state

Here the app accepts a finished form offline and sends it when a connection is available. The wording matters most at this level. A queued item is a request waiting to be made. It is not a booking, a stock reservation, an assigned job or an accepted record until the server has accepted it. If two people queue changes for the same unit, the server decides what happens, and one may be refused.

The interface should therefore distinguish these states:

• Saved on this device only.
• Waiting to send.
• Accepted by the server.
• Rejected, with a reason a person can read and an action: edit and resend, or discard.
• Result unknown, for the case where the app sent the entry but never received an answer.

That last state deserves attention. If the connection drops after the server accepted an entry but before the reply arrived, the device cannot tell what happened. As a recommendation, not a guarantee of any product behaviour, the app should check what the server holds before offering a resend, so a stock adjustment is not applied twice. Specify that rule in plain words and test it.

Do not treat background sending as a given. The Background Synchronization API is designed to let a web app defer tasks to a service worker once there is a stable connection, but MDN marks it as limited availability because it does not work in some of the most widely used browsers. MDN's offline guide adds that browsers may stop service workers and limit retries. So make every sending behaviour an explicit acceptance requirement: a visible send button, a retry when the person reopens the app, and a retry when they return to a connection. None of these is something a browser does for you by default. If background sending is added where supported, treat it as a bonus.

Level five: multi user offline edits and conflicts

This level covers several people changing the same records while disconnected, with the system reconciling them afterwards. It brings the most scope and complexity because it forces business decisions that no code can make for you. If one person marks a unit damaged and another marks it clear, which change wins? Is it the later edit, the more senior role, or neither until someone looks? Which fields can be merged, and which need a person to choose? One option to consider is avoiding the situation by rule: one assigned editor per record at a time, or offline users may add new entries but not change existing ones.

Decisions to make before anyone builds

Who can edit what, offline? Offline permissions can be narrower than online ones. Tie them to your access roles.

How stale may saved information be, and how is its age shown to the reader?

What may sit on the device? Decide which sensitive fields must never be cached at all, whether shared devices are allowed, and what happens to local data on sign out. Decide which access you can revoke online, and be honest that a device that is offline cannot receive a revocation until it reconnects. Decide how unsent data is handled when a person leaves or loses a device, and do not assume a remote wipe will work. If regulated data is involved, get proper advice outside this article.

What happens when sign in expires while items are waiting? Decide whether queued items survive until the person signs in again.

Where do backups and recovery fit? Server acceptance is not the same as durable storage. The server side needs its own backup and recovery plan, and the device side needs its own rules for drafts and queued items. Both deserve suitable protection.

A requirements example you can adapt

This hypothetical brief is guidance for the inspection and stock count scenario.

Purpose: inspectors record a condition note and a counted quantity for each unit in rooms with unreliable signal.

Offline reading: the day's assigned units are loaded when the inspector opens the app online. Each screen shows when its data was last refreshed. If the data was never loaded, the app says so instead of showing an empty list.

Offline entry: the inspector can complete the inspection form without a connection. Entries are labelled saved on this device only until sent.

Sending: entries show waiting to send until the server accepts them, then accepted. Sending happens by a visible send button, when the app is reopened, and when the person returns to a connection. These are acceptance requirements. If no answer arrives, the entry shows result unknown, and the app checks the server record before allowing a resend. The app never states that stock is reserved or adjusted until the server has accepted the entry.

Rejections: if the server refuses an entry, for example because the unit was reassigned, it stays visible with the reason, and the office manager can resolve it.

Editing: only the assigned inspector may change a unit's offline entry. Office staff edit only online.

Device rules: no customer contact details are cached. On sign out, the app warns about unsent entries before clearing local data.

Out of scope: automatic background sending, and offline edits to existing records by more than one person.

The structure above follows the same pattern as how to write acceptance criteria for a small web app.

Acceptance checklist

Treat each line as a test performed on real devices with synthetic records.

• Airplane mode before opening: open the app on a device that loaded the data and on one that did not. The first shows saved records with a refresh marker. The second explains what is missing.
• Airplane mode mid task: start a form, lose the connection, finish it. The label says saved on this device only.
• Close and reopen: close the browser fully while offline, reopen, and confirm drafts and queued items are listed with the right labels.
• Sign in expiry: let the session lapse while items are waiting. Nothing is silently discarded and the person is asked to sign in.
• Reconnect: restore the connection and confirm items become accepted only after the server responds, and that manual retry works.
• Lost response: interrupt the connection after sending and confirm the app shows result unknown and checks before resending.
• Different browser or device: sign in elsewhere and confirm local drafts are not expected to appear, and accepted records do.
• Conflict: have two people change the same record, one offline. The outcome matches your written rule, and a rejected change is visible to a person who can resolve it.
• Shared device: sign out and check what remains on the device.

Frequently asked questions

If the app is installed on the home screen, does it keep my data offline?

Not by itself. Installing can change how the app opens, but installation alone is no proof that business data is available offline or that it will last. Browser policies differ, and what is actually kept depends on how the app was built to store data. If offline access to records or drafts matters to you, ask for the storage design to be written down and tested on the browsers and devices your team really uses.

Can the app just sync in the background?

Sometimes, but do not specify it as a guarantee. Browser support differs, work done in the background is limited in time and retries, and the registration has to happen while the app is open. Ask instead for the explicit send, reopen and reconnect behaviours listed above, and confirm in which browsers your team will use the app.

Do I need conflict handling?

Ask whether two people could change the same record while at least one is disconnected, and whether a wrong result would cost money or trust. If not, a simple rule may do: one editor per record, or offline adds only. If so, write down who wins, which cases need a person, and how that person is told, before design starts. If you want to talk through what your situation needs, the work with me page explains how to get in touch.