Progressive web app development, installable and offline-capable
A progressive web app gives you the useful parts of an app, installation, offline access and notifications, without asking customers to visit a store or waiting on review queues to ship a fix.
What is progressive web apps?
A Progressive Web App is a website built with app capabilities: it can be installed to a phone home screen, works offline or on poor connections, and can send push notifications, all without app store distribution. It suits Australian organisations with field staff, patchy regional connectivity, or customer tools that do not justify a native app.
Get a fixed written quote- Typical timeline
- 7 to 12 weeks
- What drives cost
- How much has to work offline, the number of device capabilities used, and whether an existing site is being converted or a new one built.
- Best for
- Field teams, regional coverage gaps and tools used repeatedly
- You own
- The codebase, the deployment pipeline and the user data
- Built with
- Service workers, offline data sync, web push, installable manifests
Your handover
Why offline capability matters more in Australia than the demos suggest
Most progressive web app examples are written for cities with dense coverage. The Australian reality is different in ways that decide whether a tool gets used. A technician on a mine site, an agronomist in a paddock two hours from Dubbo, a delivery driver in a basement car park in the Melbourne CBD and a nurse in a regional clinic all share the same problem: coverage that comes and goes without warning.
- 01Installable progressive web app with manifest and icons
- 02Service worker with per resource caching rules
- 03Offline data storage and background sync queue
- 04Documented conflict resolution rules per data type
- 05Web push notifications with user preferences
- 06Real device testing under throttled and interrupted connections
- Sync failure monitoring and offline usage analytics
- Deployment pipeline with staged rollout
- Staff rollout guide and training material
A conventional web application fails hard in those moments
A conventional web application fails hard in those moments. The form the worker spent four minutes completing vanishes, and after that happens twice they stop using the system and go back to paper. A progressive web app treats connectivity as unreliable by design. The interface and reference data are cached locally, work is written to device storage first, and submissions queue until a connection returns and then sync automatically. The person using it does not have to think about network state, which is the entire point.
The person using it does not have to think about network state, which is the entire point.
What makes an app installable and worth installing
The technical requirements are modest: a web app manifest declaring the name, icons and display mode, a service worker handling caching and offline behaviour, and delivery over HTTPS. Meet those and both major mobile platforms offer installation, placing an icon on the home screen that opens without browser chrome. Most users cannot tell the difference from a native app once it is there.
The harder part is earning the install
The harder part is earning the install. Nobody adds an icon for something they use once. Installation makes sense for tools people return to weekly: a job management app for tradespeople, a booking tool for regular customers, a portal for members checking something routinely. We build the install prompt to appear after someone has shown intent rather than on first load, because an immediate prompt is dismissed by most people and cannot easily be shown again. For client portals and staff tools the case is strongest, since usage is habitual by definition.
How the engagement runs
How we build and test one
Offline behaviour cannot be verified from a desk on good office wifi. It has to be tested the way it will be used, which means throttled connections, real devices, older handsets and deliberately hostile conditions.
- 01Stage 1Map the journeys that must work offline, which is rarely all of them and should not be
- 02Define the data strategyWhat is cached, how long it stays fresh, what happens on conflict
- 03Stage 3Build the application shell so the interface loads instantly regardless of network state
- 04Stage 4Implement the service worker with caching rules chosen per resource type
- 05Stage 5Build the queue and sync layer, including how the user is told an action is pending
- 06Stage 6Add push notifications where they earn their place, with granular preferences
- 07Stage 7Test on real devices with throttled and interrupted connections, and in aeroplane mode
- 08Stage 8Instrument sync failures and offline usage so you can see the system working in the field
Two decisions on your side that keep the project moving
We also involve the people who will use it earlier than is comfortable. A field crew will tell you within ten minutes that the form asks for information in the wrong order, that the buttons are too small for gloved hands, or that the flow assumes a job finishes where it started. None of that emerges from a requirements workshop in a meeting room, and all of it is cheap to fix before the sync layer is built around it.
The comparison
Progressive web app or native app
This is the decision most clients arrive wanting help with. There is no universal answer, but there is almost always a clear one once the actual requirements are written down rather than described in general terms.
Factor
Progressive web app
- Distribution
- A link, installable in a couple of taps, no store review
- Shipping a fix
- Deployed immediately to everyone
- Device capability
- Camera, location, storage, notifications and more
- Build and maintain
- One codebase for all platforms
- Discovery
- Found in search results like any web page
- Best fit
- Internal tools, portals, repeat use utilities
Native app
- Distribution
- App stores, with review times and policy compliance
- Shipping a fix
- Submitted, reviewed, then only on devices that update
- Device capability
- Full access, including Bluetooth peripherals and background processing
- Build and maintain
- Typically two, unless you use a cross-platform framework
- Discovery
- Found in store search, where ranking is its own discipline
- Best fit
- Consumer products needing deep hardware or heavy background work
Where the choice usually lands
The question that settles it fastest is what the app must do that a web page cannot. If the list is empty, or contains only installation and notifications, a progressive web app covers it at lower cost and with faster release cycles. If the list includes continuous background location, Bluetooth peripherals or heavy on device processing, native is the honest recommendation and we will say so rather than stretch the web to fit.
Sync conflicts, the problem nobody scopes for
Offline editing creates a question that has no default answer. Two crew members update the same job record while both are disconnected. When they reconnect, which version is correct? A naive implementation lets the last write win, which silently discards someone's work and eventually destroys trust in the system.
Some need an explicit conflict prompt because a human must decide
We settle these rules during design, per data type, with the people who do the work. Some records suit append only structures, where every entry is kept and nothing is overwritten. Some need field level merging, so two people editing different fields of the same record both succeed. Some need an explicit conflict prompt because a human must decide. The right choice depends on your operation, and it is a business decision dressed as a technical one. Anyone quoting an offline app without asking this question has not built one that survived contact with a real crew.
Where progressive web apps do well, and where they do not
The strongest fits we see are operational. Field service teams recording jobs, photos and signatures on site, with everything syncing when the vehicle reaches coverage. Logistics operations capturing proof of delivery without paying for rugged handheld hardware. Membership and booking tools people open weekly. Internal dashboards staff want on a home screen but which do not warrant store distribution. Organisations in construction and transport and logistics tend to recognise these immediately.
The poor fits are equally clear
The poor fits are equally clear. If you need continuous background location tracking, tight integration with Bluetooth hardware, or presence in an app store because your customers expect to find you there, build native. If your app is a consumer product where store discovery is a real acquisition channel, the store presence itself is part of the value. And if the tool is used once a year, nobody will install anything, so a fast ordinary website is the correct answer. Where the requirement is genuinely a full application rather than an enhanced site, the conversation moves to web application development or native mobile apps.
How we scope it
Four ways to scope your Progressive Web Apps project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Progressive Web Launch
A credible site, built properly, live sooner
Fixed written quote, agreed before work starts
- Installable progressive web app with manifest and icons
- Service worker with per resource caching rules
- Offline data storage and background sync queue
Progressive Web Growth
A site that has to sell or integrate with something
Fixed written quote, agreed before work starts
- Everything in Progressive Web Launch
- Documented conflict resolution rules per data type
- Web push notifications with user preferences
- Real device testing under throttled and interrupted connections
Platform
A large site, or one built around your operation
Fixed written quote, agreed before work starts
- Everything in Progressive Web Growth
- Sync failure monitoring and offline usage analytics
- Deployment pipeline with staged rollout
- Staff rollout guide and training material
Progressive Web Care
Keeping it fast, patched and improving
Rolling monthly, quoted in writing
- Hosting, patching, backups and uptime monitoring
- Content and design changes as you need them
- Core Web Vitals watched, not assumed
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
How long does it take to build a progressive web app?
Usually 7 to 12 weeks. The interface work is comparable to any web application, and the additional time goes into offline data handling, sync logic and testing under poor network conditions. That testing is not optional padding, since offline behaviour is where these projects fail. Scope grows most when many journeys must work offline rather than a well chosen few.
What does a progressive web app cost compared with a native app?
Generally less, because one codebase serves every platform and there is no store submission overhead on each release. The variable is offline complexity: caching a read only reference list is straightforward, while bidirectional sync with conflict resolution is real engineering. We scope the offline requirements precisely and then give you a fixed written quote for the agreed set.
Can a progressive web app send push notifications on iPhones?
Yes, once the app has been installed to the home screen. That installation step is required on iOS, which makes onboarding important: staff or customers need clear instructions and a reason to install. For internal rollouts we provide a short guide and often walk teams through it, since an app that never gets installed cannot notify anyone.
Do we still need an app store presence?
Only if your users expect to find you there or you need capabilities the web cannot reach. Internal tools almost never need it. Consumer products sometimes do, and a progressive web app can be wrapped for store submission if that becomes necessary later, which is a reasonable staged approach: prove the product on the web, then add store distribution once demand justifies the extra process.
Who owns the application and the data it collects?
You own the codebase, the deployment pipeline and all data collected, with the hosting and service accounts registered to your business. Where the app stores personal information on staff or customer devices, we also document what is held locally and for how long, which matters for your obligations under the Privacy Act 1988 and for any device that gets lost.
How do you handle updates once staff are using it daily?
Updates deploy to the server and the service worker picks them up on the next visit, so everyone is on the current version within a day without touching an app store. For changes that alter workflow we use a staged rollout and an in app notice, because a field crew discovering a redesigned form at 6am on a job site is a support call you would rather avoid.
Related services
Have a team working where coverage drops out?
Describe the job they do and where the network fails them. We will tell you within one business day whether a progressive web app fits, and quote it in writing if it does.