We've been building apps since before most people had a smartphone, and the projects that go badly almost never go badly because of the code. They go badly because something basic wasn't decided at the start.
None of this needs technical knowledge. If you can answer these seven things before you talk to any developer, us included, you'll get better quotes and a better app.
1. Who is it for, exactly?
"Everyone" isn't an answer. Is it your existing customers? Your staff in the field? Parents at a school? The answer changes everything from the design to whether it needs to work offline. When we built the app for The Guardian School System, the users were parents checking on their kids, and that shaped every screen.
2. What's the one job it has to do well?
Write down the single thing someone opens the app to do. Book a ride. Check a child's attendance. Reorder a product. Everything else is a nice-to-have for version two. First versions that try to do ten things usually do none of them well, and cost twice as much.
3. Does it need to be an app at all?
A real question, not a trick. If people will use it once a month, a well-made mobile website might do the job for a fraction of the price, with no app store approval to wait for. Apps earn their place when people come back often, or need the phone's camera, location, notifications or offline access.
4. iPhone, Android, or both?
Check where your users actually are. In Pakistan and much of the Gulf, Android is the majority. In the US and UK, iPhone is much stronger. Building for both at once is usually sensible now, and costs far less than building two separate apps, but it's worth knowing where to test first.
5. Who owns what?
Before anyone starts, agree in writing that:
- the source code is yours once it's paid for
- the App Store and Google Play accounts are in your company's name (Apple charges 99 US dollars a year, Google a one-time 25 dollars)
- the servers, domain and database are in accounts you control
We've taken over projects where the previous developer owned all of it and disappeared. It's a horrible position to be in, and completely avoidable.
6. What happens after launch?
An app isn't finished when it goes live. Apple and Google release new versions of their systems every year, and apps need updating to keep working. Servers cost money every month. Users will find bugs. Budget for ongoing support from the start, rather than finding out about it the first time something breaks.
7. What does "done" look like?
Agree how you'll judge the first version before it's built: a number of downloads, bookings, orders, fewer phone calls to your office. It keeps everyone honest about what matters, and it tells you when it's time to build the next part.
Ready?
If you've got rough answers to most of these, you're ahead of most people we speak to. Tell us about your idea on the contact page. We'll go through the gaps with you, and if an app isn't the right answer, we'll say so.