What Your App Development Contract Must Include (IP, Scope, Handover)

Most app projects that end badly don't fail on code. They fail on a sentence nobody wrote down: who owns the source, what "done" means, whose name the app is published under, what happens when the money runs out halfway.

An app development contract doesn't need to be long. It needs to answer about a dozen questions before work starts, while everyone is still friendly. This is the checklist I'd want any client to have, whether they hire me or someone else. It's practical guidance from the developer's side of the table, not legal advice, so have a lawyer review the final document.

Key takeaways

• Intellectual property should transfer to you on payment, including source code, designs and documentation. Pre-existing tools and open-source code stay licensed, not assigned.
• Accounts must be yours from day one: code repository, Apple and Google developer accounts, cloud, domain and third-party services.
• Define "done" per milestone with acceptance criteria and a review window, and tie payments to accepted milestones.
• Write down how changes work. New ideas go into a change request with a price and a date, not into silent scope creep.
• Plan the ending now: a handover pack, a warranty period for bugs, and what happens to access if the contract ends early.

The 12 clauses that matter

Intellectual property: get the wording right

You want the contract to assign all project-specific work to your company once it's paid for: source code, designs, documentation and assets made for you. Two nuances matter:

• Pre-existing tools. Experienced developers bring their own utilities and templates. It's fair for those to stay theirs, as long as you get a perpetual, royalty-free licence to use them in your product.
• Open-source libraries. Your app will use dozens. They come with their own licences (MIT, Apache 2.0 and so on). Ask for a list, and for nothing with a licence that would force you to open-source your app unless you've agreed to it.

Accounts and access: the clause people regret skipping

Make it explicit that these belong to your company and are created in its name:

• The code repository (GitHub, GitLab or Bitbucket), with the developer added as a collaborator.
• The Apple Developer Program membership, enrolled as your organisation.
• The Google Play Console developer account.
• Cloud and backend services: hosting, database, storage, email, push, analytics, crash reporting.
• Domain names and DNS.
• Third-party APIs such as payments, maps and SMS.

Moving an app between developer accounts and transferring repositories is possible, but it's slow and sometimes messy. It's far easier to start in the right place.

Milestones, acceptance and change requests

A good milestone reads like this: "Milestone 2, booking flow: users can browse classes, book, cancel and receive a confirmation push on iOS and Android test builds. Acceptance: the client tests within five working days against the attached checklist."

Change requests should follow a simple rule: the developer estimates the change, you approve it in writing, and it gets a new milestone or extends an existing one. Nothing is "just a small thing" once it's on the record, and that protects you as much as the developer.

Fixed price or time and materials?

Many projects mix them: fixed price for the MVP, then time and materials or a monthly retainer afterwards.

The handover pack (save this list)

Whether the project ends happily or early, ask for this in the contract:

• Source code in your repository, with a README covering setup, environment variables and build steps.
• Access lists: every account, who has access, and how to remove it.
• Architecture notes: a one-page overview of the app, backend, data and integrations.
• Build and release notes: how to make a store build, how signing works, how over-the-air updates are configured.
• Third-party services list, with plans, costs and renewal dates.
• Known issues and the agreed "later" list.
• A short recorded walkthrough of the codebase.

Red flags in a proposed contract

• IP transfers only "on completion of the entire project" with no milestone-level transfer.
• The app will be published under the developer's or agency's account.
• No acceptance criteria, just "delivery".
• Unlimited revisions or unlimited liability on either side.
• No termination clause, or one that leaves you without the code.

Contracts across borders

Many app projects involve a client and developer in different countries, which adds a few points worth writing down:

• Governing law and disputes: which country's law applies and how disputes are handled, often mediation first.
• Currency and payment method: the invoice currency, who pays transfer fees, and the platform (bank transfer or services such as Wise or Payoneer).
• Taxes: each side handles its own taxes; check with an accountant whether withholding or reverse-charge rules apply in your country.
• Signing: electronic signatures are accepted for commercial contracts in most countries; keep the signed PDF with your company records.
• Working hours and communication: the overlap hours and response times you expect, so time zones don't become a dispute.

FAQ

Who owns the source code of my app?

Whoever the contract says. Without a clear assignment clause, the developer may keep ownership of the code they wrote, depending on your country's law. Make sure the contract assigns project-specific code, designs and documentation to your company on payment, with a licence to any pre-existing tools.

Do I need an NDA before sharing my app idea?

It's reasonable to sign a simple mutual NDA before sharing details, and most developers will agree. In practice, ideas are rarely the valuable part. Execution, data and users are. Put the important protections, like confidentiality and IP, in the main contract.

What's a reasonable warranty period for an app?

A bug-fix period of 30 to 90 days after launch is common. It should cover defects against the agreed scope, not new features or problems caused by later changes. Ongoing support beyond that usually moves to a retainer.

Should my app contract be fixed price or hourly?

Fixed price per milestone works well when the scope is clear, such as an MVP. Hourly or a retainer suits evolving products and ongoing work. Either way, insist on milestones, written change requests and visible progress.

Next steps

If you're about to sign a development contract and want a developer's view on what's missing, send it over and I'll point out the gaps. For the legal wording itself, use a lawyer. Get in touch, or see how I work as a React Native developer.

Sources

• Enrolling as an organization, Apple Developer Program
• Transferring a repository, GitHub Docs
• Transfer apps to a different developer account, Google Play Console Help
• Licenses overview, Open Source Initiative