Questions worth answering before you commission a mobile app

Apps carry a certain status. Having one feels like a milestone, and there is usually somebody on the team keen to build one. That enthusiasm is not a bad thing. It is just a poor basis for spending six figures.

What follows is a set of questions that will either firm up the decision or save you the money. Both outcomes are useful.

Does the job actually need to be an app

Start here, because a lot of ideas do not survive it.

There are four things a native app can do that a website genuinely cannot do as well. It can work with no connection at all. It can use the hardware properly, meaning the camera, GPS, bluetooth or biometrics. It can send a notification that appears on a locked screen. And it can stay logged in and open instantly, which matters when somebody uses it fifteen times a day.

If your idea needs one or more of those, an app is a reasonable answer. A delivery driver logging drop offs in an area with patchy signal needs offline. A field engineer photographing an installation needs the camera and probably GPS. A warehouse team scanning stock all shift needs speed and hardware access.

If your idea does not need any of them, look hard at a mobile website first. It costs a fraction as much, requires no download, no store approval, and no separate build for two platforms. A customer checking an order status once a month will not install anything, and asking them to is how you end up with a beautiful app that has ninety downloads.

Who is it for, and will they install it

Apps for your own staff and apps for your customers are almost different products, and the harder one is the customer app.

Staff will install what you ask them to install. Adoption is largely a management question. Customers will not. Every single one has to decide your app is worth the space, the download, the account, and the permissions, and most of them will decide it is not unless they use you often.

A blunt test. How many times a month does a typical customer interact with you? Below about four, a customer app is very hard to justify. People keep apps for things they use constantly. Everything else gets deleted the next time the phone runs out of storage.

The cost you are actually signing up for

The build quote is the smaller number. Plan on a two year view.

Beyond development, budget for the following.

• Developer accounts with both stores, renewed annually.
• Operating system updates. Both platforms release major versions every year and things break. Expect maintenance work twice a year whether or not you have changed anything.
• Backend running costs, if the app talks to a server, which it almost certainly does.
• Fixes for problems that only appear on real devices in real conditions, which will arrive in the first month.
• A second round of design work about a year in, because mobile conventions move quickly and an app that looked current in 2025 will not in 2027.

A reasonable planning assumption is that ongoing costs run somewhere between fifteen and twenty five per cent of the original build each year. If nobody has raised that with you, raise it yourself before signing.

Native, cross platform, or neither

You will be offered three routes and the differences are real, though usually explained in the wrong terms.

Native means separate builds for iOS and Android, written in each platform’s own language. Best performance, fullest access to hardware, and the most expensive to build and maintain because it is two codebases.

Cross platform means one codebase producing both apps. Typically faster to launch and cheaper to maintain, with some limits when you need deep hardware access or the last few per cent of smoothness. For most business applications the difference is not noticeable to users.

A progressive web app is a website that behaves somewhat like an app, can work offline to a degree, and can be added to a home screen without a store. Cheapest by a distance. Notification support is weaker, and it does not appear in store searches, which matters only if store discovery is part of your plan. It rarely is for a business tool.

The right question to put to anybody quoting is not which technology they prefer. It is what the two year cost looks like under each option for your specific feature list.

Test the flow before anybody writes code

The most expensive mistakes in app projects are not bugs. They are flows that make sense to the people who designed them and confuse everybody else.

Clickable prototypes solve most of this. Put a prototype in front of five or six people who resemble your actual users, give them a task, and watch without helping. You will learn more in an hour than in a month of internal discussion, and changing a prototype costs a fraction of changing a built screen.

Watch particularly for where people hesitate. Hesitation is the signal. If somebody pauses before tapping something, the label is wrong or the flow is not where they expected it.

The store review process will surprise you

Both app stores review submissions before release, and first time publishers routinely get caught out by the timing.

Reviews usually take somewhere between a day and a week, and a rejection resets the clock. Common reasons are mundane. A privacy policy that does not exist or does not cover what the app collects. Login credentials not supplied so the reviewer cannot get past your sign in screen. Permissions requested without a clear explanation of why. An app that a reviewer decides is really a website in a wrapper.

None of that is hard to satisfy. It is just work that has to happen before submission rather than after, and it needs to be in the plan. If your launch is tied to an event or a campaign, build in at least two weeks of slack for the review, because you have no way to hurry it along once it is submitted.

Decide what success looks like now

Write down, before the project starts, what would make this worth having done. Downloads is the wrong measure and the one everybody reaches for.

Better measures depend on what the app is for. Fewer phone calls to the office. Orders completed in the field before the driver returns. Time from job finished to invoice raised. Repeat usage after week four, which tells you whether anybody kept it.

Agreeing that in advance also protects the project internally. Six months after launch, somebody will ask whether the app was worth it. Having a number you both agreed to beforehand makes that a short conversation instead of a difficult one.