25 Questions to Ask Before Hiring an App Developer (and Good Answers)

The best questions to ask an app developer are the ones that force specific answers: which live apps they built, who will write your code, how they handle change, what the price includes, who owns what, and what happens after launch. Below are 25 questions in six groups, with why each one matters and what a good answer sounds like.

They work whether you are talking to a freelancer, an agency or a small studio. If you have not decided which of those you need, start with our comparison of freelancer vs agency vs in-house teams. Print the list, take notes during each call, and compare answers side by side.

Portfolio and proof

These questions separate teams that have actually shipped from teams that have only built demos. A developer's past work is the best predictor of your outcome.

1. Can I download an app you built from the App Store or Google Play?

Why it matters: screenshots and Dribbble shots prove design skill, not delivery. A live app proves the team got through store review and kept it working. A good answer: "Here are three links. This one we built end to end; on this one we did the mobile client only." Clear attribution of what they did is as important as the link itself.

2. Which of your past projects is most similar to mine, and what was hard about it?

Why it matters: relevant experience shortens the learning curve, and talking about difficulties shows honesty. A good answer names a specific challenge, such as offline sync, payments or a store rejection, and explains how they solved it.

3. Can I speak with a past client?

Why it matters: a reference call reveals how the team behaves under pressure. A good answer offers a contact, or if the team is new or bound by NDAs, offers an alternative such as a paid discovery sprint so you can judge them on real work.

4. Who exactly will work on my project, and can I meet them?

Why it matters: the biggest gap in the industry is between who sells the project and who builds it. A good answer names the lead engineer and designer, states their experience and confirms you will talk to them directly during the build.

5. Have you shipped apps in my domain or with my constraints?

Why it matters: health, finance, children's apps and anything handling personal data come with extra store rules and privacy law. A good answer mentions the specific obligations, for example GDPR, Apple's privacy details or Google Play's health apps declarations, without being prompted.

Process and communication

Most failed projects fail on process, not code. These questions show how visible the work will be and how problems get surfaced.

6. How often will I see working software?

Why it matters: the longer you go without seeing progress, the larger the eventual surprise. A good answer: "Every week or every two weeks, on a real device, via TestFlight and a Play Console internal testing track." Be wary of "you'll see it at the end".

7. What happens in the first two weeks?

Why it matters: the opening weeks show whether they scope before they code. A good answer describes discovery: clarifying user flows, agreeing on must-have features, wireframes or clickable prototypes, and a technical plan before full development starts.

8. How do you handle a change in requirements mid-project?

Why it matters: requirements always change. A good answer explains a lightweight change process: estimate the change, show what it displaces or costs, and get your approval in writing before starting.

9. How will we communicate, and how fast do you respond?

Why it matters: time zones and response times matter more than the tool. A good answer names the channel (Slack, email, a shared board), a response window during working hours and a regular call cadence that overlaps with your day.

10. What do you need from me to keep the project on schedule?

Why it matters: delays often come from the client side: late content, slow feedback, missing accounts. A good answer lists specifics, such as feedback within two working days, a single decision-maker and store account access by a given week.

Technology and quality

You do not need to be technical to ask these. Listen for reasoning and trade-offs rather than buzzwords.

11. Which technology would you use for my app, and why?

Why it matters: the stack affects cost, performance and who can maintain the app later. A good answer ties the choice to your needs, for example "React Native because you need iOS and Android from one codebase and your team knows JavaScript", and mentions when native Swift or Kotlin would be better. Our React Native vs Flutter comparison covers the main trade-offs.

12. How do you test the app before release?

Why it matters: untested apps get one-star reviews and store rejections. A good answer covers automated tests for core logic, manual testing on a range of real iOS and Android devices, and a beta round with real users before submission.

13. How do you handle performance and app size?

Why it matters: slow startup and large downloads cost users, especially on mid-range Android phones. A good answer mentions measurable targets, such as cold-start time, bundle size or frame rate, and how they check them.

14. What third-party services and SDKs will you add?

Why it matters: every SDK adds cost, lock-in and lines to your App Store privacy label and Google Play Data safety form. A good answer lists each service, why it is needed and what data it collects, and suggests leaner alternatives where possible.

Cost and contract

Ask these in writing. The goal is to compare quotes like for like and avoid surprises at the invoice stage.

15. What exactly is included in your quote, and what is not?

Why it matters: two quotes can differ by 3x simply because one excludes design, backend, testing or store submission. A good answer is an itemized scope with explicit exclusions. Our guide to what determines app development cost shows what a complete scope should cover.

16. Is this a fixed price or time and materials?

Why it matters: each model shifts risk differently. A good answer explains why they chose the model and what triggers a price change. Fixed price suits a well-defined scope; time and materials suits evolving products, ideally with a monthly cap.

17. How are payments tied to milestones?

Why it matters: paying for working software rather than elapsed time protects you. A good answer links each payment to a demoable deliverable, with a modest deposit up front rather than most of the budget.

18. What is the realistic timeline, and what could delay it?

Why it matters: optimistic timelines are a sales tactic. A good answer gives a range, names the biggest risks (integrations, content, store review) and builds in time for testing and submission. See how long it takes to build an app for typical ranges.

Ownership and security

These are the questions people most often forget and most often regret. Get the answers into the contract.

19. Who owns the source code and intellectual property?

Why it matters: without an explicit assignment, you may not legally own what you paid for. A good answer: "You own everything we produce for you, assigned on payment, and the code lives in your repository from the first commit."

20. Whose name will the App Store, Google Play and cloud accounts be under?

Why it matters: an app published under a vendor's developer account is hard to move and can be held hostage. A good answer: "Yours. You create the accounts and invite us as team members."

21. How do you protect user data and secrets?

Why it matters: a data leak can end a young company. A good answer covers encryption in transit and at rest, keeping API keys out of the app bundle, least-privilege database access and collecting only the data the app needs.

22. How will you help us meet privacy and store data requirements?

Why it matters: both stores require accurate privacy disclosures, a privacy policy and in-app account deletion for apps with accounts. A good answer shows they fill in these forms routinely. Our App Store and Google Play submission checklist lists what is required.

Launch and post-launch

Launch is the start of the app's life, not the end of the project. Plan for it before you sign.

23. Will you handle App Store and Google Play submission?

Why it matters: first submissions are often rejected for fixable reasons, and a new Google Play personal account must run a closed test before it can publish. A good answer includes submission in scope and explains how they handle rejections.

24. What happens if we find a bug after launch?

Why it matters: this is where many disputes start. A good answer defines a warranty period (commonly 30–90 days) during which defects in agreed scope are fixed at no charge, and a clear rate or retainer after that.

25. How will you keep the app working as iOS and Android change?

Why it matters: Apple and Google raise SDK and target API requirements every year, and apps that fall behind can no longer be updated. A good answer describes an ongoing maintenance plan with an estimated yearly budget.

What red flags should make you walk away?

One weak answer is not disqualifying, but a pattern is. These are the warning signs we would take most seriously.

1. 01A firm quote before they have asked you a single question about users or features.
2. 02No live apps you can install, and no alternative way to verify their work.
3. 03Insistence on publishing under their own developer account or hosting code in their private repository.
4. 04A price far below every other quote, with no explanation of what is left out.
5. 05No demos until the end of the project.
6. 06Vague answers about testing, security or post-launch support.

How would Navelo Software answer these questions?

We wrote this list partly as a mirror. Navelo Software is a small senior studio, and our own apps, including ZorbiLock and BodyLog, are live on the App Store and Google Play for you to download. Clients get weekly demos, the code lives in their repository from day one, and store and cloud accounts stay in their name.

If you are building a mobile app or web application, send us your questions, all 25 if you like, and we will answer them in writing alongside a fixed quote. Start the conversation here.