Will Your Business System Work When the Internet Is Down? What to Decide About Offline Use

The connection at your second outlet drops every Saturday afternoon, just when the queue is longest. In the warehouse, the Wi-Fi never quite reaches the back racks. On a site visit, there may be no signal at all. If you are about to commission a custom business system, a fair question is: what happens to the work when the internet is down?

This guide is for owners and managers of small and medium businesses with outlets, warehouses or sites where the connection is patchy. It helps you decide, before a developer starts, which tasks must keep working with no connection and which can wait, what "works offline" can and cannot mean, and how to write the need into the brief so the quote covers it. It is general guidance about decisions, not code or any supplier's method.

Start with the tasks, not the technology

"Offline" is not one feature. It is a decision about each task. A system that stops for ten minutes may be harmless for a monthly report and a disaster for ringing up a sale. So list what staff actually do at the counter, in the store room and on site, then sort every task into one of three groups:

• Must keep working. If it stops, money or customers are lost on the spot: taking an order or a sale, looking up a price, receiving a delivery at the dock, clocking in.
• Read-only is enough. Staff need to look something up but not change it, such as a customer's last order or a stock level that may be a few minutes old.
• Can wait. Nobody is harmed if it is done later: approving leave, running a report, editing product details, changing a price list.

Be strict about the first group, because it is the part that costs more (see below). A useful test: if this task stopped for an hour at 4pm on our busiest day, what would we do instead? If the answer is "carry on by hand without much trouble", it probably belongs in the second or third group.

Also note how often and for how long the connection fails, and ask the people who work there: the office may have a perfect connection that the shop floor never sees.

What "works offline" can and cannot mean

When a supplier says a system "works offline", it can mean very different things. Ask which of these they mean:

Two limits are worth understanding in plain terms. First, "record now, sync later" means other people do not see your entry until it syncs. Head office will not see the offline sale, and another outlet will not see that the stock has gone. Second, anything that depends on an outside party, such as a card payment approval from a bank, a message to a customer or a submission to a government or accounting service, cannot be completed without a connection, however good your own system is. Ask your payment provider what its terminal does in an outage.

Whether you need a mobile app for this is a different question. A web app can keep some content available for viewing, but showing a page is not the same as recording orders safely. For that choice see web app or mobile app and signs you need a mobile app.

When two people change the same record: conflicts and duplicates

Offline use creates a problem that online systems rarely have: two people can change the same thing while neither can see the other's change. When the devices reconnect, the system has to decide what to keep.

A made-up example: the system says an item has 10 units in stock. Outlet A is offline and sells 3. Outlet B is also offline and sells 4. If each device sends back its own total, one reports 7 and the other 6, and whichever arrives last wins, so the system says 6 when the truth is 3. If each sends the movement instead (minus 3, minus 4), the system ends at 3. The result depends on a rule chosen in advance.

There are four common ways to handle a clash:

• Last write wins. The latest change to arrive replaces the earlier one. It is simple and fine for low-stakes fields such as a note or a phone number, but risky for quantities, prices and statuses, because someone's work disappears without a warning.
• Ask a person. The system flags the clash and a named person chooses which version to keep. It is the safest option for important records, but someone must be available and the screen must be clear about what differs.
• Merge by rule. The system combines both changes using a rule agreed in advance, such as adding stock movements instead of overwriting totals, or keeping both notes. Each rule has to be designed and tested.
• Block the change offline. Some edits are not allowed without a connection, such as changing a price or a customer's credit limit. This avoids the conflict altogether.

Duplicates are the other common trouble. If a device is offline when a customer is added, a second device may add the same customer. If order numbers come from the main system, a device with no connection cannot know the next number, so it needs a temporary reference that is replaced when it syncs. Decide, for each record type, how duplicates are spotted and who merges them.

These are business decisions, not technical ones. A developer can build any of the four approaches, but only you know whether losing the second entry is a nuisance or a real loss. Write the choice down for every record type in the brief.

A task-by-task decision table

Use this as a starting point for your own list. For many tasks, the simplest cover is not software at all.

If clocking in must work, see staff attendance, leave and claims and, if you run several outlets, multi-outlet management for how branches share stock and sales.

The cost and complexity trade-off

Offline use is not a switch you turn on. Each task in the "must keep working" group means extra design (what the screen shows with no connection), extra rules (conflicts, duplicates, what is blocked), extra testing (every state and every reconnection) and extra support later (what staff do when a sync fails). The more of the system must work offline, and the more people can change the same records, the more of all four you pay for.

Think of it as a ladder: a backup connection or paper fallback asks little of the software, a read-only cached view is a modest addition, a queue of entries is bigger, and full offline working across many record types is the biggest. Do not ask for the top rung for everything when only two tasks need it.

No price is given here for offline features, because it depends on the tasks, devices and rules. Gotka's published starting points are indicative: from RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps, indicative, confirmed by written quote. Offline requirements are scoped inside that quote like any other feature, so ask for them to be listed separately. For what else drives an app's price, see what a mobile app costs.

Cheaper ways to cover a patchy connection

Before paying for offline features, check whether a cheaper fix covers the real problem. These can also be combined.

Check the power too: a router with no electricity is offline, so a small battery backup for the router and the till may solve more than any software feature.

Write the need into the brief: an offline requirements template

A vague line such as "must work offline" will be read differently by you and the supplier. Replace it with a short section like this. The examples are made up.

Data stored on a device can leave the building with it, so decide who may use the offline functions and what happens if a phone is lost. How access is set up is covered in user roles and permissions. For the wider brief, see what to prepare before your first conversation.

Make sure the quote covers it

If offline use is not written down, you cannot assume it is included. When quotes come back, check each one against your offline section:

• Which tasks? Does it list them, or just say "offline mode"?
• Which conflict rule? Is there one per record type, and who resolves a clash?
• First load. A device usually needs to load its data while connected. What happens on a new device, after a reinstall or after a long gap?
• Testing. Is the pull-the-cable test part of acceptance?
• Later changes. A task you did not list that fails offline may be treated as a change request rather than a bug, so get the boundary in writing. See bugs versus changes after launch.

Also ask how offline work affects the schedule and the data loaded first; see how long a custom business system takes and moving your data into a new system. To compare quotes fairly, put the same offline section in front of every supplier; how to compare custom software quotes shows how.

Test it in acceptance: the pull-the-cable test

The only way to know whether offline use works is to take the connection away. Add this to your user acceptance testing and run it on real devices in the real place, not on the developer's desk.

1. Load the system while connected and confirm the data is on the device.
2. Pull the network cable, switch off Wi-Fi or turn on flight mode. Note the time.
3. Do each "must work" task as staff would, and record what the screen showed and whether it worked.
4. Check that read-only tasks show their data and its age, and that blocked tasks give a clear message rather than a crash.
5. Change the same record on two devices while both are offline, to trigger a conflict, then check the outcome matches the rule.
6. Close the app and restart the device while still offline. Entries must survive.
7. Reconnect and watch what is sent. Count the entries made offline against what arrived: none lost, none duplicated, and any failure shown to a person.
8. Repeat with a weak or dropping connection, which can behave worse than none.

Record each run (task, device, what you saw, pass or fail), fix, then run it again. How you switch the team over (everyone at once or one outlet first) is a separate decision from this one.

Staff habits when the connection drops

A system that handles offline use well still fails if staff panic or improvise. Agree the routine in advance and put it on a one-page card at the counter, in the same way as the cheat sheets described in getting your team to use a new business system.

• Know the signs and the limits. What the screen shows when offline, what "waiting to send" means, what continues (orders) and what waits (price changes).
• Do not enter it again. If a screen did not confirm, check the waiting list before re-entering, or you create the duplicates you tried to avoid.
• Use the paper form properly. Numbered, filled in fully, entered the same day by a named person, and marked as entered so it is not typed twice.
• Know who to tell. One person, usually the system champion, and a phone number that does not depend on the system.
• Check at close. Someone looks at the waiting and failed lists before the shop shuts.

Practise the fallback once while nothing depends on it.

Checklist before a developer starts

• Every task sorted into must keep working, read-only or can wait.
• The longest offline period, how often it happens and how many devices, written down.
• A conflict rule and a named person for each record type.
• What the user sees offline, described in words.
• Offline items listed separately in the quote, with the first-load and device-loss questions answered.
• The pull-the-cable test in the acceptance plan.
• A one-page staff card and a paper fallback with a catch-up rule.

Common mistakes

• Asking for "everything offline". It is the most expensive and slowest option, and rarely needed.
• Leaving conflicts to the developer. Which version wins is your decision.
• Testing only on the office connection. The problem is on the shop floor and the back racks.
• No staff routine. Without one, people re-enter orders and create duplicates.
• Ignoring power. A power cut can look like an internet fault.

Where Gotka Technologies fits

Gotka's App & System Development service builds mobile apps, web apps and business systems, from an indicative RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps, each confirmed by a written quote once your needs are scoped. This guide is general advice and does not describe any offline or synchronisation method, so if offline use matters, ask any supplier, Gotka included, to state in the written quote which tasks work with no connection, the rule for conflicts and how it will be tested. The team is reachable through the contact page.

Key terms used in this guide

• Offline: working with no connection to the internet or to the main system.
• Sync: sending what was recorded on a device to the main system, and receiving what changed there.
• Queue of entries: new entries saved on the device and sent in order when the connection returns.
• Cached view: a read-only copy of data saved on the device when it was last connected.
• Conflict: two people changing the same record before either can see the other's change.
• Catch-up rule: the agreed way and deadline for entering paper records once the connection returns.