Most people who want an app built don’t write code, and they shouldn’t have to. But the first call with a developer goes much better when you’ve done a little homework. Not a spec, and not a tech stack. Just a clear picture of the problem, and a few questions of your own.
I’ve been building Android and iOS apps for 13 years, and I’ve owned four greenfield Android builds end to end. This is what I ask on a first call, what helps if you bring it, and what I’d ask if I were the one hiring.
Bring two things
A one-paragraph problem. Who the app is for, and what it fixes for them, in plain words. “Households that employ domestic staff lose track of attendance, advances and half-days, so the monthly salary settlement is hard to get right” is a good paragraph. “An app like Uber, but for X” is a starting point, not a problem.
If you can’t write the paragraph yet, that’s useful to know too. It means the first conversation should be about the problem, not about the app.
A short, ranked list of must-have features. Write down what the app has to do, put the most important thing first, and keep the nice-to-haves on a separate list. The ranking matters more than the length. When time or budget runs short, and it usually does, the ranking decides what ships first.
What you don’t need: a full spec document
You don’t need a 40-page requirements document before you talk to anyone. Turning your problem and your feature list into a plan is part of the work. When I take on an MVP, we agree what the first version must do and what can wait in a paid discovery sprint, and it ends in a written plan and an estimate you can use with me or with anyone else.
A good developer will help you write that plan. Be wary of one who skips it and quotes a price straight from your feature list.
What I’ll ask you
These are the questions I ask on every first call. Expect a good developer to ask something similar.
- Who are the users? Not “everyone”. Who opens the app first, on what kind of phone, and in what situation? A field worker on patchy signal needs a different app from an office team on Wi-Fi.
- What’s your budget range? A rough range is enough. It isn’t there to set the price. It’s there so the plan fits what you can spend, instead of a plan you then have to cut in half.
- What already exists? Designs, a website, a backend, an earlier version of the app, store accounts, anything. Each of these changes the plan, sometimes a lot, and it’s far better to know on day one.
What to ask the developer
Turn the questions around. These are the ones I’d want answered if I were hiring.
- Who owns the code? The answer should be you. In my case, you get read access to the repository from the start so you can see every commit, and the code is transferred to your repository at each paid milestone.
- When will I see the app on a real phone? You should get working builds on a test track every week or two as the app grows, not slides and a big reveal at the end.
- Who handles the store release? Getting an app into Google Play or the App Store involves signing, store listings, privacy declarations like Play’s Data Safety form, and ideally a staged rollout. Ask whether that’s included, or whether it’s a surprise at the end.
- Could someone else take over later? You want an app your own team, or another developer, can pick up later, not one only its builder understands. Ask how the decisions get written down.
The short version
- Write the one-paragraph problem.
- Rank your must-have features, and keep the nice-to-haves separate.
- Know your budget range, and list what already exists.
- Skip the spec. Plan it with the developer, and ask who owns the code.
If you’d like to go through this with me, the MVP page explains how a build starts with a discovery sprint and what you get at the end of it.