What it costs to add offline mode to an app you already have

$21,000 – $31,000 over 11–16 weeks, on an app that already works and has an API behind it. Holding the work on the phone is about $17,000 – $25,000 of that. The rest is getting it back.

$21,000 – $31,000: Offline plus sync, on an app that already exists
$17,000 – $25,000: Holding the work on the phone, on its own
11–16 weeks: Start to shipped

Written by

WhatWillMyAppCost

We build the estimator this site runs on, and we design and build custom mobile and web software for a living. Every figure below is the estimator’s own output, except the subscription prices, which are read off each vendor’s pricing page and dated.

Your app works fine. Right up until somebody walks into a basement. Then it spins, or it throws an error, or worse, it looks like it saved and didn’t. You hear about it from the person it happened to, usually a day later, usually with a job they have to redo.

Here’s what it costs to fix, why the second half costs more than the first, what makes the estimate move, and the one question you have to answer before anybody can build it.

What does adding offline mode cost?

$21,000 – $31,000, over 11–16 weeks. That assumes what most people mean by "an app we already have": it’s live, the screens are designed, and there’s a working API behind it that somebody can point at.

$17,000 – $25,000: Holding work on the phone with no service
$21,000 – $31,000: That plus getting it back to the server

If your API is half-built, or it was written on the assumption that a phone is always online, it’s nearer $24,000 – $34,000. That’s the common case and it catches people out, because the app is the part you can see and the server is the part that has to change.

Price your own version if your setup is different. The description’s filled in already.

Why is syncing more expensive than storing?

Because storing has one right answer and syncing has a hundred. Writing a record to the phone while there’s no service is a solved problem. Deciding what to do with that record two hours later, when the server has a different version of it, is not.

What people picture: The app saves to the phone, then uploads when the signal comes back. Done. Any developer can demo that in an afternoon and it’ll look exactly like the finished thing.
What actually has to be built: A queue that survives the app being killed. Retries that don’t double-submit. A rule for what happens when the same record changed in two places. Something that tells the user their work is still pending without nagging them. And a way to get a record back when all of that fails anyway, because it will.

One person edits a record on a phone with no service. Somebody else edits the same record on the web. Whose version wins? Nobody outside your business can answer that, every quote assumes an answer, and it’s cheaper to decide it now than to find out what somebody assumed.

What makes the number move?

Four things, and you already know the answer to all four.

How finished your API is. A working, documented one is the low end. One that assumes the phone is always online needs work on the server too.
How much of the app has to work offline. One screen is much cheaper than all of them, and one screen is usually enough.
Whether two people can touch the same record. If they can’t, most of the hard part goes away.
How long people stay disconnected. Twenty minutes is a different problem from a full day in a rural county.

That third one is worth pushing on. Plenty of apps look like they need conflict handling and don’t, because in practice one person owns a record at a time. If that’s true for you, say so early. It’s the single biggest thing that can come off this estimate.

How do you know it actually works?

You test it on bad service, not on no service, and that’s harder to arrange than it sounds. Airplane mode is the easy case. Everything works or nothing does. Simple.

The states that break apps are the in-between ones. One bar. A connection that dies partway through an upload. A phone that joins a customer’s Wi-Fi with no internet behind it, so it thinks it’s online and isn’t. Testing those takes a real phone in a real place, so it’s worth agreeing up front where that place is.

Worth doing yourself before you spend anything: take your current app to the worst place your people work and use it for ten minutes. Whatever breaks is the list.

Adding offline to an app that already exists runs $21,000 – $31,000, and roughly half of that is the syncing, not the storing.

Decide who wins a conflict before you get quoted, and narrow it to the screens people actually use without service. Those two things move the number more than anything a developer can do.

FAQ

Questions about going offline

How much does it cost to add offline mode to an app?

$21,000 – $31,000 over 11–16 weeks for an app that’s already live with a working API. Holding work on the phone is $17,000 – $25,000 of that; syncing it back is the rest. If the API needs work too, $24,000 – $34,000.

Can we just cache data instead?

If people only read in the field and never write, yes, and it’s much cheaper. Caching what somebody already looked at is a fraction of this. The cost arrives the moment they can create or change something while disconnected, because then two versions of the truth can exist.

Does the whole app need to work offline?

Almost never. Pick the screens people actually use with no service, which is usually one or two, and leave the rest needing a connection. Scoping it that way is the biggest saving available on this kind of work.

What happens if two people edit the same thing?

Whatever you decide. Common answers are last write wins, the server wins, or flag it for a human. All three are defensible and they cost roughly the same to build. What costs money is nobody deciding, because then it gets discovered late and rebuilt.

Will it work if someone is offline for a whole day?

It can, and the longer the window the more careful the syncing has to be. A twenty-minute gap rarely produces conflicts. A full shift does, and it also means more queued-up work to send at once, which is where retries and partial failures start to matter.

Does this need changes on the server too?

Usually. An API written for an always-connected app often can’t tell you what changed since a given moment, which is what the phone needs to catch up efficiently. That’s the difference between the low end of this range and the high end.

How do we test it properly?

On real phones in real places, not in airplane mode. The failures that matter happen at one bar, on a connection that drops mid-upload, or on a Wi-Fi network with no internet behind it. Budget for someone to actually go and stand where your users stand.