What an app development contract has to settle before anyone writes code

Ownership: the clause that has to survive the developer disappearing

The default position in most common-law systems is that an independent contractor owns the copyright in what they create, and paying the invoice does not change it. For software the American work-made-for-hire route is not available either: the statutory categories do not include standalone software, so a work-for-hire clause on a custom build achieves nothing by itself. Who owns the work sets out why in detail; the drafting consequence here is simple.

• A present-tense assignment. "Developer hereby assigns" transfers on signature. "Developer agrees to assign" is a promise to do something later, which is worth much less if the relationship ends badly.
• Triggered on payment in full, not on creation or delivery. This is the developer's security and it costs a paying client nothing.
• A fallback licence — perpetual, irrevocable, worldwide, royalty-free — for anything that cannot be assigned, plus a waiver of moral rights where the governing law permits one.
• A background IP carve-out. The developer's pre-existing libraries, frameworks, internal tooling and boilerplate stay theirs, with a licence to the client covering whatever is embedded in the deliverable. Without this the clause reads as transferring the developer's entire toolkit, which is why developers resist broad assignments.
• Further assurances. An obligation to sign whatever additional documents are needed to record the transfer, years later, with registries or an acquirer's counsel.

Then a delivery obligation, kept separate from the IP clause because it is a different thing: the complete source, build configuration, dependency manifests, infrastructure definitions, design source files, and enough documentation for a competent third party to build and deploy it. Copyright ownership does not oblige anyone to hand over a repository. That is a scope term.

Acceptance: the clause that decides when you pay

Acceptance testing converts a delivery into a payable milestone. The mechanism is standard: the developer delivers, the client tests against agreed criteria for a defined window, and either accepts or issues a defect report classified by severity. Failure gives the developer a cure period and a re-test. The details of that loop are where the money is.

Deemed acceptance is normal and defensible — without it, a client can withhold sign-off indefinitely and never pay. But it means the testing window is a real obligation on the client, and a ten-day window agreed in a kick-off meeting will collide with a holiday, a release freeze or the one person who understands the domain being unavailable. Negotiate the length against your actual capacity, and make the window start on delivery of something testable rather than on notification.

• Write the criteria before the build, not at delivery. Criteria agreed retrospectively are criteria argued about retrospectively.
• Define severity levels concretely — what makes a defect critical, major or minor — because only critical and major defects should block acceptance, and the boundary is otherwise a matter of opinion.
• Say that minor defects do not block acceptance but go on a snag list with a fix deadline. Otherwise trivial issues are used to hold up payment, or waived entirely and never fixed.
• Cap the cure cycles. After a second failure the client should have a real remedy: terminate the milestone, recover payments made for it, and keep the work in progress.
• State what acceptance does not waive. Accepting a milestone should not waive the warranty, latent defects, or the security obligations.

Source code escrow, and when it earns its fee

Escrow is a three-party arrangement: the supplier deposits source and build materials with an independent agent, and the agent releases them to the customer on defined trigger events. The conventional triggers are the supplier's insolvency, discontinuation of the product, and failure to meet maintenance and support obligations after a cure period.

It is worth understanding what it is for. Escrow does not apply to custom development where the client already owns the code and holds the repository — there is nothing to escrow. It applies where you depend on software you do not own and cannot maintain: a licensed platform, an embedded component, an on-premise product from a small vendor, a white-label application. Those are the cases where the supplier failing leaves you with a running binary and no ability to change it.

The accounts and keys nobody puts in the contract

This is the most common practical failure in app projects, and it has nothing to do with intellectual property. Ownership and control are two separate axes, and a contract that settles only the first leaves you in the square nobody plans for.

Apple's own guidance points the same way: an app should be published under the developer account of the business that owns it, because the store relationship is with the owner of the content. An agency publishing a client's app from its own account creates a mismatch that surfaces during app review, during a transfer, and during any dispute.

The contract should list them, say who holds each during the project, and require transfer of all of them at handover or on termination for any reason. Then test the list before final payment: log in to each account using client credentials. An access list that has never been exercised is the same kind of fiction as an untested backup.

Fee model, change control and the scope you did not price

Fixed price transfers estimation risk to the developer, who prices that risk into the number and defends the scope boundary hard. Time and materials transfers it to the client, who then carries the cost of every change of mind. Capped time and materials splits it, and is the model most likely to produce a workable relationship — provided the contract says what happens when the cap is reached, which is the term most often left out.

Whichever model applies, the change mechanism has to be usable. Changes take effect only through a written change order referencing the affected milestone and signed by both sides, with a lightweight route for small items — a named approver each side, an email confirmation, a value ceiling. A process too heavy for a two-hour change is a process that gets bypassed, and bypassed changes are the raw material of scope disputes. Where the build sits under a master agreement, MSA and SOW covers how the two documents interact and which one governs when they disagree.

Warranty, security and the period after launch

• A warranty period after acceptance — 60 or 90 days is common — during which defects against specification are fixed at no charge. Distinguish it clearly from paid support, or every support ticket becomes a warranty argument.
• Security obligations that outlive the project: dependency updates during the warranty period, a disclosure route, and notice to the client of vulnerabilities found in delivered code.
• Store compliance. Rejections by Apple or Google for policy reasons are the developer's to fix where they relate to the implementation, and the client's where they relate to the business model. Allocating this in advance avoids the most predictable argument in mobile work.
• Portfolio rights. Developers will want to show the work. Grant it expressly, with a confidentiality carve-out, rather than leaving it to an argument after launch.

If you are already mid-project without any of this

Do three things this week, in order. Get a signed IP assignment covering everything produced to date — retrospective assignments are awkward, but the leverage only ever moves away from you. Take a full copy of the repository, the dependency inventory and the build configuration, and confirm they build outside the developer's environment. Then transfer or create the store, signing and cloud accounts in your own name.

None of that requires renegotiating the commercial deal, and all three are ordinary requests that a competent developer will expect. A developer who resists all three has told you the most useful thing you will learn about the project, and told you it while you can still act on it.