15 Questions to Ask Before You Hire an App Developer

A first call with an app developer usually goes the same way. They show a portfolio, you describe your idea, everyone is enthusiastic, and a proposal arrives a few days later. Nobody has asked the questions that predict whether the project will actually ship.

These are the questions to ask an app developer before you hire them, whether that's a freelancer, an agency or a candidate for your team. You don't need technical knowledge to use them. For each one, I've written what a good answer sounds like and what should make you cautious. Print this list and take it into your next call.

Key takeaways

• Ask about specific past work and failures, not general skills. Real experience comes with stories.
• Ask how they'll work with you: updates, demos, decisions, and what happens when scope changes.
• Test judgement, not knowledge: what they'd cut, what they'd build first, which trade-offs they'd make.
• Settle ownership before money: code, accounts, credentials and handover.
• A good developer asks you as many questions as you ask them. If they don't, that's an answer too.

Experience

1. "Which apps have you built that I can download today?"
Good: several store links, and a clear description of their part in each. Cautious: only screenshots, or apps that no longer exist.

2. "What exactly did you build in this app, and what did others build?"
Good: "I built the React Native app and the API, and handled releases; a designer did the UI." Cautious: "we" for everything, with no specifics.

3. "Tell me about a project that went wrong. What happened and what did you change?"
Good: a specific story with a lesson. Cautious: "Nothing has ever gone wrong."

4. "Have you built something like this before?"
Good: a related project, or an honest "not exactly, but here's what's similar and here's the part that's new to me." Cautious: claiming experience with everything.

Process

5. "How will I see progress, and how often?"
Good: a regular build on your phone (TestFlight or internal testing), short written updates, a shared task list. Cautious: "I'll show you when it's ready."

6. "What do you need from me, and when?"
Good: a concrete list: accounts, content, feedback windows, decisions. Cautious: nothing at all, which means you'll find out later.

7. "What happens when I want to add something mid-project?"
Good: "I estimate it, you decide, and we place it in a milestone." Cautious: "No problem, I'll just add it," which is how deadlines die.

8. "How do you test the app before it reaches users?"
Good: real devices on both platforms, automated tests on the risky paths, staged rollouts. Cautious: "I test on the simulator."

Technical judgement

9. "What would you cut from my feature list for the first version?"
Good: they cut things and explain why. Cautious: they agree everything is essential.

10. "Which technology would you use, and why that one for my app?"
Good: a choice tied to your product, with trade-offs ("React Native with Expo, because you need iOS and Android and a web dashboard"). Cautious: a favourite tool for every problem.

11. "How will the app handle no connection, slow networks and errors?"
Good: a clear plan for loading, empty and error states, and for retrying safely. Cautious: the question surprises them.

12. "How do you get a fix to users quickly after launch?"
Good: crash reporting to find it, over-the-air updates for JavaScript fixes within store rules, a fast store release for native changes. Cautious: "Users will tell us."

Ownership and business

13. "Whose accounts will the code, the apps and the servers live in?"
Good: "Yours, from day one. I'll ask for access." Cautious: anything else.

14. "What do I get at the end, or if we stop early?"
Good: code in your repository, documentation, credentials, a walkthrough. Cautious: vague answers or delivery only "on completion".

15. "What does support look like after launch?"
Good: a defined bug-fix period, then a retainer or hourly support with response times. Cautious: either "it won't need support" or open-ended free support.

A scoring sheet you can use

A total of 24 or more out of 30 is a strong candidate. Anything under 15 needs a very good reason.

From the field: I own the release path on the apps I build: EAS builds, over-the-air updates, store review and crash triage. That's why I'd weight questions 8 and 12 heavily. Developers who haven't lived through releases and production bugs tend to answer them with theory.

Questions they should ask you

Pay attention to what the developer asks. Good ones will want to know:

• Who your users are and what job the app does for them.
• What success looks like in the first three months.
• Your budget range and any fixed dates.
• What already exists: designs, a website, an API, data.
• Who makes decisions on your side, and how fast.

A developer who asks none of these is planning to build what you described, not what you need.

Technical questions if you're hiring a React Native developer

If the app will be built with React Native, add a few specific questions. You don't need to judge the code, only whether the answers are concrete:

• "How do you handle releases?" Listen for builds in CI, store submission, over-the-air updates for fixes and staged rollouts.
• "How do you find out about crashes in production?" A good answer names a crash reporting tool and a routine for triaging issues.
• "When would you write native code?" Expect specific examples, such as Bluetooth, background work or a missing SDK.
• "How do you keep the app fast on cheaper Android phones?" Expect talk of measuring in release builds, list performance and images.
• "What happens to old app versions when the API changes?" Expect backwards compatibility and a minimum-version check.

FAQ

What should I ask an app developer before hiring?

Ask about apps you can download and their exact role in them, a project that went wrong, how they report progress, what they'd cut from your feature list, how they test, how they ship fixes after launch, and who owns the code and accounts. The answers reveal experience better than any portfolio.

How do I know if an app developer is good?

Look for live apps with recent updates, specific answers about their role, honest stories about problems, sensible trade-offs, and clear ownership terms. A short paid trial on a real task is the most reliable test of all.

What are red flags when hiring an app developer?

Publishing your app under their account, withholding code until the end, estimates far below everyone else's with no explanation, no apps you can download, and agreeing to every feature without question. Slow or vague communication before the contract usually gets worse after it.

Should I ask for references from an app developer?

Yes, especially for larger projects. Ask to speak with one or two past clients about communication, deadlines and what happened after launch. If references aren't possible because of confidentiality, live apps and a paid trial are the next best evidence.

Next steps

If you'd like to put these questions to me, I'm happy to answer every one of them on a call. Get in touch, or read how I work as a React Native developer.

Sources

• TestFlight, Apple
• Set up an open, closed or internal test, Google Play Console Help
• EAS Update introduction, Expo