How to Get a Client to Sign Off on a Build (The Acceptance Gate)
- Sign-off fails because builders ask for a verdict instead of an action. A non-technical client cannot judge a build, but they can complete a numbered list of tasks and tell you which ones worked.
- Write the acceptance criteria into the scope before you write code, in outcome language the client themselves used. Criteria invented at delivery time are a negotiation, not a gate.
- Attach a dated window and an explicit consequence. A test script with a deadline and a stated default converts far more clients into written acceptance than an open-ended request for feedback.
What Client Sign-Off Actually Is
Client sign-off is a written statement that the build does what you both agreed it would do. It is not praise, it is not a thumbs up in a chat window, and it is not the client saying the design looks great. It is a specific, dated confirmation that named criteria were met, which is what turns finished work into work you can invoice and close.
The distinction matters because everything downstream depends on it. Final payment usually hangs on it. The line between a bug you fix for free and a change you charge for is drawn at it. The moment your support window starts is measured from it. Without written acceptance you are holding a project that is technically done and commercially open, which is the worst position in client work.
Most builders never get it because they ask the wrong question. Sending a staging link and asking what do you think puts a non-technical client in the position of judging engineering, which they cannot do and know they cannot do. So they either say something polite and vague, or they say nothing at all until a deadline forces them, and by then the details of what was agreed have gone soft in everybody's memory.
The Acceptance Gate: Five Parts
The Profit Room calls this routine the Acceptance Gate. It has five parts, and it only works when they run in order, because each one removes an excuse the next one would otherwise run into.
| Part | When it happens | The failure it prevents |
|---|---|---|
| 1. Acceptance criteria | Written into the scope, before any code | Arguing at delivery about what done meant |
| 2. The test script | Sent with the build | A client who cannot tell you anything useful |
| 3. The window | Stated in the same message | A review that never starts |
| 4. The sign-off line | At the end of the script | A reply you cannot point to later |
| 5. The boundary | Immediately after acceptance | Free work disguised as finishing touches |
The five parts of the Acceptance Gate and the failure each one prevents
Every part is cheap. The criteria take twenty minutes at scoping. The test script takes half an hour to write and can be drafted from your own manual testing notes in the Claude Code desktop app while the build is fresh. The rest is one message. The return is that projects end on a date instead of trailing off.
Write the Acceptance Criteria Before You Write Code
Acceptance criteria are the short list of things that must be true for the build to count as delivered. Write them during scoping, in the client's own words, and put them in the agreement rather than in your notes.
Criteria written before the build are a shared standard. Criteria written after it are a proposal the client is free to reject, and they will, because at delivery time the client's ambitions have grown and yours have shrunk. Whoever writes the definition of done last loses the argument, so write it first.
- Phrase each one as an outcome the client can observe. A staff member uploads the spreadsheet and sees a summary in under a minute is testable. The importer is reliable is not.
- Keep the list short. Five to eight criteria covers almost any single build. A list of thirty is a list nobody reads and a review nobody finishes.
- Name the environment. Criteria are met on the machines and browsers the client actually uses, and you both should have agreed that list already.
- Include the one thing that must not break. Every project has a feature whose failure means the project failed, and it belongs in the criteria explicitly.
- Put the list in the agreement itself. It belongs next to the scope, which is covered in [the one-page agreement you sign before you build](/blog/one-page-agreement-before-you-build).
The Test Script: Give a Non-Technical Client Something to Do
The test script is a short numbered list of tasks the client performs themselves, each one mapped to an acceptance criterion, each one ending in a result they can compare against what you wrote. It is the single highest-leverage document in the whole handoff.
It works because it changes the request. You are no longer asking a non-technical person to evaluate software, which is intimidating and vague. You are asking them to do eight small things they already understand, in an order that happens to walk through the entire build. People complete tasks. People avoid judgements.
- Write each step as an instruction plus an expected result. Log in with the account we sent you, then confirm you land on the dashboard with your branch name at the top.
- Use the client's vocabulary, not the codebase's. If their team says job sheet, the script says job sheet, whatever the database table is called.
- Cover the criteria and nothing else. A script that wanders into features nobody agreed to invites requests for features nobody agreed to.
- Include one deliberate failure case. Try to submit the form with the date field empty and confirm you see a clear message. It proves the build handles the real world, and it is the step that most impresses a careful client.
- Finish with a single tick box per step and one line for anything unexpected. Structured feedback beats a paragraph of impressions every time.
Send it as a document they can fill in rather than a wall of text in an email. The physical act of ticking eight boxes is what produces a reply, and the completed script is a far better record than a chat thread when a question comes up two months later.
Set a Window and Say What Happens When It Closes
Give the review a start date, an end date, and a stated default. Five business days is enough for a small build and short enough that it stays on the client's desk. Then write, plainly, what happens if the window passes without a response.
The default is the part everybody leaves out, and it is the part that makes the window real. Without it, a deadline is a suggestion. With it, the client has a decision to make rather than an email to postpone. Keep the language matter of fact and never threatening: if we do not hear back by Friday the twelfth, we will treat the build as accepted and move to the support period, and anything that comes up after that is handled as maintenance.
Announce the window before delivery, not with it. Tell the client at the previous check-in that testing opens on a specific date and takes about an hour of their time. A review somebody has diarised gets done. A review that lands as a surprise on a Thursday afternoon does not. That habit lives naturally inside a regular update rhythm, which is why [the weekly client update prevents fires](/blog/weekly-client-update-prevents-fires).
The Sign-Off Message That Gets a Reply
Keep the delivery message to five short parts: what is ready, the link and credentials, the attached script, the window with its default, and one sentence on what happens next. Anything longer gets skimmed and the ask gets lost.
Put the request in the first two lines. Busy clients read the top of an email and decide whether to deal with it now. If the ask is in paragraph four, it does not exist. Lead with the action: the build is ready to test, here is the script, please work through it by Friday.
End with the sign-off line itself, written so a reply is one sentence of work. Reply with all steps passed, or list the step numbers that did not. That phrasing produces a usable answer from clients who would never write a considered review, and either answer moves the project forward. A list of failed steps is a punch list you can close in a day. Silence is not.
What to Do When the Client Will Not Test
Some clients will not test no matter how good the script is. The fix is almost never another reminder email. It is to remove the friction, shrink the ask, or move the review onto a call.
Diagnose before you chase. A client who has gone quiet is usually blocked by something specific rather than uninterested. The three common causes are that the person who has to test is not the person who hired you, that they cannot access the environment, or that they are avoiding a decision they know is attached to a payment.
- Wrong person: ask directly who will be using this day to day, then send the script to them and copy your buyer. Testing belongs with the user, sign-off belongs with the buyer.
- Access problem: get on a screen share and watch them log in. Half of all silent reviews are a password or a permission nobody wanted to admit was broken.
- Avoidance: book a thirty minute call and run the script together, live, with them driving. You will finish the whole review inside the call and get verbal acceptance on the spot, which you then confirm in writing.
- Genuine no capacity: shorten the script to the three criteria that carry the most risk and say so. A partial review you can name beats a full review that never happens.
If none of that lands, the stated default does its job and the build is accepted by the terms you wrote in advance. Send one short note confirming that has happened. This is also the point at which a wider pattern of non-response becomes worth reading properly, and [what to do when a client goes silent](/blog/what-to-do-when-a-client-goes-silent) covers that case in full.
What Sign-Off Does Not Cover
Acceptance does not mean the client stops asking for things. It means the things they ask for after it are classified differently. Draw that line in the same message that confirms sign-off, while everybody is happy, rather than three weeks later when it sounds defensive.
| Request type | What it is | How it is handled |
|---|---|---|
| Defect | An accepted criterion stops being true | Fixed by you inside the support window, no charge |
| Environment change | Something outside the build changed | Investigated, then quoted if the work is real |
| Change request | New behaviour nobody agreed | Quoted as new work, no exceptions |
| Preference | Same outcome, different taste | Small ones absorbed once, patterns quoted |
How requests are classified after acceptance
Say the support window length out loud and put a date on its end. Two to four weeks is normal for a small build. An open-ended promise to fix anything forever is how a profitable project turns into an unpaid subscription. If the client wants ongoing coverage after that, that is a retainer conversation and it is a good one to be having.
The requests that arrive in the first fortnight are worth handling generously and precisely, because they are the ones that shape whether the client rehires you. The mechanics of separating included revisions from new work are in [how to handle client revision requests](/blog/handle-client-revision-requests), and the specific case of a defect found later is in [a client found a bug after launch](/blog/client-finds-a-bug-after-launch).
How Sign-Off Connects to Getting Paid
Tie the final payment to acceptance, not to launch. Launch depends on the client's marketing calendar, their legal review, their domain registrar and the holiday nobody mentioned. Acceptance depends only on whether the build does what you agreed, which is the only thing you control.
Write it into the agreement in those words: the final instalment is due on acceptance, and acceptance is either a completed test script or the passing of the review window. That one sentence removes the most common reason final invoices sit unpaid, which is a project that is finished but has never been formally declared finished by anybody.
It also fixes the sequencing problem. A client who is invoiced before they have confirmed the work is met with a request that feels premature. A client who has just ticked eight boxes and written all steps passed is in exactly the right frame of mind to approve a payment. Structure the milestones so that moment is the trigger, which is the pattern described in [structuring client payments around milestones](/blog/structure-client-payments-milestones).
Mistakes That Turn Sign-Off Into a Second Project
Five mistakes account for nearly every acceptance that drags. All of them are avoidable in the message you have not sent yet.
- Asking for feedback instead of acceptance. Feedback is an invitation to redesign. Acceptance is a question with two answers.
- Delivering everything at once. A client seeing the whole build for the first time at sign-off will react to all of it, including the parts that were agreed months ago.
- No window. An open review has no reason to end, and unfinished projects quietly become free support relationships.
- Criteria written at delivery. If the definition of done arrives with the build, it is a negotiating position, and the client will negotiate.
- Silence on what comes next. Acceptance without a stated support window and change policy simply moves the ambiguity a week down the road.
Run the gate the same way on every project and the whole end of an engagement stops being a stressful improvisation. It becomes a document you send, a box the client ticks, and an invoice that gets paid on time, which is also the foundation for [delivering a build so clients come back](/blog/deliver-a-build-so-clients-come-back).
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
How do I get a client to sign off on a build?
Send a numbered test script instead of a link and a request for feedback. Each step should be an instruction the client can perform plus the result they should see, mapped to acceptance criteria you agreed before the build started. Attach a dated review window and state what happens if it passes without a reply. Finish with a one-line sign-off instruction so the client can accept in a single sentence.
What should acceptance criteria look like?
Five to eight observable outcomes written in the client's language, agreed at scoping and stored in the agreement rather than in your notes. Each one should describe something a person can do and see, such as a staff member uploading a file and receiving a summary. Avoid quality words like reliable or fast unless you attach a number both sides can measure the same way.
How long should the sign-off window be?
Five business days suits most small builds. It is long enough for a busy client to find an hour and short enough that the review does not slip off their desk. Announce the dates at the check-in before delivery so the time is already booked, and always state the default that applies if the window passes without a response.
What if the client never replies to the test script?
Diagnose the block before you send another reminder. Usually the tester is not the buyer, the environment is inaccessible, or the client is avoiding the payment attached to acceptance. Fix access on a screen share, send the script to the actual user while copying the buyer, or book a short call and run the script together with the client driving. If nothing lands, the stated default applies and you confirm that in writing.
Should final payment depend on sign-off or on launch?
On sign-off. Launch dates depend on the client's marketing calendar, legal review and vendors you do not control, so tying money to launch hands your cash flow to other people's schedules. Acceptance depends only on whether the build meets the agreed criteria. Write into the agreement that the final instalment is due on acceptance, and define acceptance as a completed test script or the passing of the review window.
Does sign-off mean I stop fixing things?
No. It changes how requests are classified. An accepted criterion that stops working is a defect and you fix it free inside a stated support window, typically two to four weeks. New behaviour nobody agreed is a change request and gets quoted. Say the support window length and its end date in the same message that confirms acceptance, while the tone is still warm.
Last reviewed August 22, 2026.
Co-founder of the Claude Code Profit Room. Went from shipping software to closing paying clients, and now teaches builders the selling half of the equation.
More from David Iya →
