How to Offboard a Claude Code Client So They Come Back and Send You Others
- The offboarding conversation is not the end of the client relationship - it is the beginning of the referral relationship. How you close a project determines whether the client returns for the next one and sends their network to you.
- A clean offboarding has four parts: a handoff document that explains how the build works, a walkthrough session, a clear answer to what happens if something breaks, and a testimonial or referral request while the result is fresh.
- The best time to ask for a referral is immediately after the client expresses satisfaction - not three weeks later in a follow-up email. Build the ask into the closing conversation so it happens at the highest point of goodwill.
Why most builders skip offboarding and what it costs them
The typical project end looks like this: you deliver the final build, the client says it looks great, you exchange pleasantries, and you both move on. No structured handoff, no walkthrough, no plan for what happens if something breaks two weeks later.
The cost is invisible in the moment but real over time. A client who does not fully understand what they now have cannot describe it to anyone else. A client who does not know what to do when something breaks becomes frustrated when it eventually does. A client who was not asked for a referral does not think to give one - not because they would have said no, but because they were never prompted.
The handoff document - 15 minutes to write, permanent value
The handoff document is a single page that explains the build to a non-technical user. It is not developer documentation. It is a plain-language owner's manual that makes the client feel secure in what they have.
- What the build does: one sentence. 'This tool takes the data from your weekly sales export and produces the summary report in the format you previously built manually.'
- How to use it: step-by-step, written for someone who has never seen the tool before. Number every step. Include screenshots if the interface has steps that might confuse.
- What to do if something breaks: a first-response checklist before they contact you. 'If the report is not generating, check that the input file is in the /exports folder and named correctly. If that is correct and it still does not work, contact me at [email].'
- How to reach you for the next build: a one-line invitation. 'For the next project or any question about this one, reach me at [email/link].'
The client may never refer to this document after the first week. That is fine. The act of receiving it communicates that you are thorough and that you care about what happens after you are no longer in the room. That is the impression that generates referrals.
The closing conversation
For a build of any real complexity, a 20 to 30 minute closing call is worth scheduling. For smaller builds, a screen recording or a structured voice note covers the same ground without requiring a calendar slot from the client.
The structure of the closing conversation: walk through what they now have, explain how to use the two or three things they will touch most often, confirm they know what to do if something goes wrong, and then ask two questions.
- 'Is there anything that still feels unclear or that you would want adjusted before we close out?' This surfaces small fixes while it is still easy to make them - and prevents a vague dissatisfaction from festering.
- 'Would you be open to leaving a short testimonial? Even one or two sentences about what changed for your team would be genuinely helpful - I would use it on my site.'
The referral ask - how to do it without being awkward
The awkwardness most builders feel about asking for referrals comes from asking in the wrong moment. A referral ask three weeks after a project closes feels transactional. The same ask in the moment the client says 'this is great' feels completely natural.
The right response to a client expressing satisfaction: 'I am really glad it landed well. If you know anyone else running into the same kind of problem - [name the problem you solved] - I would love an introduction. Referrals are how most of my best projects start.' One sentence. No over-explaining.
If they bring someone to you: send a thank-you the day the new project starts. A short message saying 'the project with [name they referred] just kicked off, thank you for the introduction' maintains the referral loop for every future project.
Setting up the return engagement
The close of one project is the natural opener for the next conversation. You have just spent time understanding how this client thinks, what they need, and what their constraints are. Use that context to plant one specific idea before you sign off.
'What you have now handles [the problem you solved]. If you ever want to extend it to [the natural next step], that would be a straightforward build. Just let me know when that is on the radar.' One sentence. No pitch, no pressure. You are planting a specific idea that will surface when they are ready - and because it came from the person who built the original tool, the threshold for acting on it is much lower.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What if I delivered something the client is not fully happy with?
Surface it directly in the closing conversation with the first question: 'Is there anything that still feels unclear or that you would want adjusted?' This gives the client permission to raise a concern without feeling like they are complaining. Most small dissatisfactions dissolve when addressed directly. For anything substantive, offer one specific fix with a clear scope for what that fix covers.
Should I offer a warranty period after a project?
A short warranty - 14 or 30 days where you fix genuine bugs at no additional charge - is reasonable and reassuring. The key is defining clearly what counts as a bug versus a scope change. 'The build breaks unexpectedly' is a bug. 'I want to add a new feature' is not. Put this in writing before the project starts, but reinforce it at close so the client knows what to expect.
How do I handle a client who keeps adding requests as the project closes?
Name it directly: 'I want to make sure this build ships cleanly at the scope we agreed. For anything beyond that, I am happy to scope a follow-on project.' The pattern of expanding requests at close usually comes from clients who do not feel fully confident in what they have - a thorough offboarding reduces this because the client feels secure enough to let the project close.
What should the handoff document include for a very technical build?
Two versions: one plain-language version for the business user, and one technical reference for whoever will maintain it. The business version explains what it does and how to use it. The technical version documents the architecture, the environment variables, the dependencies, and how to update or extend it. Deliver both, but walk the client through the business version - that is the one that matters for day-to-day use.
Last reviewed August 2, 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 →
