How to hire an app developer: brief, vetting, contract and handover

Should you hire an app developer at all?

Hiring is the most expensive way to learn whether an idea works. It is the right move when you already know what to build and cannot build it yourself, or when the product needs things a first AI-built prototype handles badly, such as payments between strangers or regulated data. It is the wrong move when your main question is still “does anyone want this?”.

Before you spend, check the cheaper routes. You can test demand with a landing page or interviews, as described in how to validate an app idea. You can build a first version yourself with an AI coding agent; how to build an app with Claude Code walks through it. Or you can look for a partner instead of a contractor, covered in how to find a technical cofounder.

This page covers the first three. For rough ranges on what building costs, see how much it costs to build an app. This page gives no price per hour because rates vary by country, skill and scope, and a figure from a page that has not seen your project is not a basis for a budget.

What should you prepare before you contact developers?

A written brief is the single best thing you can do. It lets candidates quote against the same scope, it shows who asks good questions, and it forces you to decide what the first version includes. A developer who quotes immediately without questions has not read it.

Keep the first version small. The guide to scoping an MVP shows how to cut a feature list down to one workflow, and the free MVP Scope Planner drafts one for you. Then fill in this brief.

Project name: [working name]

One sentence: For [specific person] who [has this problem], this app [does one thing].

Platforms: [iPhone / Android / web / all] and why.

The core workflow, step by step:
1. [What the user does first]
2. [What the app shows or stores]
3. [What the user gets at the end]

Included in version one: [Short list.]
Not included in version one: [Accounts? Payments? Admin screen? Push notifications? List them so nobody assumes.]

Data and privacy: [What personal data is collected. Who can see it. Any rules you know apply, such as children's data or health data.]

Integrations: [Payments, maps, email, third-party APIs. Name them.]

Design: [Wireframes, sketches, apps whose look you like, or 'designer needed'.]

How I will know it is done: [Five things I can test myself on my own phone.]

Budget range and deadline: [Be honest. A range filters out people who cannot do it.]

Ownership: I expect to own the source code, designs and accounts at handover.

What I want from your reply: [A fixed price or range for a first phase, your questions about this brief, two live examples you built, and who would work on it.]

If the idea is not yet described this well, the Idea Checker shows which parts are still missing, and the AI Coding Prompt Builder can turn the same description into a scoped build prompt.

Where do you find an app developer?

Start with people who can vouch for someone. A referral from another founder who shipped an app is worth more than any listing, because you can ask what went wrong. Beyond referrals, the usual sources are freelance marketplaces, agencies with public portfolios, developer communities and the credits in apps you already like. Each can produce good people and bad people, so the vetting steps below matter more than the source.

• Your network. Ask founders and product people who they would hire again. Ask what the worst week looked like.
• Apps you admire. Many app store listings and websites name the studio or developer. Message them with your brief.
• Marketplaces and directories. They give you volume and public reviews. They also give you many unqualified bidders, so cap the number of conversations at five.
• Communities. Founder forums and local meetups. Post the brief, not just “I need a developer”.
• The board. The ideas board is a place to see how other people describe what they want built, and the build prompts on each idea show what a precise brief looks like. It is not a hiring marketplace.

How do you vet an app developer?

Judge evidence, not pitch. A developer who can show you a live app, explain a decision they regret and name the part of your brief that worries them is worth more than a polished proposal.

If you cannot judge code yourself, pay an independent developer for an hour or two to read the proposal, or later to review the first delivery. It is a small sum against the cost of a bad build.

1. Walk me through the last app you shipped that looks like this one. What went wrong?
2. Which part of my brief worries you most?
3. What would you leave out of version one?
4. Who will actually write the code? Will anyone else touch it?
5. How do you show progress, and how often? Can I try a working build every week or two?
6. What do I get at handover: source code, accounts, documentation, deployment steps?
7. Who owns the code and designs when I pay, and where is that written?
8. What happens if I find a serious bug a month after launch?
9. What do you need from me, and by when?
10. Can I speak to a past client?

How should you pay an app developer?

There are three common arrangements. None is best for every project. What matters is that payment follows delivered, testable work rather than elapsed time or promises.

A strong default is a small paid first phase, then a decision. For example, pay for a scoped plan or one working feature first. If it goes well you continue with the next milestone. If not, you have lost little, and you own what you paid for.

Avoid large upfront payments for the whole build. Pay in steps tied to things you can run on your own device.

What should the contract say about ownership?

Do not assume that paying for code means you own it. The U.S. Copyright Office describes a “work made for hire” as a work prepared by an employee within the scope of employment, or a work specially ordered or commissioned for certain uses, if the parties expressly agree in a written instrument signed by them that the work shall be considered a work made for hire. Two points follow. A contractor is not an employee, and commissioned work only qualifies for certain uses. And the agreement has to be written and signed.

In practice, many contracts therefore also contain a clause that assigns the rights in the code to the client. Ask your lawyer to include one. Then check the contract against this list.

• Ownership of code, designs and assets transfers to you, in writing, and not only after a later payment.
• Third-party and open-source code is listed, with licences, so you know what you depend on.
• Scope, milestones and acceptance are written down: what is delivered, how you test it, and how many rounds of fixes are included.
• Payment is tied to accepted milestones, with the amount and date of each.
• Changes to scope go through a written change request with a price.
• Confidentiality covers your data and your plans.
• Handover names every item you receive: repository, accounts, documentation, build and deploy steps.
• Support after launch says what is covered, for how long, and what counts as a bug versus a new feature.
• Ending the contract explains what you get if either side stops midway.

Which accounts should be in your name?

Create the accounts yourself and give the developer access. If the developer publishes under their own account, moving the app later is awkward, and your customers see their name, not yours.

Keep credentials in a password manager and share access through each service's invite or team feature, not by sending passwords in chat. Remove access when the work ends.

How do you manage the build once it starts?

1. Ask for a working build early. Within the first couple of weeks you should be able to open something on your own device, even if it does one thing badly.
2. Run a short weekly check-in. The developer shows what works, you try it, and you agree what happens next. Keep notes in writing.
3. Test with real people. Give the build to the five people from your validation work and watch them use it.
4. Write bugs as steps. “On the second screen, tapping Save does nothing. Phone: [model]. Expected: [result].”
5. Hold the scope. New ideas go in a list called later. Each addition moves the date and the price.
6. Pay on acceptance. You accept a milestone when you have tested it against the criteria in the brief, not when the developer says it is done.

Before the final payment, confirm I have received and can access:

[ ] Source code repository, owned by my account or organisation
[ ] A written assignment of rights in the code and designs, signed
[ ] A list of third-party libraries and their licences
[ ] App store developer accounts in my name, with the builds submitted from them
[ ] Hosting, database and domain accounts in my name
[ ] Environment variables and keys documented, stored in my password manager
[ ] Steps to build and deploy the app from a clean machine, tested once by me or by a second developer
[ ] Documentation of the main parts of the system
[ ] A list of known bugs and open items
[ ] Agreed terms for fixes after launch
[ ] Developer's access removed or reduced to what the support terms need

What are the warning signs when hiring a developer?

• An instant, precise quote with no questions. They have not understood the project.
• Pressure to pay the full amount upfront. Payment should follow delivery.
• Hosting and accounts in their name. It gives them control over what you built.
• No live examples. Mock-ups are not evidence.
• Ownership “after the final payment, in the usual way”. Ask for the exact wording.
• A promise to build everything for a low price. Scope, time or quality will give.
• They agree with every idea. You want someone who will say no.
• Reluctance to show progress. A developer who cannot show a working build after the first two weeks is a risk.

If you find one, pause and ask directly. A good developer will answer. If the answer is vague or defensive, take that as information and keep looking.

What if you do not want to build the app at all?

Then you do not need a developer. You can post the idea publicly and let a builder with spare time take it on. Post your build ideas is free, takes no account and gives every idea a generated build prompt, but there is no obligation on anyone to build it. The trade-offs are in what to do with an app idea.