Mobile Backend / API in New Zealand

Ask every app quote one question

Is the backend in this price?

It is the largest single reason two quotes for the same app differ by forty percent, and it is rarely stated plainly. A quote covering only what runs on the phone is a quote for perhaps half the work.

Get the answer itemised:

• The API the app talks to.
• The database behind it.
• Hosting, and who pays for it.
• Accounts, login, password reset and account deletion.
• Push notification infrastructure.
• Admin screens for your own staff.
• File and image storage, if the app uploads anything.

If a developer says your existing systems will provide it, ask who is building the layer between those systems and a phone on a mobile connection. Something has to, and an ERP is not it.

The app cannot be trusted, and that shapes everything

A phone is a device you do not control, in the hands of someone you have not met, and anything shipped inside the app can be extracted from it. Keys embedded in an app are effectively public.

That means every rule that matters lives on the server:

• The server decides what this user may see, not the app.
• The server validates every value, however carefully the app validated it.
• The server calculates prices, discounts and totals.
• The app never holds a credential that reaches your database.

Be wary of any proposal where the app connects directly to a database. It is the most serious and most common security mistake in mobile work.

Design for a bad connection, not no connection

The interesting case is not offline. It is one bar of signal in a carpark: the request goes out, takes eleven seconds, and may or may not have arrived.

Ask what the app does then:

• Is there a timeout, and does it retry?
• If the user taps twice because nothing happened, do two jobs get created?
• Does the screen say what is happening, or spin forever?
• Are large payloads paged, so a slow connection returns something?

Idempotency is the technical answer to the double-tap problem: a repeated request produces the same single result. Ask whether it is in the design — it is cheap to include and produces duplicates in your database if it is not.

True offline is a different budget

If the app genuinely has to work with no signal, that is a decision to make deliberately, because it changes the price materially.

What has to be settled:

• What can the user do offline — read, or also create and edit?
• How much data is held on the device, and is it encrypted?
• When two people edited the same record while disconnected, which wins? That is a business rule, not a technical one.
• What does the user see about what has not yet synced?
• What happens to a queued action that fails when it finally reaches the server?

Worth paying for when your people genuinely work out of coverage. Worth declining when they do not, because it is the most expensive thing on this page.

Push notifications need a plan, not a checkbox

Sending one is easy. What causes trouble is everything around it:

• Who receives which notification, and can they turn categories off?
• What happens when someone has the app installed on three devices?
• What is the plan when a token becomes invalid, as they do?
• Does tapping the notification open the right screen, with the right record loaded?
• Is there a record of what was sent, for when a customer says they were never told?

Notifications that arrive at the wrong time or too often are the fastest route to being uninstalled, so the sending rules deserve as much attention as the plumbing.

Version the API from day one

People do not update apps. Six months after you ship version two, a meaningful number are still on version one, and the backend has to keep working for them.

So the contract has to be versioned from the start:

• A version in the URL or a header, decided and written down.
• Adding fields is safe; renaming or removing them is not.
• A way to tell an old app it must update before continuing, for the cases where you cannot support it any longer.
• A record of which versions are in use, so you know what you can retire.

Cheap to design in, painful to add later.

Do not forget the screens your own staff need

Every app project eventually discovers that somebody at your end has to look up a customer, resend a notification, refund an order or unlock an account. If that is not in the quote, it gets done in the database by a developer at $200 an hour.

Ask what admin screens are included. A modest admin interface built during the project is far cheaper than the support arrangement that replaces it.

Comparing five quotes

Read for:

• Which quotes include the backend, itemised?
• Who described what happens on a poor connection?
• Who raised API versioning before you did?
• Who included admin screens for your staff?
• Who gave a monthly hosting figure?

Describe what the app does, who uses it, where they use it, what systems the data comes from, and whether it must work without signal. Developers who have shipped mobile work will ask about signal and about your existing systems before they ask about screens.