"Done" Is Not "Shipped": User Acceptance Testing for Founders Who Have to Sign Off

Your development partner writes “it’s done.” You reply “great, so it’s live?” Both of you are right, and that is the problem. User acceptance testing (UAT) is the step where those two meanings of done meet. Most founders have never been told what they are supposed to do in it. This guide covers what UAT is, how long it should take, what you actually test, and how you sign off. It ends with the four sentences that keep the invoice and the production release from colliding.

Key Takeaways

• User acceptance testing is the final check where the client, not the developer, confirms the software does the job. It is the moment “done” becomes “shipped”.
• Three parties mean three definitions of done. If the contract does not pick one, the invoice will.
• A written acceptance period, an acceptance rule with an end date, and release-after-payment take about four sentences. Poor software quality cost the US at least $2.41 trillion in 2022 (CISQ). The cheapest part of that bill is the sentences nobody wrote.

What is user acceptance testing, and who is it for?

User acceptance testing is the last validation stage before software goes live. Real users or the people paying for the product check it against business needs, not against the code. The ISTQB glossary defines acceptance testing as formal testing against user needs, requirements and business processes. Its purpose is “to enable the user, customers or other authorized entity to determine whether or not to accept” the system (ISTQB).

Notice who the definition puts in charge. On an agency project, the acceptor is you. The agency has already run its own quality assurance. UAT is your check that the thing they built is the thing you asked for.

What you check it against is a set of acceptance criteria. The UK Government Service Manual has the plainest definition. Acceptance criteria are “a list of outcomes that you use as a checklist to confirm that your service has done its job and is meeting that user need” (GOV.UK). If your spec has no such list, UAT becomes a matter of taste, and taste is where disputes start. Our software development contract guide covers where the criteria belong in the paperwork.

Why does “done” mean three different things?

Because three people own the word. The developer, the delivery team, and the client each have a legitimate definition, and each one triggers something different.

Software teams have a formal version of the first row. The Scrum Guide’s Definition of Done is “a formal description of the state of the Increment when it meets the quality measures required for the product” (Scrum Guide, 2020). It is a good tool. It also says nothing about the client, the invoice, or production.

We learned the gap the expensive way recently. A development was finished and sitting on staging, reviewed and working. We sent the invoice, because the work was done. The client was confused, because to them done meant live, and nothing in writing said which one we meant. Nobody was wrong. The contract had simply never chosen a definition. We fixed three things the same week: a fixed one-week test window for the client, a written rule for what counts as accepted, and production release after payment. The rest of this article is that fix, written down.

The same ambiguity is a cousin of scope creep. When done is undefined, every “one more thing” looks like part of the original job.

How long should UAT take, and what happens if you never finish it?

For an MVP-sized delivery, one calendar week of client testing is enough. The testing itself is rarely the risk. The calendar is. A window that never closes is a phase that never ends, and open-ended phases are where budgets go. McKinsey and the University of Oxford found large IT projects run 45% over budget and deliver 56% less value than predicted (McKinsey). PMI reports that 52% of projects experience scope creep (PMI).

Real contracts handle the calendar with two mechanisms. The first is a fixed window. A software development agreement filed with the SEC gives the customer seven days after delivery to test. After a corrected re-delivery, the acceptance process restarts (SEC EDGAR, 2017). The second is deemed acceptance: if the window ends with no written report of a blocking defect, the delivery counts as accepted.

Founders sometimes read deemed acceptance as a vendor trick. It protects you too. It forces the vendor to make testing easy. A client who cannot test in a week will say so. A vendor who wants the clock to run has every reason to hand over a clean build with clear instructions. It pairs naturally with the re-scoping gates we describe in fixed price versus time and materials. A phase ends when it is accepted, not when everyone is tired of it.

What should a founder actually test? The one-week UAT plan

Two things make the week short in our practice, and both happen before you see a staging link.

First, weekly demos. Our fixed-price builds run on fixed scope and a demo every week. By the time a delivery reaches formal acceptance, you have already seen each feature and reacted to it. The acceptance week confirms; it does not discover.

Second, an AI review step. Before a delivery goes out, our project manager cross-checks every commit against its ticket with an AI review and signs the result. Across roughly 200 tasks, over 90% of the findings were relevant, and rework dropped from three or four rounds to one or two. Ádám wrote up the method in how we check every commit against its ticket. The effect for you is that client-side testing finds outcome problems, not code problems.

Then the week itself.

You are testing outcomes, not code. Security, load, backups and monitoring were the agency’s job before UAT started, and they are what technical due diligence will look at later. Our MVP launch checklist lists the technical side if you want to know what should already be true.

Where do you test? Normally on a single staging environment that is frozen for the week, so the thing you tested on Monday is the thing you sign off on Friday. On integration projects, where your own team is testing our work against a larger system, we usually run a separate dev environment as well. Updates keep landing on dev, and staging stays stable under your testers until the window closes.

How do you sign off, and what goes in the sign-off?

A sign-off is a written confirmation that the delivery meets the agreed criteria and may go live. It names what was tested, which defects remain open and how they will be handled, and who is approving. That is the whole document. A one-paragraph email is enough if it contains four things:

• The delivery it refers to, by name and date.
• The word “accepted”.
• The cosmetic defects you are deferring, listed, so nobody later claims they were hidden.
• Your name, as the person authorized to accept.

Resist the urge to sign off “with conditions”. A conditional acceptance is a rejection with better manners, and it leaves the clock ambiguous. Either the blocking list is empty and you accept, or it is not and you report it.

The four sentences your contract needs

Everything above fits into four sentences. This is example wording, not legal advice, and your lawyer will want to adapt it to your jurisdiction.

Acceptance period. The Client has five business days from written delivery notice to test the deliverable against the acceptance criteria in the specification.

Acceptance rule. The deliverable is accepted when the Client confirms in writing, or when the period ends without a written report of a defect that prevents the deliverable from meeting the criteria.

Cure loop. Reported blocking defects are fixed and re-delivered; the period restarts only for the corrected items.

Release and payment. The accepted deliverable is invoiced on acceptance and released to production after payment, unless agreed otherwise in writing.

Each sentence prevents a specific argument. The first prevents “we were never given time.” The second prevents “we never said it was fine” from a client who went quiet. The third prevents a single cosmetic bug from restarting a full week. The fourth prevents the exact confusion we ran into: an invoice for something the client believed was not yet real.

The fourth sentence is also cheaper than it sounds. A production environment used to be a project in itself. Today, a developer’s own tooling can clone a staging setup into production in hours. The cost of doing it is low. The cost of leaving it undefined is the dispute.

The scale of what unresolved quality costs is not small. CISQ estimated the cost of poor software quality in the US at $2.41 trillion for 2022, with accumulated technical debt at roughly $1.52 trillion (CISQ, 2022). And “we’ll fix it in production” is not a plan. The 2025-26 World Quality Report surveyed over 2,000 senior executives in 22 countries. It found that 94% of organizations review production data, but nearly half struggle to turn it into action (Capgemini, Sogeti, OpenText, 2025). Acceptance is the last cheap moment to be precise.

What happens after acceptance?

Acceptance ends the build phase and starts two clocks. The warranty clock covers defects against the spec: things that were accepted and turn out not to work as specified. It does not cover changes of mind, which are new work and get scoped as such. And the support clock starts, which is where a software maintenance contract takes over from the build contract. If you ever end the relationship, acceptance is also the mechanism that makes a clean handover possible; we cover that in how to switch development agencies.

If you are about to receive a delivery and are not sure what your contract says about any of this, book a call. We will read it with you, including the parts that are missing.

Frequently Asked Questions About User Acceptance Testing

What is UAT in software development?

User acceptance testing is the final check before software goes live, performed by the people who will use or pay for it rather than by the developers. It tests the product against business needs and agreed acceptance criteria. On an agency project, the client is the acceptor: the agency's quality assurance checks the code, UAT checks the outcome.

How long should user acceptance testing take?

For an MVP-sized delivery, one calendar week of client testing is enough, provided the client has seen the features in weekly demos along the way. Regulated products and multi-role systems take longer. Whatever the length, the window is written into the contract, because an open-ended acceptance phase is where budgets and timelines drift.

What is the difference between QA testing and user acceptance testing?

QA testing checks the code against the specification and is the agency's job: unit tests, integration tests, security, load, and review. User acceptance testing checks the product against the business need and is the client's job. QA asks "did we build it right?" UAT asks "did we build the right thing, and does it do the job we are paying for?"

What happens if I never sign off on the software?

Most contracts include deemed acceptance: if the testing window ends without a written report of a blocking defect, the delivery counts as accepted. That protects both sides. The vendor cannot be held in limbo by silence. The client is guaranteed a clean build and a real testing window, because the vendor needs both for the clock to run.

Should I pay before the software is in production?

In the model we use, acceptance triggers the invoice and production release follows payment. The release itself is a small, reproducible step today, so tying it to payment costs the client nothing in time. What it prevents is the situation where money and a live product are both pending and each side believes the other moves first.

Conclusion

“Done” is a word with three owners. The developer’s done, the delivery team’s done, and your done are all legitimate, and only one of them starts the invoice. User acceptance testing is where your definition gets its turn, and four sentences in the contract make sure it is a turn rather than a fight. The acceptance step is not an agency protecting itself from a client. It is both sides protecting the project from the calendar. If your contract does not say when done becomes shipped, decide it now, in writing, while everyone is still on good terms.