What contract terms protect you when hiring app developers

Hiring app developers without a solid contract is one of the most reliable ways to end up with nothing to show for a significant spend. The contract is the real work, or at least the foundation everything else rests on. Get it right and you have a clear framework for every decision that follows. Get it wrong and you discover the gaps exactly when you can least afford to.

A contract is the framework for every decision that follows, not the paperwork before the work starts.

We have watched projects burn through entire budgets without a single build reaching the app store. We have seen clients lose ownership of code they paid for, developers disappear mid-project, and scope balloon to twice the original estimate because nobody defined what "done" actually meant. On the sports club app project we worked on, what should have reached market in three to four months never launched after twelve to fourteen months of development, and the budget almost doubled. The contract terms did not cause that outcome, but sharper contract language would have created earlier stopping points and clearer accountability for the decisions that led there.

This article covers the contract terms that matter most when you are commissioning app development. Not in the abstract, but drawn from the patterns we have seen repeated across projects, and the places where vague language consistently causes real damage.

Who owns the code when the contract ends

Intellectual property assignment is the single clause most clients assume is already covered, and it often is not. A developer who writes code owns that code by default unless the contract explicitly transfers ownership to you. Without an assignment clause, you may be licensing the work rather than owning it, which limits what you can do with it if the relationship ends.

The clause needs to be specific. It should cover the source code, any libraries written specifically for your project, design assets, database schemas, and documentation. It should also clarify the point at which ownership transfers, because some contracts only assign IP after final payment is made. If payment is disputed, that timeline matters.

Pre-existing code and open source

Developers routinely bring pre-existing code, proprietary libraries, or open source components into a new project. These cannot be assigned to you because the developer either does not own them outright or they are governed by a separate licence. The contract should list any pre-existing IP the developer intends to use and specify that you receive a perpetual, royalty-free licence to use it as part of your product. Without that, your product may depend on code you have no right to deploy commercially.

What transfer actually means

Ownership on paper means nothing without access. The contract should require the developer to deliver all code to a repository you control, and to do so at agreed intervals rather than only at the end of the engagement. Waiting until the final invoice to receive the codebase leaves you exposed if the relationship breaks down before that point.

Defining the scope in writing before a line is written

Scope is where most projects start to come apart. A feature that one party considered obvious and already included is the other party's extra, and without a written specification neither of you has a clean way to resolve that disagreement. Up to 77% of software project respondents, according to Geneca, say they do not know how to tell when their project is done, which describes exactly what happens when scope is left to interpretation.

The scope document needs to describe what the product will do, what platforms it will run on, and what it will not do. That last part is often left out, and it is where the trouble lives. On the sports club app project we worked on, both co-founders independently and consistently pushed to add features each considered obvious and already implied. Because the original scope did not explicitly exclude anything, every addition was a reasonable interpretation rather than a clear change request. That dynamic drove the project from a three-to-four-month timeline to fourteen months without ever reaching launch.

A scope document is a plain-language description of the product you are commissioning, agreed and signed by both parties before any build work begins.

Ask your developer to walk through the scope document feature by feature before signing. Any feature they interpret differently from you is a gap that will cost money later. Resolve it in writing before work starts, not after.

What change request clauses actually cost you

Change requests are the mechanism by which scope creep becomes billable. Every project has them, and a well-written contract does not try to eliminate them. It creates a process for handling them that protects both sides.

The change request clause should specify that any change to the agreed scope must be submitted in writing, assessed for cost and timeline impact, approved by a named decision-maker on your side, and confirmed in writing before any additional work begins. That last step is the one most commonly skipped. Verbal approvals feel efficient in the moment and become expensive disputes six weeks later.

Verbal approvals feel efficient in the moment and become expensive disputes six weeks later.

The fitness and wellness product we worked on illustrates how approval processes can break down even with good intentions. We would get sign-off on a design, begin building, and then the clients would walk back their approval, saying they had not understood that this was what would actually be built. There was no consensus between the two co-founders, and approvals were given to be polite rather than as a genuine decision. By the time the budget ran out, the project had never progressed beyond the design and research stage. A formal written approval process, tied to a named individual with actual authority, would have caught this earlier.

The clause should also specify what happens when you request a change the developer believes is outside their capability or timeline. You need the right to seek external help in those circumstances, without that being treated as a breach of contract.

Name one person on your side who has authority to approve change requests. If two co-founders both have that authority independently, you will get conflicting approvals and no clear record of what was actually agreed.

Payment milestones and what they should be tied to

Payment schedules structured around calendar dates, rather than deliverables, transfer all the risk to the client. If you pay thirty percent at signing, thirty percent at four weeks, and the remainder at completion, you have no mechanism to pause payment if progress stalls. Milestone-based payment puts the incentive where it belongs.

Good milestones are tied to working software or agreed outputs, not effort or time spent. The list below shows how a reasonable milestone structure compares to a calendar-based one.

Each milestone should define clearly what constitutes completion, who signs off on it, and how long that sign-off review period lasts. If you do not respond within the review window, the contract should state whether the milestone is deemed accepted or whether the clock pauses. Either is fine, but the contract needs to say which.

On longer engagements, a retention amount held back until a defined period after launch, typically thirty to sixty days, gives you leverage to address issues that only surface with real users rather than test accounts.

App store account ownership and access rights

The app store account is not a detail to sort out later. Who holds the Account Holder role on App Store Connect or Google Play determines who has ultimate control over the published product, including the ability to remove it from sale, transfer it, or refuse access to other parties.

On the social football product we worked on, the client held the App Store Connect Account Holder role because the account was registered in their name. We were given admin access to most of the account and set up three internal testing groups, one for our team, one for the client, and one external QA beta test group for the client's testers. This structure let us control which builds went to which groups during the deployment process. As the project approached launch, the client began bypassing that structure by manually sending uploaded builds to whichever group they wanted, which caused real problems. Because everything was on their account, they had full access and we had limited ability to prevent it.

The lesson is straightforward. The contract should specify who holds the Account Holder role, what access levels each party has, and whether either party can modify deployment configurations without the other's written agreement. If you are the client, the account should be registered in your name from day one. Transferring an account after the fact is possible but adds friction you do not need.

Register the app store account in your own name before development begins. Handing over account credentials to a developer creates a dependency that becomes very difficult to untangle if the relationship ends on poor terms.

Third-party services, APIs, and integration dependencies

Apps routinely depend on services owned and operated by third parties. Payment gateways, mapping services, push notification providers, analytics tools, and cloud infrastructure all introduce dependencies your contract needs to address. When those services change their pricing, deprecate an API, or go offline, the impact falls on your product regardless of whether your developer anticipated it.

We worked on a baby monitor product where the client was building both physical hardware and the companion app. The integration turned out to be far more complex than originally envisaged, moving well beyond off-the-shelf Bluetooth protocols. We had to formally define a software-hardware contract that specified exactly how the app would communicate with the device, covering turning things on and off, retrieving sensor data, and accessing camera feeds, all in a format the app could consume. That level of integration definition is unusual, but the principle applies to any significant dependency.

On the alcohol buying and selling platform we worked on, being forced to embed web elements instead of building a proper API layer added approximately 20% uplift in work across the entire length of the project. Because the client wanted to keep the budget the same, we had to drop features towards the end of the project to compensate for that unplanned work.

The contract should list all planned third-party integrations, state who holds the accounts and API keys, and specify what happens if a third-party service becomes unavailable or changes its terms. Responsibility for monitoring licence changes sits somewhere, and it should be named. Only 52% of developers say they always consider security when evaluating a new third-party library, according to Veracode via Dark Reading, which means the default assumption cannot be that your developer is watching these things without prompting.

Acceptance criteria and sign-off procedures

Acceptance criteria define what "done" means for each deliverable. Without them, a developer can reasonably argue that a feature works as built even if it does not work as you expected. With them, both parties have an objective standard to test against.

Criteria should be written in plain language and tied to user behaviour, not technical specifications. "The user can complete checkout in under four steps from the basket screen" is a testable criterion. "The checkout flow is implemented correctly" is not. The more specific the criteria, the less room for disagreement at sign-off.

The sign-off review window

The sign-off procedure should specify how long you have to review each deliverable, what format your feedback should take, and how many rounds of revision are included in the original fee. Open-ended revision cycles are one of the most common sources of cost overrun. Two rounds of amendments per deliverable, with additional rounds charged at an agreed rate, is a reasonable structure that protects both sides.

Conditional and phased acceptance

For complex features, partial acceptance, where you accept a feature for testing but reserve final sign-off until it performs in a live environment, can be useful. The contract needs to define whether this is an option, what conditions apply, and how long the conditional acceptance window lasts before it converts to full acceptance.

Confidentiality, data handling, and security obligations

An NDA is not a substitute for specific confidentiality provisions in the development contract. A standalone NDA covers information shared before and during negotiations. The development contract needs to address what happens to your data, your users' data, and your business logic once the engagement ends.

The contract should specify that the developer will not retain copies of your source code, user data, or commercially sensitive information after the engagement concludes, and that all such material will be returned or destroyed within a defined period. If the developer uses any of your data for testing, it should be anonymised. This is a legal requirement in many jurisdictions, not a preference.

Security obligations should also be explicit. On the performance coaching survey app we worked on, the biggest technical challenge was locking down Firebase security rules without the protection of a dedicated API layer. By making a deliberate early decision to skip a traditional API for the MVP, we had to scrutinise every security rule very carefully to ensure that neither the app nor the web response page could be exploited, since there was no API acting as a controlled intermediary between the client and the database. The security decisions we made were our professional judgement calls. A contract that defines the expected security standard, and assigns responsibility for meeting it, makes that kind of decision traceable.

The contract should also state whether the developer is permitted to subcontract any work, and if so, whether their subcontractors are bound by the same confidentiality and security obligations.

Termination rights and what happens to the work in progress

Termination clauses get written for worst-case scenarios, which is exactly why they need to be specific. A clause that lets either party terminate "for convenience" with thirty days notice sounds reasonable until you consider what happens to work in progress, payments already made, and access to assets held by the developer at the time.

The clause should address three scenarios separately.

1. Termination by you for convenience. What notice is required, what you pay for work completed to date, and what the developer delivers to you before access is removed.
2. Termination by you for cause. What constitutes a breach, what remedy period the developer has, and what your payment obligations are if they fail to remedy.
3. Termination by the developer. Under what circumstances they can exit, what notice they must give, and what their obligations are around handover.

In every scenario, the contract should require the developer to deliver all work in progress, code, documentation, and credentials to you before the termination takes effect. Holding these back as leverage in a fee dispute is a common tactic, and a well-drafted contract removes that option. Poor contract management costs organisations between five and nine per cent of annual revenue, according to Ironclad's 2025 Legal Operations Field Guide. Most of that loss occurs not in litigation but in poorly structured exits and unrecoverable work.

Warranties, liability caps, and post-launch support

A warranty clause gives you a period after delivery during which the developer is obliged to fix defects at no extra cost. Thirty to ninety days is standard. The clause should define what counts as a defect, whether that includes performance issues or only functional failures, and what the response time commitment is for different severity levels.

Liability caps

Developers will typically seek to cap their liability at the total value of the contract. That is a reasonable position. What you need to ensure is that the cap applies symmetrically, and that it does not exclude liability for intellectual property infringement or data breaches, where uncapped exposure is more reasonable to expect. Unlimited liability in those areas gives you recourse where the damage can be most serious.

Post-launch support

The warranty period covers defects. Post-launch support is a separate commercial arrangement and should be contracted separately. That support agreement should specify what is included, whether it covers OS updates, third-party API changes, and app store requirement changes, and what the response and resolution time commitments are. Apple's App Store review requirements change periodically, and an app that is compliant today may face rejection when it next updates if nobody is watching for changes.

On the currency exchange project we worked on, the client spent significant money on legal counsel and compliance work only to face fresh rejection criteria each time Apple raised a new objection. Apple kept creating new rules and objections to what was built, and the process had no effective mechanism for a developer to challenge this behaviour. No contract clause can prevent that scenario, but a post-launch support agreement that includes app store monitoring and response gives you a team who is watching for it rather than discovering it after the fact.

Conclusion

A development contract does not guarantee a good outcome. What it does is create the conditions under which a good outcome is more likely, and give you a clear framework to work from when things go differently than planned. The projects we have watched go wrong rarely failed because of bad intentions on either side. They failed because assumptions went undocumented, approval processes were informal, and scope was left to interpretation until the interpretation mattered.

The terms covered in this article, IP assignment, written scope, change request procedures, milestone-based payment, account ownership, third-party dependencies, acceptance criteria, confidentiality, termination rights, and post-launch support, are the baseline. A developer who pushes back hard on any of them is worth questioning. A developer who welcomes them is signalling that they have been on the other side of poorly structured engagements too.

Get the contract right before any build work begins. The cost of a thorough review at that stage is a fraction of what it costs to unwind problems that a good contract would have prevented. If you are about to commission app development and want to talk through what your contract should cover for your specific product, let's talk about your project.

Frequently Asked Questions