ProblemConnectivity
The system stops when the internet goes down
Much software is designed for places where the connection never drops. In much of Namibia it does, and a system has to be designed for that from the start.
A system stops without internet when every action must reach a server first. Software can be built the other way round: records are saved on the phone or computer straight away and sent to the server when a connection returns. First check whether the real problem is the connection, which may be cheaper to fix. If staff genuinely work where there is no signal, ask for offline working from the start. It adds about 20% to a build.
What you see, and what it usually means
| What you see | What it usually means |
|---|---|
| The screen spins and staff give up | Each tap waits for a reply from a server that cannot be reached. |
| Field staff write on paper and capture it later | The system does not work where the work happens. |
| Sales stop when the network drops | The till or order screen cannot save anything locally. |
| Records are missing after a bad-signal day | Entries were lost when a save failed and nobody noticed. |
| It works in the office and nowhere else | It was built and tested on office Wi-Fi. |
What you can do yourself
These cost nothing but time. Do them before paying for software, including ours.
Find out where it fails, and when
Keep a one-week note of each failure: place, time, network. A pattern usually appears.
Test the connection, not the system
Run a speed test at the spot where staff work, on the network they use. If it is the Wi-Fi or router, that is a different and cheaper fix.
Try a second network
A SIM from another operator in a spare phone used as a hotspot is a cheap backup for an office.
Ask your current supplier about offline mode
Some products have one that was never switched on.
Agree a paper fallback meanwhile
One printed form, and a rule for who captures it and by when, so that nothing is lost on a bad day.
Today, and with a system
Today
- Work stops when the signal drops
- Records written on paper and captured later, or never
- Lost entries nobody notices
- Staff blame the system and stop using it
With a system
- Every record saved on the device at once
- Sent to the server when a connection returns
- A clear mark showing what has and has not been sent
- Small pages that load on a weak signal
- Staff collect records in the field, on farms, at villages or on the road.
- A sale or a patient cannot wait for the network.
- The connection is already as good as it can be made at that place.
- Paper fallback happens every week and capturing it later is never finished.
What we would build
We agree which screens must work with no connection, because not all of them need to. Those screens save to the device first and synchronise later, and show plainly what is still waiting to be sent. Pages are kept small so they load on a slow connection, and we test on the kind of phone and network your staff really use.
Offline working adds 20% and about a week to a build. See it in the estimator. If the cause is your network rather than your software, ADA Tech handles that.
Common questions
Can any system be made to work offline afterwards?
Rarely, and not cheaply. Offline working changes how a system stores and sends its records, so it is best decided at the start. Tell any developer about your connection before they quote.
What happens if two people change the same record while offline?
A rule decides, and the rule is agreed in the scope: usually the latest change wins and the earlier one is kept in the history, or the clash is shown to a supervisor.
Does offline mean an app from the app store?
Not necessarily. A web app can keep working without a connection once it has been opened and installed from the browser. App or web app.
Describe the problem. We will send back a scope.
Say what is slowing the work down and who is affected. You get a one-page scope in plain words: what would be built first, how long it takes and what it costs. It is free, and you owe nothing if you do not go ahead.