You found an agency. They have a solid portfolio, reasonable rates, and the discovery call went well. Now they've sent over a contract.
Most clients read the scope, check the price, glance at the timeline, and sign.
That's a mistake — and one we've seen play out badly more times than we'd like to count.
The clauses that hurt clients most aren't the obvious ones. They're buried in the sections most people skip: intellectual property, deliverables, and what happens when the engagement ends. These three areas can make the difference between a successful partnership and a situation where you've paid six figures for code you don't own, in a system no one documented.
Here's what to negotiate before you sign.
1. Code Ownership: Who Actually Owns What You're Paying For?
In a fair engagement, the client owns the code. But "fair" isn't the default — it has to be written into the contract.
Many agency contracts include language that transfers intellectual property to the client only upon final payment. That sounds reasonable until you realize what it means in practice: if you're halfway through a project and you want to switch agencies, bring work in-house, or dispute a final invoice, the agency still owns the codebase. You can't legally take it and leave.
What to push for:
- Ownership transfers at each milestone, not just at final payment. As deliverables are accepted and invoices paid, IP transfers.
- Repository access from day one. You should have admin-level access to the version control repo — GitHub, GitLab, Bitbucket — not just read access, and not access granted at the end. If they push back on this, ask why.
- Third-party component disclosure. Any open-source libraries, licensed SDKs, or components from external vendors should be listed. You need to know if your "custom" software includes a critical dependency with a restrictive license.
- Work-for-hire language. In most jurisdictions, software built for a client under contract qualifies as work-for-hire. Make sure the contract says this explicitly rather than leaving it to interpretation.
The agency doing this right will have no problem with any of these terms. The one that resists them is telling you something.
2. Handover Terms: What Are You Actually Getting at the End?
A lot of agencies treat handover as an afterthought — something to figure out when the project is "done." But if handover isn't defined in the contract, you're relying on goodwill rather than obligation.
We've talked to founders who received a production-ready app with zero documentation. No README, no deployment guide, no explanation of how the infrastructure was set up or why certain architectural decisions were made. Technically, the agency delivered — they just didn't deliver anything useful for long-term ownership.
What a proper handover should include — and should be written into the contract as a deliverable:
- README and setup guide — How to run the project locally, how to configure environments, dependencies.
- Architecture documentation — A high-level overview of the system: key components, how they connect, what each service does. Doesn't need to be a dissertation — it needs to be enough for a new developer to understand the system in an afternoon.
- Deployment runbook — Step-by-step instructions for deploying to staging and production. How to roll back. What monitoring is in place.
- Environment configuration guide — What environment variables exist, what they control, where secrets are stored and how to rotate them.
- Knowledge transfer session — At minimum one working session where the lead developer walks your team (or your next agency) through the codebase.
These aren't optional extras. If an agency is proud of what they built, they'll have no problem documenting it. If they treat documentation as unnecessary overhead, that tells you something about their engineering culture.
3. Exit Terms: What Happens When the Relationship Ends?
Every engagement ends — successfully, prematurely, or somewhere in between. What happens when it does should be defined upfront, not negotiated under pressure.
This is the section most contracts handle poorly. Vague exit terms aren't accidental — they give agencies leverage. If the process for getting your data, your repo, and your access back is undefined, you're dependent on the agency's cooperation. That's a bad place to be.
What to negotiate:
- Repo transfer SLA. If you want to move the repo to your own organization, how long does that take? 48 hours is reasonable. "When we get around to it" is not. Put a number in the contract.
- Data export. What data does the agency hold? Databases, backups, analytics, user data. Define what you're entitled to receive and in what format.
- Access revocation timeline. When the engagement ends, all agency team member access to your systems, repos, and cloud environments should be revoked within a defined window. Without this clause, ex-employees of the agency may retain access to your production systems indefinitely.
- Post-exit support. Is there a period where the agency is available to answer questions? What does that cost? Having 30 days of paid Q&A access defined in the original contract is far cleaner than trying to negotiate it after.
- Survival clauses. Confidentiality and IP transfer obligations should survive contract termination — make sure the contract says so explicitly.
Red flags to watch for: Agencies that get defensive about exit terms, use language like "standard practice" to avoid specifics, or include clauses that require extended notice periods before repo access can be transferred. Protecting yourself at exit is standard practice. An agency resistant to that is protecting their leverage, not your interests.
A Note on How We Think About This
At TMNSolutions, we put these terms in our contracts by default — not because clients ask for them, but because we believe clients should have them. Code ownership transfers at each milestone. Handover is a defined deliverable. Exit terms are explicit and fair.
If you're evaluating agencies and these topics make any candidate uncomfortable, pay attention to that discomfort. A good agency partner doesn't need leverage over your codebase to maintain the relationship.
The goal of a well-written contract is that you never need to rely on it. But if things go wrong, you'll be glad it was there.
