When a Client Sends You Their Own Contract to Sign
- A client sending their own contract is normal, especially with bigger or more established businesses. Their paper was written to protect them, not you, so it often fits a Claude Code build badly. Asking for changes is expected, not rude.
- Use the Profit Room's Redline Pass: read for six things - scope, payment, ownership, liability, termination, and restrictions such as non-competes - and send back a short, numbered list of the changes you need, each with a one-line reason.
- Push hard on the few clauses that can really hurt you, let the rest go, and get your scope written into the contract or attached to it. For a large contract, have a lawyer read it before you sign. If the client will not move on anything that matters, it is fine to walk away politely.
The Short Answer
When a client sends you their own contract, thank them, say you will review it and come back with any questions, and then actually read it. Do not sign it the same day to look easy to work with, and do not insist on swapping it for your own agreement. Their contract is a starting point. Your job is to find the handful of clauses that do not fit how you work and ask for changes in a calm, specific way.
That is the Redline Pass. Most clients expect some back and forth, and the person who sent the contract is often not the person who wrote it. A short, numbered list of changes with a plain reason for each tends to get approved quickly. A wall of objections, or silence followed by a signature you regret, is what goes wrong. This is general guidance from how we run our own projects, not legal advice, and for any large or unusual contract I think a lawyer's review is worth the cost.
Why Clients Use Their Own Contract
Usually it is policy, not distrust. Bigger businesses often have a standard agreement every vendor signs, sometimes written by their legal team years ago for a very different kind of supplier. Smaller clients may have borrowed one from a past contractor. Either way, it was written to protect them, which means it tends to lean their way on ownership, payment timing, and liability.
It also usually was not written for AI builds. A generic services agreement may assume you hand over everything you touch, including the reusable tools and skills you bring to every project, or it may say nothing about the AI tools you use to do the work. That gap is the reason to read closely. If you normally start with your [one-page agreement](/blog/one-page-agreement-before-you-build), use it as your checklist: anything your agreement covers that theirs does not is a conversation to have.
Run the Redline Pass
Read the contract once from start to finish, then a second time looking only for these six things. Mark each one as fine, a small change, or a must-change.
- Scope: does it say what you are building, or just 'services as requested'? A vague scope inside a strict contract is how unpaid work happens. Ask to attach your [scope of work](/blog/scope-of-work-that-prevents-scope-creep) as an exhibit.
- Payment: when you get paid, how much up front, and how long they have to pay an invoice. If the terms are long, [the net 60 conversation](/blog/client-asks-for-net-60-payment-terms) and [milestone payments](/blog/structure-client-payments-milestones) cover how to adjust them.
- Ownership: what transfers to the client and when. A fair version gives them the build they paid for once they have paid, while you keep your pre-existing tools, templates, and know-how. [Who owns the code you build for a client](/blog/who-owns-the-code-you-build-for-a-client) goes deeper.
- Liability: how much you could owe if something goes wrong. Look for limits on your liability, and for broad promises to cover the client against anything, which are worth narrowing.
- Termination: how either side can end the project, and what you get paid for work already done if they end it early.
- Restrictions: non-competes, exclusivity, and confidentiality. A reasonable NDA is normal; a clause that stops you working in their whole industry is not. See [when a client asks you to sign a non-compete](/blog/client-asks-you-to-sign-a-non-compete) and [when a client wants you to sign an NDA](/blog/client-wants-you-to-sign-an-nda).
| Clause | What to watch for | A fair ask |
|---|---|---|
| Scope | 'Services as requested' with no list | Attach your scope of work as an exhibit |
| Payment | Long payment terms, nothing up front | A deposit and milestone payments |
| Ownership | Everything you touch becomes theirs | They own the build once paid; you keep your own tools |
| Liability | No limit on what you could owe | A cap tied to what they paid you |
| Termination | They can end it with no payment for work done | Payment for all work completed to date |
| Restrictions | A broad non-compete or exclusivity | A narrow NDA covering their confidential information |
The Redline Pass: what to look for and what to ask
Claude Code can help with the reading. In the desktop app, you can ask it to summarize each section in plain words and flag anything about ownership, payment, liability, or restrictions, then check its summary against the actual text yourself. It is a fast first pass, not a replacement for reading the contract or for a lawyer on a big deal. Before you paste in a contract, check whether it is marked confidential, and handle it the way [is it safe to use Claude Code with client data](/blog/is-it-safe-to-use-claude-code-with-client-data) describes.
How to Ask for Changes
Send one message with every change you need, numbered, each with a single plain reason. Asking for changes one at a time makes the process feel endless. Lead with the fact that you want to sign, so the list reads as getting to yes, not as pushback.
Then decide in advance where you will give ground. You will not win every point, and you do not need to. Unclear scope, no deposit on a large build, losing your own tools, or unlimited liability are worth holding firm on. The wording of the notice clause, or which state's law applies, usually is not worth a fight. Whatever you agree, make sure it ends up in the final signed document, not just in an email thread.
When to Walk Away
Most clients will accept reasonable changes. If one will not move on anything that matters, such as insisting on owning every tool you have ever built or refusing to pay for work done before an early cancellation, that tells you how the rest of the project will go. It is fine to say no politely, and [how to turn down a client project](/blog/how-to-turn-down-a-client-project) has the words for it.
Then make the next one easier. Bring up contracts in your [expectations conversation](/blog/set-client-expectations-before-a-claude-code-build) before anything is drafted: 'Do you have a standard agreement you will want me to sign?' Finding out early gives you time to review it before the client is waiting on you, and it means the start date does not slip while paperwork goes back and forth.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
Is it rude to ask a client to change their contract?
No. Most clients expect some back and forth on their standard agreement. A short, numbered list of changes with a plain reason for each, sent with a clear message that you want to sign, usually goes over well.
What clauses should I check first in a client's contract?
Scope, payment terms, ownership of the work, limits on your liability, termination and what you are paid if it ends early, and restrictions such as non-competes or exclusivity.
Can I use my own agreement instead?
You can offer to, but bigger clients often have to use their own. A better approach is to accept their contract as the base, ask for the changes that matter, and attach your scope of work to it.
Should I have a lawyer review a client's contract?
For a large project, an unusual contract, or anything with broad liability or a non-compete, yes. The cost of a review is small next to the cost of signing something that hurts you.
Can Claude Code read a contract for me?
It can summarize sections in plain words and flag clauses worth a closer look, which makes a good first pass. Check its summary against the real text, and do not treat it as legal advice.
Last reviewed November 6, 2026.
Co-founder of the Claude Code Profit Room. Built and sold AI services to real clients; writes about offers, pricing, outreach, and closing with receipts.
More from Duncan Rogoff →
