Mobile App Development in New Zealand

First, do you need an app?

A good developer will ask this before quoting, and the honest answer is often no. An app makes sense when you need at least one of four things:

• It works without signal. Field staff in rural New Zealand, warehouses, tunnels, the Coromandel. A web page needs a connection; an app can hold the work and sync later.
• It uses the device seriously. Camera as a scanner, GPS tracking in the background, Bluetooth to equipment, sensors.
• Push notifications matter. Not marketing — notifications people actually act on, like a job dispatched or a delivery arriving.
• It is used constantly. An icon on the home screen is worth something when people open it weekly. It is worth nothing when they open it twice a year.

If none of those apply, a mobile website reaches everyone immediately, costs a fraction, updates without review, and nobody has to be persuaded to install it. Plenty of app briefs are really website briefs with an installation step bolted on.

Native, cross-platform, or neither

Cross-platform — React Native or Flutter — is the sensible default for most business apps. One codebase produces both iOS and Android, and it typically costs 30% to 40% less than building the same thing twice. The apps feel native to almost everyone who uses them.

Native separate builds earn their cost when you need platform features the day they launch, heavy graphics or video processing, sustained background work, or performance tight enough that the extra layer matters. Those are real requirements, and a developer proposing native should be able to name yours.

A progressive web app sits underneath both: a website that installs to the home screen and works offline for simple cases. Cheapest by a distance, no store review, and limited on iOS in ways worth checking against your list above.

The backend is usually half the project

An app on a phone is a window. Unless it is a calculator, something behind it holds the data, authenticates users and enforces the rules.

If you already have a system with a decent API, the app is genuinely a front-end project. If you do not, the quote includes building a server, a database, authentication and an admin interface — and that half is invisible in every screen mockup you will be shown. Ask each developer to price the backend separately, so you can see it.

Two apps means two of everything, forever

iOS and Android both ship a major version every year, and both regularly break things that worked. Store policies also change: data disclosures, account deletion requirements, permission rules.

Budget 15% to 25% of build cost per year purely to keep an app working and listed, before any new features. Apps that go unmaintained do not fade gracefully; they stop passing review, then stop being offered to new users, and one day someone's phone updates and it will not open.

Store submission catches first-timers out

Review itself takes one to three days. First submissions get rejected routinely, and rarely for anything to do with code:

• No privacy policy, or one that does not match what the app collects.
• A login wall with no demo account for the reviewer.
• No way to delete your account from inside the app — now required by both stores.
• Payments for digital goods routed around the store's own billing.
• An app the reviewer decides is a website in a wrapper.

Budget two weeks for the first release, and settle who handles submission. If it is you, the developer accounts must be in your name from the start — moving an app between accounts later is possible and unpleasant.

Distribution is the part nobody quotes

If the app is for your staff, distribution is a memo. If it is for customers, getting people to install it is harder than building it, and no developer can solve that for you.

Before commissioning a consumer app, write down how the first thousand people will hear about it. If the answer is "the app store", reconsider: nobody browses app stores for a business they have never heard of. This is the single most common reason New Zealand consumer apps fail, and it has nothing to do with the software.

What to compare across quotes

• App versus website. Which specific capability requires an app.
• Backend, priced separately from the app itself.
• Native or cross-platform, with the reason named.
• Offline behaviour. What works with no signal, and what that adds.
• Store accounts. In your name, both platforms.
• Yearly cost to keep it working through OS releases.

Describe the moment of use

Do not start with screens. Describe where your user is standing, what they are holding, what they are trying to finish and what is in the way. A developer who has built for field staff will hear "no signal in the Waikato" and design differently — and that is the difference between an app people use and one they install once.