HomeServicesProgressive Web App
Progressive Web App in New Zealand
A progressive web app is a website that installs like an app. For a great many New Zealand businesses it does the job for a third of the price — and there is a short list of things it still cannot do.
$30k+
Typical project value
2 min
To post a project
What do you need built?
Start here and add detail as you go.
Free - No obligation - Your details stay private
What people usually mean by progressive web app
A PWA brief usually comes from a business that has been quoted for native apps and blanched at the number. Often that instinct is right: if the requirement is forms, lists, bookings and payments on a phone, a PWA delivers it at a fraction of the cost with no app stores involved. The honest work is checking your requirements against the short list of things it cannot do.
A phone-first web application
Forms, lists, bookings, payments and account screens, installable to the home screen and usable offline for reading.
A field tool for staff
Your own people, on their own devices, with no app store, no install approval and updates that reach everyone immediately.
An app-like layer on an existing site
Making a site you already have installable, faster and usable on a poor connection, without rebuilding it.
What it costs
Indicative ranges from projects posted here. Use them to sense-check a quote, not to budget precisely.
Add PWA capability to an existing site
Installability, caching, offline reading and performance work on something you already have.
$10k – $25k
A phone-first application
Built as a PWA from the start, with accounts, offline behaviour and a backend.
$30k – $80k
Offline-capable field tool
Creating and editing offline with sync and conflict handling, for staff working out of coverage.
$80k+
Questions worth asking a provider
·Which of our requirements would a PWA not cover, specifically?
·Do we need push notifications on iPhone, and what does that require?
·How do users discover they can install it, and what does that look like on each platform?
·What works offline — reading only, or creating and editing too?
·If we later need a native app, how much of this carries over?
Common questions
How much does a progressive web app cost in New Zealand?
Adding PWA capability to an existing site — installability, caching, offline reading and performance work — is $10,000 to $25,000. Building a phone-first application as a PWA with accounts and a backend is $30,000 to $80,000. Offline-capable field tools that create and edit without a connection start around $80,000. There are no app store fees at all.
What can a PWA not do?
The list is shorter than it used to be and still real. No presence in the app stores, so you lose that discovery and the credibility some customers attach to it. No continuous background location. Limited access to Bluetooth, contacts and some device hardware, particularly on iPhone. Push notifications on iOS work only once a user has added the site to their home screen. And anything requiring heavy graphics or sustained background processing belongs in a native app.
Do push notifications work on iPhone?
Yes, with a condition that matters: the user must add the site to their home screen first. That is an extra step you have to design for and prompt at the right moment, and a meaningful share of people will not do it. If notifications are central to your product and your audience is largely on iPhone — which in New Zealand is a lot of consumers — that is a genuine argument for a native app.
Will people actually install it?
Only if you ask them at the right time. On Android the browser offers installation reasonably prominently; on iPhone the user has to use the share menu, which nobody discovers by accident. Prompt after someone has used the site successfully rather than on arrival, and show the platform-specific steps. Design this deliberately — a PWA nobody installs is just a website, which may be perfectly fine.
Is a PWA worse than a real app?
For forms, lists, bookings, payments and account management — the substance of most business apps — users cannot tell, and you save the store fees, the review cycles and the update problem. It is genuinely worse when you need deep hardware access, background processing, or app store presence. Any developer worth hiring will tell you which category you are in before quoting either.
Progressive Web App projects open right now
Titles and categories are public. Full briefs, budgets, regions and buyer detail are visible to approved providers only.
Updated daily
No open projects in this category right now. New briefs are posted every week.
Check your requirements against the short list
A PWA covers most of what businesses actually ask apps to do, at a fraction of the cost. The exceptions are specific, and checking them takes ten minutes.
A PWA handles well: forms and data entry, lists and search, bookings and scheduling, payments, accounts and profiles, camera and photo upload, location when the app is open, offline reading, home screen presence, notifications with the caveat below.
A PWA cannot do: appear in the App Store or Google Play, track location continuously in the background, reach Bluetooth or contacts reliably on iPhone, run sustained background processing, or deliver the graphics performance a game needs.
Go through your requirements against that second list. If nothing on it appears, you have your answer and it costs a third of a native build.
The iPhone caveat, stated plainly
New Zealand consumer audiences skew towards iPhone, so this matters more here than the global picture suggests.
Push notifications on iOS work — after the user has added the site to their home screen. Not before. And adding to the home screen on iPhone means finding it in the share menu, which nobody discovers by accident.
So if notifications are central to your product and your audience is largely on iPhone, you have a real decision. Either design a deliberate, well-timed prompt that walks people through the two taps, and accept that a share of them will not do it — or build a native app.
Ask each developer how they handle this. A vague answer means they have not shipped a PWA to a consumer audience here.
What you gain by not being in a store
It is worth being explicit, because it is the substance of the case:
- No review. You ship when you are ready, not when Apple agrees. Fixes go out in minutes.
- No version fragmentation. Everyone is on the current version by definition — no supporting an app you shipped a year ago.
- No commission on anything you sell.
- No developer accounts, and no annual fees.
- One codebase for phone, tablet and desktop.
- Findable in Google, which an app is not.
For an internal tool used by your own staff, this is close to decisive. Distributing a native app to your own workforce means an enterprise programme or a device management platform; a PWA means sending a link.
Offline reading is cheap; offline editing is not
These are two very different projects and the brief should say which.
Offline reading — the app opens and shows the last data it had, so a dropped connection is not a blank screen. Straightforward, and it should be in every PWA.
Offline creating and editing — work done with no signal, held on the device, synced when it returns. That brings conflict resolution, queued actions that must not fire twice, encrypted local storage and an interface that explains what has not yet synced. It is the expensive part, and the cost is the same in a PWA as in a native app.
Decide which you need before quoting; it moves the price by a factor of two.
Design the install prompt deliberately
A PWA nobody installs is a website. That may be perfectly acceptable — but if installation matters, it has to be designed rather than assumed.
- Prompt after someone has used the site successfully, not on arrival.
- Say what they get — faster, works offline, on the home screen — rather than "install our app".
- Show iPhone users the actual steps, with the share icon, because the browser will not offer.
- Ask once. A prompt that reappears every visit is worse than none.
Performance is the whole experience
A PWA that is slow is a slow website with an icon. Since it runs in a browser rather than being installed as a package, everything about loading matters more.
Ask for real targets and a measurement before and after: how fast the first screen appears on a mid-range Android over a 4G connection, not on a developer's laptop on fibre. Caching strategy — what is stored, for how long, and how a user gets the new version — should be described in the quote rather than assumed.
It is not a wasted step if you later build native
A common worry is that a PWA is money spent twice if you eventually need an app. Mostly it is not: the backend, the API, the business logic and the design work all carry across, and the PWA gives you a year of real usage data telling you what the app should actually do.
Building the PWA first and the native app second, if it is still needed, is a sound sequence. Building the native app first because you might need it one day is how businesses spend $150,000 to find out.
Comparing five quotes
Read for:
- Who checked your requirements against what a PWA cannot do?
- Who raised the iPhone notification condition without being asked?
- Who distinguished offline reading from offline editing?
- Who designed the install prompt rather than assuming it?
- Who gave performance targets on a real device and connection?
Describe who uses it, what they must be able to do, whether they will be offline, and whether notifications matter. Developers who have shipped PWAs will tell you plainly which of your requirements rules one out.
Related services
Not quite what you are after? These are the briefs most often confused with progressive web app.
Get up to 5 quotes for your progressive web app project
You choose who may contact you. Free to use, no obligation.