Most founders spend weeks comparing agency quotes and about twenty minutes reading the contract. That is backwards. The price tells you what the first version costs; the contract decides whether you actually own what you paid for, whether you can switch teams without a rebuild, and who carries the risk when scope moves. This app development contract checklist is the list we would want any founder to walk through before signing with anyone, including us. It is not legal advice. Have a lawyer in your jurisdiction review the final document. But a lawyer can only protect what you know to ask for, so here is what to ask for.
1. IP assignment: who owns the code, and when
The single most important clause. You want the contract to say that all custom code, designs and documentation created for you are assigned to your company. Then check the trigger. Many agreements transfer ownership only on full payment, which is reasonable, but make sure it is per milestone or per invoice rather than only at the very end of the project. Otherwise one disputed invoice in month five can leave you without rights to anything. Also check who actually writes the code. If the vendor uses subcontractors or freelancers, the contract should require that their work is assigned through the vendor to you. An assignment from a company that never got the rights from its own people is weaker than it looks.
2. Pre-existing code and open-source licences
Every serious team reuses things: internal starter kits, component libraries, auth scaffolding. That is fine and usually saves you money. What matters is that the contract names it as the vendor's pre-existing IP and gives you a perpetual, royalty-free licence to use and modify it as part of your product, including after you stop working together. Ask for a list of open-source dependencies and their licences at handover. Most will be permissive, but a copyleft licence in the wrong place can matter if you ship on-premise builds or get acquired. Due diligence teams will ask, so it is cheaper to know now.
3. Source code access from day one
The code should live in a repository your company owns, with the vendor added as collaborators, not the other way round. Same for cloud accounts, app store accounts, domains, analytics and the database. Write it into the contract: accounts are created under the client's organisation, and the vendor gets access, not ownership. This is the clause that saves founders the most pain. A classic blocker in software rescue work is a previous team that still holds the Apple developer account or the only production database password. Getting those back can be slow, and sometimes it does not happen at all.
4. Scope, change requests and the pricing model
Whatever pricing model you choose, the contract has to say how change works. For fixed price, you need a written scope, acceptance criteria per feature and a change-request process with a turnaround time for quotes. For time and materials, you need rate cards, a weekly reporting format and a cap or alert threshold. Our post on fixed-price vs milestone billing goes deeper on which model fits which stage. Tie payments to things you can see working, such as a deployed staging build with agreed features, rather than to calendar dates. If you are still sizing the budget, our MVP cost ranges show how scope drives the number.
5. Acceptance, warranty and bug fixing
Define acceptance: how long you have to test a delivery, what counts as a defect versus a new request, and what happens if you say nothing. Then define a warranty period after launch during which the vendor fixes defects in delivered scope at no charge. The length is negotiable; what matters is that it exists and that it starts at production release, not at the last invoice. Severity levels help. A login outage and a misaligned button should not share the same response time.
6. Handover and exit
Assume you will switch teams one day, whether you hire in-house, change agency or get acquired. The contract should list what a handover includes: the full repository with history, infrastructure-as-code or written setup steps, environment variable names (not values sent over chat), architecture notes, a runbook for deploys and a few hours of paid knowledge-transfer calls. Also check termination. You want the right to end the engagement with reasonable notice, pay for work done to date, and receive everything above. A contract that makes leaving expensive is a contract that makes staying mandatory. If you are still deciding what kind of team to hire at all, read our agency vs freelancer vs in-house guide .
7. Confidentiality, data and compliance
A standard NDA clause covers your business plans. It does not cover user data. If the app will touch personal data, the contract needs data-processing terms: what the vendor can access, where it is stored, and what happens to copies when the project ends. If you are building in healthtech and the vendor will touch protected health information, ask about a business associate agreement before anyone sees production data. Our healthtech MVP compliance guide covers what to settle early. For AI features, add a line on which third-party model providers may receive your data and under what terms. Buyers will ask you the same question later.
8. Non-solicit, liability and the boring clauses
Many agencies include a non-solicit clause so you cannot hire their developers directly. That is normal; check the duration and whether there is a fair buyout fee if a developer wants to join you. Liability caps are also standard, usually tied to fees paid. Make sure the cap does not quietly exclude the IP and confidentiality promises above, since those are the ones that matter most.
A one-page checklist before you sign
All custom work is assigned to your company, with ownership passing per milestone or invoice. Subcontractor work flows through to you. Pre-existing vendor code comes with a perpetual, royalty-free licence. Repository, cloud, store and domain accounts sit in your organisation from day one. Change requests, acceptance windows and the warranty period are written down. Handover deliverables and termination terms are listed. Data-processing, and where relevant health-data, terms are in place. Liability caps do not swallow IP and confidentiality.
Founder takeaway
A good development partner will not push back on any of this, because none of it hurts a team that plans to do good work. If a vendor resists repository ownership or a clear handover clause, treat that as information about how the engagement will end. If you want to see how we handle ownership and handover on our own projects, talk to our team or look at our product development services .
