Should You Tell Clients You Use AI to Build? (Yes, and Here Is How)
- Disclose, and do it on your own terms before the price conversation. A fact you volunteer is a method. The same fact discovered later is a surprise, and surprises get repriced.
- The Method Line is one sentence stating how you build, delivered flat, with no apology and no pause for reassurance. Where builders lose the room is not the disclosure, it is the nervous paragraph they add afterwards.
- Disclosure should not change your price, because the client is buying a working outcome and the responsibility for it. If naming your tools collapses your fee, the fee was attached to hours rather than to results.
The Short Answer: Yes, Early, and On Your Terms
Tell them. Say it before the price is on the table, in one sentence, and then keep talking about their problem. You are not asking permission and you are not making a disclosure in the legal sense. You are describing how the work gets done, the same way a builder would mention which materials they use.
The reason to go first is simple. Information you volunteer is context. The identical information discovered later is a surprise, and a client who feels surprised revisits everything else you told them. That is how a fee that was fine on Monday becomes a negotiation on Thursday, and the trigger is almost never the AI itself.
Why Hiding It Costs More Than Saying It
Concealment fails on timing. The chance a client never finds out is low and falling, and the moment they do find out is not one you control.
Consider where the discovery actually happens. A screen share where a session is open. A commit history with a pattern anyone technical will recognise. A file in the repository that describes the working setup. Their nephew who builds things. A competing quote from someone who mentioned it openly and made you look like the one with something to hide. None of those moments favour you, and all of them arrive after money has changed hands.
Then there is the version that costs the most. A client who feels misled does not usually confront you about the tool. They quietly stop extending the engagement, they do not refer you, and the answer they give when someone asks about you is lukewarm. You never get told why. That is a far larger bill than a slightly awkward sentence in a first call.
The Method Line
The Method Line is the Profit Room's name for one sentence that states how you build, delivered early, flat, and without a follow-up apology. One sentence. Then you move on.
It has three parts and they are always in the same order. What you use, what you do with it, and who carries the responsibility. That third part is the one that matters, because it is the part the client is actually asking about when they raise an eyebrow.
- I build with AI tooling, which is why I can ship in weeks rather than months. States the method and the benefit in the same breath.
- The architecture, the decisions and the testing are mine, and I am the one on the hook if it breaks. Names the responsibility, which is what they are buying.
- You are hiring judgement about what to build, not typing speed. Sets the frame before the price lands.
Then stop. The single most common mistake is what comes next: a long justification nobody asked for. A flat statement followed by silence reads as normal. The same statement followed by three sentences of reassurance reads as a problem being managed, and the client starts wondering what the problem is.
When to Say It
Deliver the Method Line on the first real conversation, after they have described the problem and before you talk about money. That position is deliberate.
| Moment | Effect | Verdict |
|---|---|---|
| In your first outreach message | Leads with your tools instead of their problem | Too early. They have not agreed there is a problem yet |
| Early in the first call, before price | Reads as how you work. Sets up speed as a benefit | Correct. This is the slot |
| In the proposal only | Technically disclosed, but they read it alone with no chance to ask | Weak. Put it in the proposal as well, not instead |
| After they have accepted the price | Reads as something you held back until the money was agreed | Damaging. This is where repricing starts |
| Mid build, because they asked | You are now answering rather than telling | Recoverable, but you have lost the initiative |
| Never, until they discover it | Becomes a question about your honesty, not your tools | The expensive outcome |
Where the Method Line lands, and what happens
Say it once in conversation and once in writing. Once on the call so they can react and ask, once in the proposal so it is on record. Repeating it more than that starts to look like you think it is a bigger deal than they do, which is its own kind of signal.
Handling: Then Why Am I Paying You?
The answer is that they are paying for the decision about what to build, the judgement to know when it is wrong, and someone who is accountable when it breaks at an inconvenient hour. None of that comes with a subscription.
Take the question seriously rather than defensively, because it is a reasonable one. The useful reframe is availability. The tools are available to everybody, including them, and have been for a while. What is not available is somebody who knows which of the forty possible builds solves their specific problem, who has done it before on a system like theirs, and who will still be answering the phone in March.
A worked example beats an argument here. Point at a decision on a past project that had nothing to do with typing: the feature you talked a client out of, the integration you refused because their system could not support it, the simpler approach that saved a month. Those are the things they cannot buy for twenty dollars, and naming one specific instance settles the question faster than any general statement about value.
If the objection persists in the harder form, where they intend to do it themselves, that is a different conversation with its own answer, set out in [why not just use ChatGPT myself](/blog/why-not-just-use-chatgpt-myself-objection).
Clients Who Genuinely Cannot Have AI in the Process
Some of them exist and they are not being difficult. Certain organisations have contractual or regulatory obligations about where data goes and which third-party services touch it, and those obligations apply to their suppliers.
When you meet one, the correct response is to ask what their obligations actually require rather than to argue or to quietly proceed anyway. Frequently the restriction is narrower than it first sounds. It may cover their production data but not a greenfield project with synthetic test records. It may require an agreement about retention that you can satisfy in a paragraph. You cannot know until you ask, and asking is what a supplier who takes it seriously looks like.
Occasionally the answer really is no, and then you decline the work cleanly and stay on good terms. Winning a project you cannot deliver within the client's constraints is not a win. The practical detail on this sits in [is it safe to use Claude Code with client data](/blog/is-it-safe-to-use-claude-code-with-client-data), which is worth reading before you are asked rather than during.
Put It in the Agreement, Not Just the Call
One line in the written agreement covering method, ownership and confidentiality closes the loop. A verbal mention six weeks ago is not much protection when a question comes up later.
- State the method plainly. A sentence saying the work is produced using AI-assisted development tooling, reviewed and tested by you, is enough.
- Confirm ownership of the deliverable transfers to the client on final payment, so the question of what they own never gets tangled up with how it was made. The detail is in [who owns the code you build for a client](/blog/who-owns-the-code-you-build-for-a-client).
- Say what happens to their data and materials, including that you will not put confidential material into any tool without their agreement.
- Keep your warranty about the work itself. You are responsible for it functioning as described, and the method does not change that. This is the line that reassures a cautious buyer more than anything else in the paragraph.
This does not need a lawyer or a long document. Four lines inside [the one-page agreement you should already be sending](/blog/one-page-agreement-before-you-build) covers it, and having it there means the topic is closed rather than pending.
What Not to Say
Disclosure goes wrong in two directions. Underselling it as an apology, and overselling it as the product. Both cost you the same thing, which is the client's sense that you are in control of your own process.
- Do not apologise. I should mention that I do use AI turns a neutral fact into a confession and invites them to treat it as one.
- Do not oversell it as magic. Promising that AI makes it near-instant sets a delivery expectation you will be held to when the unglamorous three quarters of the project arrive.
- Do not make the tool the product. Clients buy an outcome. A pitch built around your stack invites them to shop your stack, and there is always someone cheaper holding the same tools.
- Do not volunteer the whole workflow. Which model, which extensions, how your setup is configured. Nobody asked, and it converts a supplier relationship into an evaluation of your tooling.
- Do not imply nobody reviews the output. Even if you are moving quickly, the client needs to hear that a person checks the work, because that is the part they are actually paying to be sure of.
- Do not use it to justify a low price. Cheap because it is quick for me is an argument you will be held to on every future project with that client.
Does Disclosure Change What You Charge?
No, and if it does, the problem is your pricing model rather than your honesty. A price attached to a working outcome and to your accountability for it is unaffected by how quickly the work happens. A price attached to hours collapses the moment the hours shrink.
This is why builders who price hourly find disclosure so uncomfortable. They are being asked to explain why an outcome that takes them less time should cost the same, and inside an hourly frame there is no good answer. Inside an outcome frame the question does not arise, because the client is buying a result they cannot produce themselves at a price that is worth it to them. The full case is in [value-based pricing](/blog/value-based-pricing-stop-charging-hourly).
There is an upside worth naming. Speed is a benefit if you sell it as one. A client who needs something live before their busy season cares far more about weeks than about methods, and being able to say you will have it working in a fortnight is frequently worth more to them than a discount would be.
The One-Minute Version
If you take one thing from this: say it first, say it once, say it flat, and put it in the agreement.
- Deliver the Method Line early in the first call, after their problem and before your price.
- Three parts: what you use, what you do with it, who is accountable. Then stop talking.
- If they ask why they are paying you, answer with one specific decision from a past project that had nothing to do with typing.
- If they have a genuine restriction, ask what it requires instead of arguing, and be willing to walk.
- Put four lines in the written agreement covering method, ownership, data and your warranty.
- Do not move your price. The fee is for the outcome and the accountability, neither of which got smaller.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
Should I tell clients I use AI to build their project?
Yes, early in the first conversation, after they have described the problem and before price comes up. Volunteered information reads as method, while the same fact discovered later reads as something you concealed and puts every other part of the deal back in play. Say it in one flat sentence covering what you use, what you do with it, and who is accountable, then move on.
What if a client asks whether AI wrote the code?
Answer directly and without apology. Confirm the method, then move immediately to what you are responsible for: the architecture, the decisions, the testing and the fact that you are the one fixing it when something breaks. Denying it is the one genuinely damaging option, because it is a false statement about the service you are selling and it is discoverable.
Will clients pay less if they know I use AI?
Not if you price the outcome rather than the hours. The fee covers a working result and your accountability for it, and neither of those shrinks because the build moved faster. Builders who price hourly struggle here because they cannot explain why fewer hours should cost the same. Speed is also a benefit you can charge for when a client has a real deadline.
How do I answer then why am I paying you?
Because they are paying for the judgement about what to build, not the typing. Give one specific example from a past project: a feature you talked a client out of, an integration you refused because their system could not support it, a simpler approach that saved a month. A concrete instance settles the question far faster than a general argument about value.
Should AI use be mentioned in the contract?
Yes, in about four lines. State that the work is produced using AI-assisted development tooling and reviewed and tested by you, confirm ownership transfers on final payment, say what happens to their data and materials, and keep your warranty that the work functions as described. That last line reassures a cautious buyer more than anything else in the paragraph.
What if a client says no AI at all?
Ask what their obligation actually requires rather than arguing. Restrictions are often narrower than they first sound and may cover production data but not a greenfield project with synthetic records. If the answer really is no, decline cleanly and stay on good terms, because winning a project you cannot deliver within the client's constraints is not a win.
Last reviewed August 21, 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 →
