What to prepare before hiring a mobile app developer

Before hiring a mobile app developer, prepare five things: a one-page description of your idea, the main user journeys and must-have features, a list of accounts and assets you should own, a set of questions to ask each developer, and a fair way to compare their proposals. Developers can only quote accurately what they understand, and good preparation turns vague estimates into proposals you can compare with confidence.

A mobile app is software people install on a phone, usually from Apple's App Store or Google Play. This guide is for founders and business owners preparing to hire a developer or agency. If you would like to see how we work, our mobile app service page explains our approach.

Your idea in one page

A single page forces clarity. It should answer:

1. Who is the app for? Be specific, such as "members of a fitness studio" rather than "people who exercise".
2. What problem does it solve? Describe what they do today and why it is frustrating.
3. What is the main thing they will do in the app? One sentence.
4. How will the app make money or save money? Subscriptions, bookings, sales, or reduced staff time.
5. What already exists? A website, a booking system or customer data the app must use.
6. What does success look like a few months after launch?

A worked example

"A class booking app for members of our fitness studio. Members currently book by phone or message, and the front desk spends a lot of time managing bookings and waiting lists. In the app, members see the week's classes, book a place and get a reminder. The app should reduce phone bookings and no-shows. We already have a membership list in our existing system."

User journeys and must-have features

A user journey is the sequence of steps a person takes to complete a task. Describing journeys is more useful to a developer than listing features.

1. Write the main journey as numbered steps, from opening the app to finishing the task.
2. Add the other journeys that must exist at launch, such as signing up, cancelling a booking or updating a profile.
3. List the admin tasks your team needs, such as adding classes or seeing bookings.
4. Mark each feature as must-have, nice-to-have or later.
5. Note any rules, such as cancellation deadlines or limits per member.

Decision criteria for must-have features

A feature is a must-have only if the main journey cannot be completed without it, or if it is required by law or your payment provider. Everything else can usually wait. Our guide on how to plan the first version of a mobile app explains how to keep the first version focused.

If your features do not need the app stores or device features, our comparison of progressive web apps and native apps explains a lighter option.

Accounts and assets you should own

Ownership is easiest to arrange before work starts.

A checklist

• The Apple and Google developer accounts used to publish the app, registered to your business. Apple's Developer Program is an annual paid membership, and Google Play requires a developer account with a one-time registration fee.
• The source code, in a repository your business controls.
• The server and hosting accounts for the backend, the part of the system that runs on a server.
• Third-party services, such as push notifications, email, maps and payment gateways.
• The app's name, logo, design files and domain name.
• Any data collected by the app, with the ability to export it.

A common mistake and its fix

A common mistake is letting the developer publish the app under their own developer account. If the relationship ends, moving the app to your account can be slow and complicated. The fix is to create your own developer accounts at the start and give the developer access to them.

Questions to ask when hiring a mobile app developer

Use the same questions for every developer, so answers can be compared:

1. Which apps similar to ours have you built, and can we see them in the stores?
2. Will you build for iPhone, Android or both, and with which approach, and why?
3. Who builds the backend and admin panel, and are they included in the quote?
4. How will we see progress, and how often will we test builds on our own phones?
5. How do you handle app store submission and review?
6. What testing do you do on real devices?
7. What happens after launch: fixes, updates for new phone operating systems and support?
8. Who owns the code, accounts and data, and how is handover handled?

Comparing proposals fairly

Proposals often differ because they describe different projects. Put them on equal terms.

1. Check they cover the same scope, including the backend, admin panel and store submission, not just the app screens.
2. Compare the breakdown, such as design, app development, backend, testing and project management.
3. Read the assumptions and exclusions, which often explain big price differences.
4. Compare timelines and milestones, including when you will first test the app.
5. Compare support after launch, as it affects the total cost over time.
6. Consider a small paid first phase, such as designs and a clickable prototype, to test the working relationship.

A comparison table to fill in

Our guide to what it costs to build a mobile app explains the cost drivers behind each line of a proposal.

If proposals recommend different technologies, our comparison of native and cross-platform apps explains the trade-offs.

Summary

• Write your idea on one page: users, problem, main task, business model and success.
• Describe user journeys as steps and mark features as must-have, nice-to-have or later.
• Own the developer accounts, code, hosting, services, design files and data from the start.
• Ask every developer the same questions about experience, approach, backend, testing and ownership.
• Compare proposals on scope, breakdown, assumptions, timelines and support, not just price.

Good preparation is the best way to find the right developer and get an estimate you can rely on. If you're preparing to build a mobile app, you can tell us about your idea here.