Questions to Ask an App Developer
Twenty questions for anyone hiring a freelancer or agency to build a mobile app, covering shipped work, cost structure, code and account ownership, testing, store submission, and what maintenance costs once the app is live.
The questions
Open any question for the note
Can you show me an app you built that is live right now, and can I download it?
Why ask it
Screenshots and case studies can be mock-ups. An app you can install and use on your own phone is the only portfolio item that proves the work shipped and still works.
Which parts of that app did you personally build?
Why ask it
Agencies and freelancers both present team work as their own. Ask which screens, which backend, which integrations, and whether the designer, developer and tester were the same person.
Would you recommend native, cross-platform or a web app for what I have described, and why?
Why ask it
You are testing whether they reason from your requirements or default to whatever they already know. A developer who cannot articulate a trade-off, offline use, camera access, app store presence, cost of two codebases, is choosing for their own convenience.
What would you build first if we had a quarter of the budget?
Why ask it
Forces a view on what is actually core. Someone who insists every feature must ship together either has not understood the product or intends to bill for all of it.
What is the total cost, and what is the cost of the parts that are not code?
Why ask it
Design, project management, testing, store submission, analytics setup and post-launch fixes are often the difference between a quote and a final invoice. Ask which of them are excluded.
Is this fixed price or time and materials, and what happens when the estimate is wrong?
Why ask it
Every non-trivial estimate is wrong. The useful answer describes a mechanism: a change order process, a rate for extra work, or a fixed scope with an agreed cut list.
What do you need from me, and when?
Why ask it
Projects stall on the client side more often than the developer side, waiting for content, logos, App Store accounts, legal text, decisions. A developer who names these upfront has finished projects before.
Who owns the code and the accounts when we are done?
Why ask it
Ownership should be yours in writing, including the repository, the developer accounts, the domain, the analytics and any third-party services registered on your behalf. This is the single most expensive thing to get wrong.
Will the app be published under my developer account or yours?
Why ask it
Publishing under an agency account means the listing, the reviews and the users are hostage to the relationship. Insist on your own Apple and Google accounts from the start.
What third-party services will this depend on, and what do they cost per month?
Why ask it
Push notifications, authentication, maps, storage, crash reporting and email all carry ongoing fees that scale with users. A quote that ignores running costs is incomplete.
Where will user data live, and what happens if it leaks?
Why ask it
You want to hear about specific choices: what is stored, what is encrypted, who has production access, and whether they have handled data deletion requests. Vague reassurance about 'industry standard security' is not an answer.
What will you do about App Store and Play Store review rejections?
Why ask it
First submissions are frequently rejected over privacy labels, account deletion, sign-in requirements or payment rules. Someone experienced will describe the common causes without hesitating.
How will I see progress before the end?
Why ask it
The answer should be a working build on your device every week or two, not a status document. Long stretches with nothing installable is the clearest predictor of a project going wrong.
How is the app tested, and on which devices?
Why ask it
Ask what is automated, what is manual, and which older phones and OS versions are covered. 'It works on my phone' is where most crash reports originate.
What happens in the first month after launch?
Why ask it
Crashes, store feedback and OS quirks surface immediately. Find out whether early fixes are included, chargeable, or require a new contract, before you launch rather than after.
What does ongoing maintenance cost once the app is built?
Why ask it
Apps decay: annual OS releases, expiring certificates, deprecated libraries, changing store rules. A developer who says maintenance is unnecessary has not supported an app for two years.
What happens if you become unavailable partway through?
Why ask it
Ask about documentation, repository access, and whether anyone else could pick the work up. For a sole freelancer, an honest answer plus code you already hold is the mitigation.
Can I speak to a client whose project did not go smoothly?
Why ask it
Anyone can supply a happy reference. Willingness to discuss a difficult project, and how they describe their own part in it, tells you what a problem will feel like from your side.
How do you prefer to be contacted, and what is your usual response time?
Why ask it
Mismatched expectations about availability cause more friction than technical disagreements. Agree the channel and the working hours before the first week, especially across time zones.
What do you think is the biggest risk in this project?
Why ask it
Ask last. A developer who names something real, unclear requirements, a dependency on an unstable API, your own approval bottleneck, is thinking about delivery. One who says there are no risks is selling.
Hiring and working with an app developer
Practical guidance for the conversation itself
Prepare before the first call
Write down what the app must do in one page
List the three things a user must be able to accomplish and who those users are. Developers price uncertainty, so an unclear brief costs you money whether or not anyone says so.
Separate must-have from nice-to-have in advance
Decide your own priorities before a developer decides them for you. If you cannot say which feature you would cut, you will be asked to cut one under time pressure later.
Set up your own accounts
Register the Apple Developer and Google Play accounts, the domain and the primary email yourself. Adding a developer as a collaborator is easy; recovering an account from a former contractor is not.
Know your budget range
Withholding it wastes both parties' time and produces proposals scoped for someone else. A stated range gets you a proposal shaped to what you can actually spend.
How to read the answers
- Specific numbers and named tools beat confident generalities. 'We use SwiftUI and ship a TestFlight build every Thursday' is a claim you can check.
- Watch for anyone who agrees with everything. A developer who never pushes back on scope will not push back when the scope is unrealistic either.
- Treat 'that's easy' as a warning rather than reassurance, particularly about payments, notifications, offline sync and background location.
- Ask what they would do differently on the last project like this. An honest answer here is worth more than the portfolio.
- If the quote is far below the others, find out what has been left out rather than assuming a bargain.
Put these in the contract
- 1Assignment of intellectual property to you on payment, covering code, designs and assets.
- 2Named deliverables and what 'done' means for each, including source code delivered to a repository you own.
- 3Payment tied to milestones rather than dates, with a retained final payment on acceptance.
- 4A written change process, with a stated hourly rate for work outside scope.
- 5A defect period after launch, typically thirty to ninety days, during which fixes to agreed functionality are free.
- 6Confidentiality, plus explicit terms on who may be shown the work as a portfolio piece.
- 7Termination terms: notice, what you are owed, and handover of accounts and credentials.
Once the work starts
Insist on an installable build on your own device at regular intervals from early on, even when it does much less than the finished app will. Test it yourself rather than delegating, and give feedback in one consolidated list rather than a stream of messages. Keep decisions in writing in one place, because six months later neither of you will remember why a feature was dropped. Pay on time; it is the cheapest way to stay at the front of a freelancer's queue.