Most disputes between a client and an outsourcing agency in 2026 are not about quality. They are about ownership. The codebase ships, the system works, the invoice gets paid — and eighteen months later the client wants to migrate to a different vendor, or modify a module in-house, or sell the company, and discovers that the contract did not actually transfer what they thought it transferred. This article walks through the three contract lines we write into every engagement, what each one explicitly says, and the failure modes the lines exist to prevent.
This is not legal advice. It is a written-out explanation of the contract shape we use, so a prospective client can see what to look for in their own agreement — whether they sign one with us or with someone else.
1. Why The Conventional "Work For Hire" Clause Is No Longer Enough
The standard outsourcing contract template since the early 2000s has been a single "Work for Hire" clause: "All deliverables produced under this engagement shall be the sole property of the Client." That clause was sufficient when "deliverables" meant a folder of PHP files delivered on a CD. In 2026 it is not. Modern builds include AI-generated code, AI-generated tests, third-party dependencies under varied licenses, agency-internal libraries, infrastructure-as-code that lives in the agency's cloud account, model weights and prompts used to operate the system, and content schemas registered with external platforms. A clause that just says "the deliverables are yours" is silent on each of those, and the silence is where the disputes happen.
2. Contract Line One: Source Code And Derivative-Work Ownership
The first line we write is explicit on three sub-points.
The source code itself. Every line of source code committed to the project repository, including AI-generated code reviewed and accepted by an engineer, is transferred to the client on payment of each tranche. Not on project completion — on tranche payment. This matters because it caps the client's exposure: if the engagement breaks down after tranche three, the client owns the work through tranche three, not zero.
Derivative works. Any modifications, forks, or extensions the agency makes to the codebase after handover — for example, if the agency uses similar patterns on a future engagement — do not retroactively claim ownership. The agency retains the right to reuse generic patterns (Laravel scaffolding shapes, common Vue components) under a separate "reusable techniques" carveout, but specific business logic, schemas, and code paths belong to the client unconditionally.
Third-party dependencies. The contract lists every Composer, npm, pub, and other package the project relies on, with the license of each. The client receives a documented bill-of-materials, not just the lockfile. If a dependency changes license terms post-handover (it happens), the client knows what to audit.
3. Contract Line Two: Repository Custody And Access
Ownership without custody is theoretical. The second line addresses where the code physically lives and who controls access.
The repository is hosted under the client's account from day one. Not the agency's. The client creates a GitHub, GitLab, or Bitbucket organization and grants the agency push access. When the engagement ends, the agency removes itself; the client does not have to "transfer" anything because there is nothing to transfer. The repo never left their account.
Credentials are stored in the client's secret manager. AWS Secrets Manager, HashiCorp Vault, 1Password Teams — wherever the client already keeps their secrets. The agency holds working copies for the duration of the engagement and rotates them out at end-of-engagement. The agency does not retain post-engagement access to client credentials, ever, even for "support."
Build artifacts and container registries are also under the client's account. Docker Hub, GitHub Container Registry, AWS ECR — the agency builds into the client's registry, not its own. The same logic: when the engagement ends, the client's deployment pipeline keeps working because nothing has to move.
The agency maintains a separate "audit copy" of nothing. This sounds redundant but is important to state explicitly: the agency does not keep a copy of the production codebase on its own servers after handover. The only copies that exist are in the client's accounts. The contract specifies this and the agency complies in writing.
4. Contract Line Three: IP Clauses Around AI, Models, And Prompts
This is the line that was not in 2023 contracts and is mandatory in 2026 contracts.
AI-generated code is treated identically to human-written code. Every line generated by Claude Code, Cursor, GPT, or any other assistant during the engagement is reviewed and signed off by a senior engineer, and is then transferred to the client on tranche payment just like human-written code. The agency does not retain any residual rights on AI-generated code on the basis of "the AI did it."
Prompts and system instructions used to build agentic features. If the project includes AI agents — chatbots, copilots, automated workflows — the prompts that drive those agents are part of the deliverable. The contract names them as protectable IP that transfers to the client. This matters because in many 2026 projects, the prompts are the product.
Model weights and fine-tuning data. If the project trained or fine-tuned a model on client data, the resulting weights are client property, the training data remains client property, and the agency does not retain a copy of either. If the agency used hosted models (Claude, GPT, Gemini), the contract specifies the data-handling terms of those providers and confirms that client data is not retained for training. The clause is explicit about both directions: the client does not own the underlying foundation model, but everything trained on their data is theirs.
Reusable technique carveout. The agency retains the right to reuse generic AI-development techniques learned during the engagement — prompting patterns, agent-orchestration shapes, evaluation frameworks — on future engagements. The carveout is narrow and named. It does not cover client-specific prompts, business logic, or data.
5. Three Failure Modes These Lines Prevent
Each line exists because we have watched a real failure mode play out in past engagements.
Failure mode one: Eighteen months after handover, a client tries to migrate to a different vendor. The new vendor cannot get the repo because it lives under the original agency's GitHub account, and the original agency is now slow to respond. The repo-custody line prevents this; the client never had to migrate the repo because the repo was always theirs.
Failure mode two: A client tries to sell their company and a buyer's due diligence flags that the source code IP transfer is unclear. The acquisition stalls. The ownership line, written tranche by tranche, makes this immediate: the client points to tranche payments and the buyer's lawyer signs off.
Failure mode three: A client wants to migrate from one AI provider to another, and discovers the prompts and orchestration logic were never explicitly transferred. They have to either rebuild or pay the original agency to extract the prompts. The AI-clause line prevents this; the prompts were always client IP.
6. The Onboarding Conversation We Have With Every New Client
Before any code is written, we walk every new client through a one-hour conversation that confirms the three contract lines in plain language. The questions are simple:
- Which GitHub or GitLab organization will host the code? (If they do not have one, we wait until they create it.)
- Where will secrets live? (If they do not have a secret manager, we recommend one and wait until it is set up.)
- Who is the signatory who will accept tranche payments? (This determines who legally takes title to each tranche.)
- Are there any third-party AI services in scope that have data-retention or training-rights clauses we need to flag? (Almost always, the answer is yes for at least one service.)
- Is there a successor-vendor clause the client wants in the contract that automates handover if they ever migrate? (We recommend yes.)
This conversation typically adds an hour to the kickoff and saves months of dispute risk later. It is also a useful filter on the agency side: clients who decline to have this conversation tend to be clients who will later argue the contract said something it did not.
7. The Two-Page Contract Appendix We Attach To Every Statement Of Work
The three lines above sit in a two-page appendix attached to every statement of work we sign. The appendix is identical engagement to engagement; the SOW changes per project. The appendix includes the ownership clause, the repo-custody clause, the AI-IP clause, a bill-of-materials template, and a successor-vendor clause that requires us to provide reasonable handover assistance to any future vendor at our standard hourly rate. The bill-of-materials is filled in during the project and finalized at last-tranche delivery.
The reason to standardize the appendix is that it removes negotiation from each engagement and shifts the conversation to scope and price, which is where the conversation belongs. Clients comparing us to other agencies can ask each agency for their equivalent appendix; the agencies that cannot produce one quickly are signaling something about how they handle these questions.
If you are evaluating a build with any outsourcing partner this quarter — us or anyone else — the appendix question is the single most useful screening question to ask. The answer tells you, in five minutes, whether the contract you are about to sign will still serve you on day 731.