Progressive Web App development

What this actually solves

Two quite different buyers arrive at this page.

The first wants a mobile app and has looked at what building one costs. Two codebases, two store review processes, a fresh approval every time a price changes, and a budget sitting well above this range. What they actually want is narrower than an app — they want their icon on the customer's phone, so that the next time someone is deciding where to order from, the business is a tap away rather than a search away.

The second has a connectivity problem. Their people work where the signal is poor — delivery riders between buildings, field staff at sites, market traders, anyone in a basement or a lift. The web app they use loses its connection several times an hour, and every loss means re-entering something. For them, offline behaviour is not a feature; it is the difference between a tool that gets used and one that gets abandoned.

A Progressive Web App answers both with the same two additions to an ordinary website. A manifest that tells the phone the name, icon and colours to use, and a service worker — a small script that runs in the background and can serve content the phone has already seen. The result installs without a store, updates the moment you publish, and runs from one codebase.

What it is not is a rescue. A PWA wraps whatever is underneath it. If the site is slow or awkward on a phone, installing it produces a slow, awkward app that people now blame more, because it looks like something that should behave better.

What we do, and in what order

1. Check the site is worth installing, and say so if it is not. Real-device performance, mobile layout, and whether the core task can be completed on a phone at all. Where something obvious is in the way, that gets fixed or scoped first. Starting here is not a formality — it is the step that decides whether the rest of the money is well spent. One to two days.
2. Agree exactly what must survive a lost connection. This is the conversation that defines the build, and it is more specific than people expect. Which screens must open with no signal, which data may be a little stale and which must never be, and what should appear when someone tries to do something that genuinely requires a connection. The answers are written down, because they become the caching rules. One to two days.
3. Build the manifest and icons. Icon set at every size the platforms ask for, including maskable variants so Android does not crop the logo badly, name and short name, theme and background colours, display mode and start URL. Small, unglamorous, and the part that makes an installed app look deliberate rather than like a bookmark. One day.
4. Write the service worker, with updates designed in from the start. Built on Workbox, or through Serwist or next-pwa on a Next.js site. A caching strategy chosen per resource type rather than one blanket rule, and an explicit list of what must never be cached — anything authenticated, anything priced, anything that changes per user. Then the part most implementations skip: how an already-installed user finds out a new version exists and how they get onto it, with a visible prompt rather than a silent wait. One to two weeks.
5. Test on real phones, not emulators, and separately per platform. A physical Android device and a physical iPhone, installed from the home screen, in aeroplane mode and on a throttled connection. Install flow, offline screens, update flow, and notifications where they are in scope. Emulators are convincing and they do not reproduce how a real phone evicts storage or handles a half-open connection. Three to five days.

What moves the price

The range is $1,500–$8,000 and three factors decide where you land.

Reading offline versus writing offline. Serving content someone has already loaded is well-trodden. Accepting input with no connection, holding it safely, and sending it later without duplicating it when the signal returns is a synchronisation problem, and it is the single largest jump inside this range.

Whether the site is ready underneath. If the site is modern and quick and only needs the installable shell and a sensible cache, this sits near the bottom of the range. If speed, mobile layout or structure need attention first, that work is real and is priced as itself rather than hidden inside the PWA line.

Notifications and how much of the platform difference you want covered. Android-only notifications are one job. Making the experience feel intentional on iPhone as well — working within its install flow and its storage behaviour rather than pretending they match Android — is more, and it is usually worth it because it is where the complaints come from.

What usually goes wrong

Nobody writes down the iPhone limitations before the build. You test on Android, find the install prompt and the notifications working exactly as described, and are delighted. Then you open it on your own iPhone, where installation is a manual step buried in the share sheet and notifications behave differently, and the whole project feels oversold. Nothing was broken. The list simply belonged in the proposal, where it can be a trade-off, instead of arriving as a surprise at handover.

Stale content with no way out of it. A cache-first service worker is the fastest thing to ship and the easiest to get wrong. Users who installed in month one keep seeing month one — old prices, an old menu, a removed product — and the site looks correct to everyone testing in a normal browser. Worse, they have no mechanism to escape it, because clearing a service worker is not something a customer knows how to do. Update handling is not a polish item; it is the second thing to design.

Offline writing is quoted as if it were offline reading. The brief says the form should work with no signal, everyone nods, and it is scoped as another cached page. It is not. It needs a local queue, a rule for what happens when the same submission is retried, and a clear signal to the person that their entry has been stored but not yet sent. Discovered mid-build, this is where PWA projects overrun.