Five questions to answer before you build an app
Most app projects that stall were in trouble before the first line of code. These five questions catch it early.
A good app project starts long before design or code. The teams that ship on time have usually answered a short list of questions first, in plain words, and written the answers down. Here are the five we ask on every project.
Who is it for, exactly?
“Everyone” is not an audience. The apps that do well start with one kind of person in one situation, and serve them unusually well. Write that person down, then write down what they do today instead of using your app.
If you can’t describe the current workaround, you don’t yet know the problem well enough to design for it. The workaround is also your real competition: a spreadsheet, a group chat or a paper form is free, familiar and already installed.
What is the one job it does?
Every successful app has a job it does better than anything else on the phone. Name it in one sentence. Features that don’t serve that job can wait for version two.
A useful test: describe the first minute after someone installs the app. If that minute doesn’t get them to the one job, the first version is trying to do too much.
Does it need to be an app at all?
A fast website can do a surprising amount. It costs less to build, works on every device and needs no store approval. An app earns its place with things the web does poorly:
- notifications people actually want
- working offline
- the camera, location or other device features used often
- payments in a tap, through the stores
- being one tap away on the home screen
If none of those matter, start with the web. You can add an app later, once you know people come back.
What happens after launch?
Apple and Google ship new operating systems every year, and the stores change their rules more often than that. An app that nobody looks after quietly ages out: a login breaks, a new phone size looks wrong, a required update is missed.
Budget for upkeep from the start. A small monthly allowance for updates and monitoring is far cheaper than an emergency rebuild two years in.
How will you know it worked?
Pick two or three numbers before you build: people who come back each week, a task completed, a subscription started. Decide what “good” looks like at three and six months.
It turns every later decision into a simpler one. When someone asks for a new feature, the question becomes: will it move one of those numbers?
The short version
Write down who it’s for, the one job, why it must be an app, who looks after it, and how you’ll measure it. If you can answer all five on one page, you’re ready to start. If you can’t, that page is the first piece of work, and we’re happy to help with it.