Powstania Warszawskiego 15
31-539 Kraków
The first question we ask when a client says the app has to work offline is not technical. It is whether the offline they mean is the offline we mean. Usually it is not, in either direction. This article separates the three things people mean by offline mode in mobile apps, what each one costs to build, and what changed in two of our own projects when the app met a river with no signal and a technician with no patience.
August 18, 20268 min read"It has to work offline." Almost every field project we scope contains that sentence, and almost every time the two sides of the table picture something different. The client pictures a technician opening the app in a basement and seeing today's jobs. We picture two devices, three days without coverage, and a form definition that changed on day one.
Neither picture is wrong. They are different products that happen to share a name. So the first thing we do is not estimate. It is ask which one is being bought, because that answer moves the number more than the feature list does. Everything below is the long version of that conversation.
The lightest meaning. The app shows what it downloaded while it had a network. Today's jobs, the customer's address, the last report, the map of the stretch you are on. Nothing new is created without a signal, or if it is, the user is told to try again later.
This is a cache with a good user interface. It is worth having, it is quick to build, and it covers a real share of "we lose signal in the car park" complaints. It is also where most off the shelf tools stop, which is why the next two definitions are usually what a custom project is actually about.
Here the user does the job without a network and the app promises to deliver it. A checklist completed, photos attached, a signature captured, a status changed. All of it sits on the device until coverage returns, then goes out in the right order and exactly once.
The promise is the product. Every piece of engineering underneath it exists so the user never has to think about whether something went through: a local store that survives the app being killed, an outbox with a retry state per record, uploads that resume rather than restart, and identifiers that make a repeated send harmless.
What decides adoption is that the promise is visible. Each record shows its own state, in words the user can read. Synced. Pending. Needs review. The moment a technician cannot tell whether an hour of work is safe, the app becomes paper with extra steps, and we have watched that happen.
On TimeFix, a field service app for technicians, the gaps did not produce complaints. They produced workarounds. Technicians started writing things into the notes app on their own phones, and from that day the notes and the system disagreed. Reports were built from one, the truth lived in the other.
The same project taught us that requirements arrive on the job, not in the meeting: the work timer had to keep counting when the screen locks and when the technician places a call from inside the app. Field requirements surface in the field. Plan the project so they can.
The third meaning is where offline stops being a feature and becomes the architecture. The device is the working store for the whole shift, or the whole voyage. Reference data has to be present before it is needed. Definitions change while devices are away. Two people touch the same record from different places. And the app is expected to just work, for days if necessary.
This is the offline our offline first app development work is built for, and it is a system, not an app: mobile, a sync layer, a backend that understands versions, and an office view. It is also the one where the schema decides everything, which brings us to a river.
Liniowiec is a river navigation app we built in Flutter for inland waterways in Poland, over 1,000 km across more than 18 rivers, with offline maps as the core of the product. A skipper in the middle of the river cannot depend on a signal, so the map and the routes have to be on the phone before the boat leaves.
The way it works is quiet. When an administrator adds new routes in the backend, the app notices on its next start and loads them in. The user does nothing and downloads nothing by hand. The maps themselves are not heavy, so this is invisible in practice, which is exactly how reference data in an offline product should behave.
The decision we are most pleased with is not visible on any screen. We spent a serious amount of time on the database schema before building: routes are versioned, and the relations between routes, points and the data attached to them were designed properly rather than added as we went.
Had that been done quickly and without thought, the same app would have ended up as a mess of data by the end of its first season.
That is the general lesson for the third kind of offline. In a connected app a weak schema is a refactoring ticket. In an offline one it is copied onto every device in the field, and every device has to be reconciled after you fix it.
Stage two of Liniowiec, which extends the map stack, adds water level data and brings the app to WCAG AA, is built on that same schema, which is the best evidence that the time was well spent.
The honest answer differs by what the app is for, and it is worth saying out loud, because offline three sold to a business that needs offline one is a waste of their money.
We quote fixed prices, and a fixed price is only honest if both sides mean the same thing by the words in the scope. "Works offline" is the phrase most likely to break that. Written as offline one and built as offline three, the supplier loses money.
Written as offline three and built as offline one, the client discovers it in a basement, on a real job, with the notes app open.
So the definition goes into the scope document in plain words: what the user can see without a network, what they can do, for how long, what happens to it afterwards, and who resolves the cases the rules cannot.
If the answers are still "it depends" after the first call, that is what a short discovery workshop is for, and it is a far cheaper place to find out than the field.
How that turns into a number, line by line, is in how a fixed price app quote is built, and the model itself is on fixed price app development.
What to bring to the call, by product type, is in how to brief an app development company. If you are in the US and wondering how a team in Poland runs a project like this from six hours ahead, nearshore Flutter developers in Poland gives the honest version.
The third kind is, because the sync layer and a backend that understands versions are part of the product. The first kind is a modest addition. Which one you need is the real question, and it is answered by how long your people are actually without a network and what they have to do in that time.
You can add a cache later. Moving from a connected app to a device as the working store is closer to a rebuild of the data layer, because the schema has to be designed for it. If there is any chance you need the third kind, design the schema for it on day one even if the first version ships less.
No. Both Flutter and React Native handle local storage, background work and sync well. Liniowiec is Flutter. The choice is made on your existing systems and the platform features you rely on, not on the offline requirement itself.
Rules decide it field by field where that is safe, and a person is asked where it is not. Completed records are locked so later changes become new versions with an audit trail. The point is that nothing is silently overwritten and the user is never left guessing.
Say what the user must be able to see without a network, what they must be able to do, for how long, and what should happen to that work afterwards. Add who else touches the same records at the same time. Those five answers place the project in one of the three definitions above, and that is enough to price.
Because every device holds a copy of it. In a connected app a weak model is fixed on the server. In an offline one the fix has to reach every device and reconcile everything they hold. On Liniowiec, versioned routes and correct relations between the data are what let new routes arrive by themselves without disturbing what is already there.
Co-Founder and CEO, Apps Value
Thomas takes the first call on most Apps Value projects. When the brief says the app has to work offline, that call is spent finding out which offline is meant, because the answer decides the scope and the number. If the light version is enough, he will say so. If it is not, you get a written scope and a fixed price before a line of code exists.
Where your people lose the network, for how long, and what they have to get done in that time. You will get a straight answer on which of the three you need, and if it is the real one, a written scope with a fixed price for a first version.
Book an intro call30 minutes, no preparation needed.