The build is the short part of a mobile app. The long part is everything after: the store reviews, the operating system updates that break something once a year, the device somebody has that nobody tested on, and the version that has to go out on a Sunday because a payment provider changed something.
Rate a mobile partner on the long part. These are the questions to ask before any code exists.
Whose store accounts will it live in
Apps are published under a developer account. That account should belong to your company, with your billing details, and you should have access to it. If the app is published under the developer's account, moving to another developer means republishing as a new app and losing every review, every ranking and every installed user.
This is the mobile version of the domain question, and it is just as expensive to get wrong.
What happens when the platforms change
Apple and Google both make changes every year that require an app to be updated whether or not you wanted any new features. Ask directly:
- Who pays for the work when a platform requires a change?
- How quickly do you respond when an app is removed from a store?
- How many apps do you currently keep updated?
An app that has not been updated in two years is usually one that has stopped working for some of its users, and nobody has told the owner.
How it behaves without a connection
In the Maldives this matters more than almost anywhere. A ferry, a dive site, a store room, an island with a weak signal. Ask what the app does in each case. Does it show a spinner forever? Does it lose what somebody typed? Or does it hold the work and finish it when the signal returns?
Working properly offline is a design decision made at the start. It is not something that can be added at the end for a small fee.
One codebase or two
You can build separately for each platform, or use one codebase for both. Both are reasonable. What you want is a clear answer about why, in terms of your app rather than the developer's preference, and what the trade is. Ask what the choice means for release speed, for cost, and for finding another developer later.
Who owns the code and can somebody else read it
Ask for the repository to be in your company's account from day one. Ask whether another competent developer could pick it up, and how they would know how to run it. An app with no written setup instructions is an app that can only ever be maintained by the person who wrote it, which is a commercial position rather than a technical one.
What the five year cost looks like
Add it up honestly before you start:
- The build
- The store developer accounts, annually
- The servers behind the app
- Platform compliance updates, at least once a year for each store
- Support and small changes
If that total is uncomfortable, the honest conversation to have is whether you need an app at all. A great deal of what people ask an app for is better served by a fast website that works on any phone, needs no installation and no store approval, and can be changed the same afternoon.
The best mobile advice we have given some clients was to not build an app, and to put the money into the thing the app was going to be a shortcut to.
When an app genuinely is the answer
Build one when you need what only an app can do: reliable offline work, hardware such as a camera or a scanner used constantly, notifications people actually rely on, or a tool your own staff use every day where the installation is not a barrier.
We build mobile apps and we also build the servers behind them, which means one team answers when something is wrong and there is no argument about which side the fault is on. The services page has the detail. If you are unsure whether your idea needs an app, describe it to us and we will give you an honest answer, including the one where you save the money.