When a Client Wants the Code Before Final Payment (Protect the Handoff Without Losing Trust)
- A client asking for the code before the final payment is usually not trying to skip the bill. They want proof the build is real and complete before they hand over the last of the money. Your job is to give them that proof without giving away your only leverage.
- Use the Profit Room's Proof Before Handoff method: let the client see and test the finished build in a staging environment or a live walkthrough, sign off on it in writing, then transfer the repository, accounts, and credentials the same day the final payment clears.
- Prevent it next time. Put the handoff order in your agreement before you start: ownership and full access transfer on final payment, and the client gets a testing window before that payment is due. Then the request is already answered.
The Short Answer
When a client wants the code before final payment, offer them everything they need to trust the build, except the transfer itself. Give them a working version they can click through, a walkthrough of how it works, and time to test it. Ask for written sign-off, send the final invoice, and hand over the repository, admin accounts, and credentials as soon as the payment lands. Say it plainly and kindly: the build is theirs the moment it is paid for, and you want them to be completely sure it works before they pay.
That is the Proof Before Handoff method. It works because it answers the real worry behind the request - 'what if I pay and it is not finished?' - without creating the opposite worry for you - 'what if I hand it over and the invoice never gets paid?' Both fears are reasonable. A clear order of steps removes them both.
Why Clients Ask for the Code First
Work out which of these is behind the request before you reply. The answer shapes the tone.
- They want proof it is finished. They cannot read code, so having it in hand feels like the only way to be sure. A demo and a test window usually solve this completely.
- Someone else needs to look at it. A partner, an investor, or a developer they trust wants to review the build. Read-only access to the repository for a review is a different thing from a full transfer. [When a client hires a developer to review your code](/blog/client-hires-a-developer-to-review-your-code) covers that conversation.
- They were burned before. A previous freelancer disappeared or held a project hostage. Reassurance and a clear handoff date matter more here than any policy.
- Their finance process requires it. Some companies only release payment once a delivery is confirmed. Written sign-off on a tested build usually satisfies this.
- They are hoping to delay paying. Rare, but real. If the request comes with vague complaints and no specific defects, treat it carefully and stick to the order of steps.
Most requests are the first four. Respond as if the client is acting in good faith, and let the process protect you in case they are not.
Run Proof Before Handoff
Reply the same day, in writing. Then follow these steps in order.
- Show the finished build. Give the client a staging link or a test version they can use with real-looking data, or walk them through it on a call. Let them click every button they care about.
- Give them a testing window. Agree on a few days for them to try it and send any issues as a written list. Fix real defects. Anything new goes through a [change order](/blog/change-order-template-for-a-claude-code-project).
- Get written sign-off. A short email confirming the build matches what was agreed is enough. [Getting a client to sign off on a build](/blog/get-a-client-to-sign-off-on-a-build) covers how to ask without it feeling formal.
- Send the final invoice. Reference the sign-off and the handoff date in the invoice note so the next step is obvious.
- Transfer everything when it clears. Move the repository to their account, hand over admin access and credentials, and send the handoff documentation the same day. Speed here builds the trust that gets you referrals.
If the Client Pushes Back
Sometimes a client insists on having the code first. You have a few reasonable options, depending on how much you trust them and how much is still owed.
| Option | When it fits | What to watch |
|---|---|---|
| Read-only access for review | They need a developer or partner to check the build | Keep it read-only and keep ownership with you until payment |
| Split the final payment | A large final payment is the sticking point | Release part of the handoff with each part of the payment, in writing |
| Escrow or a platform with payment protection | Neither side has worked together before | Fees and timelines, which you agree on up front |
| Hand it over anyway | A long-standing client with a clean payment history | Only do it if you could absorb not being paid |
Options when a client insists on the code before paying
Whatever you choose, put it in writing before anything moves. If the final invoice later goes unpaid, [how to handle a client who pays late](/blog/how-to-handle-a-client-who-pays-late) and [when a client disputes an invoice](/blog/client-disputes-an-invoice) cover the next steps.
Set It Up So the Question Never Comes Up
The easiest version of this conversation is the one that happened before the project started. Add these to every project.
- Put the handoff order in your agreement. A line stating that ownership, the repository, and full access transfer on final payment, and that the client gets a testing window before final payment is due. [A one-page agreement before you build](/blog/one-page-agreement-before-you-build) shows where it fits.
- Use milestone payments. Smaller payments tied to milestones keep the final payment from being large enough to fight over. [Structuring client payments by milestone](/blog/structure-client-payments-milestones) lays out a simple split.
- Take a deposit. Work does not start until the first payment clears. [The deposit conversation](/blog/the-deposit-conversation-get-paid-upfront) covers how to ask.
- Demo early and often. A client who has seen the build working at every milestone does not need the code to believe it exists.
- Have the handoff ready. A clean handoff guide, documentation, and a [proper offboarding](/blog/how-to-offboard-a-claude-code-client) mean the transfer really can happen the same day, which makes your promise believable.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
Should I give a client the source code before they pay the final invoice?
Usually not the full transfer. Give them a working build to test, a walkthrough, and a testing window, get written sign-off, then transfer the repository and access as soon as the final payment clears. That protects both sides.
What if the client needs a developer to check the code before paying?
Give the reviewer read-only access to the repository for the review. That lets the client confirm the work is real and sound without transferring ownership before payment.
Is it okay to withhold a client's website or data until they pay?
No. A client's own data, domain, and existing business accounts stay theirs. What you hold until payment is the transfer of the new work you built. Spell out ownership in your agreement before the project starts.
How do I stop clients from asking for the code before paying?
Put the handoff order in your agreement, use milestone payments so the final payment is small, take a deposit, demo the build at every milestone, and have your handoff guide ready so transfer can happen the same day payment clears.
What if the client still refuses to pay after I hand over the code?
Follow your late payment process in writing, reference the signed agreement and the client's sign-off, and escalate step by step. If a large amount is at stake, get advice from a lawyer where you work.
Last reviewed October 14, 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 →