Your development team just said: "It's ready for UAT." You said fine, poked around the system for an hour, couldn't find anything obviously broken and replied "looks good to me." Two weeks after go-live, a customer discovers they can't complete their order. Your ops team can't export the report they need. An edge case nobody tested is now a live production incident.
This is what UAT looks like when it goes wrong — and it goes wrong in exactly this way on most projects. Not because the developer was careless, but because the client didn't know what UAT actually requires of them.
What is UAT, and why is it your responsibility?
User acceptance testing is the final phase before a software system goes live. Its purpose: verify that the software does what your business needs it to do, in the way real users will use it.
That's your job, not the developer's. A developer tests whether the code works. UAT tests whether the solution works for your business. Only you and your team know what that means — which processes matter, which edge cases exist in your data, which combinations of inputs a real customer might try.
The most common misconception I encounter: clients treat UAT as a formality, a final quality check the developer runs. It isn't. If your developer is doing UAT for you, they're answering the wrong question. They can confirm the system behaves as specified. They cannot confirm it fits your business — because they don't run your business.
When in the project does UAT happen?
A well-run project has feedback built in throughout. Working software should be visible from week two onwards in sprint demos, so UAT is never the first time you've seen the system. If you're reviewing a system in UAT that you've never seen before, something has already gone wrong in the process — that's the kind of late discovery that causes the painful overruns covered in keeping a software project in scope.
What UAT specifically tests:
- Completeness — Does the system do everything in the agreed scope? Every user story, every workflow, every edge case in the spec.
- Business logic — Do the calculations, rules and automations produce the right output with real data from your business?
- Integrations — Do the connections to other systems (your ERP, payment provider, email tool) work in the production environment, not just in development?
- Permissions — Can a user see only what they're supposed to see? Can a manager do what a regular user cannot?
- Performance — Does it respond acceptably when multiple people use it simultaneously?
How to run UAT properly
Use test scripts, not free exploration. "I'll poke around and see if anything breaks" is not UAT. Before you start, write down the specific scenarios you need to test:
- A new customer registers and places their first order
- A manager approves a purchase request over €5,000
- A user tries to access a report they don't have permission to see
- Month-end export produces the correct totals
These scenarios should come directly from your original requirements. If the project had a good discovery phase with user stories, those user stories are your test scripts.
Test with real data, not demo data. Demo data is clean. Your data isn't. Test with real customer names, real product codes, real edge cases from your business — the articles with unusual characters in the name, the customer with an address in Belgium, the order that falls exactly on a pricing tier boundary. This is where most post-launch incidents originate: a scenario the developer never thought to test because they didn't know your data.
Document every issue you find. When something doesn't work as expected, record it with enough detail that the developer can reproduce it:
- What you were doing, step by step
- What you expected to happen
- What actually happened
- A screenshot where possible
"The report is wrong" is not a bug report. "When I filter by date range 1–28 February and export to CSV, the totals column shows €0 for all rows" is a bug report.
Separate bugs from scope changes. During UAT you'll inevitably think: "This works as specified, but actually we need it to work differently." That's valuable feedback — but it's not a bug. It's a scope change, and it should be treated as one, with an agreed cost and timeline adjustment. The clearer this distinction, the smoother the go-live.
Test in the right environment. UAT should happen in a staging environment that mirrors production — same hosting, same third-party connections, same data volumes. Testing on a developer's laptop or with fake integrations doesn't count.
The UAT sign-off checklist
Before formally accepting the software, verify:
- Every user story in the agreed scope has been tested and passed
- Tests ran with real or realistic production data
- All integrations with external systems have been verified in the staging environment
- All users who need access have tested their own workflows and permissions
- Critical bugs are fixed; minor cosmetic issues are logged and scheduled for v2
- You have received the documentation: user manual, admin guide, deployment instructions
- You have access to the production environment, monitoring tools and code repository
That last point — access to your own code and infrastructure — is not strictly a UAT item, but it's the right moment to confirm it. Don't accept a system you don't hold the keys to.
What to do when UAT reveals significant problems
Finding issues in UAT is not a failure — it's exactly the point. A project with thorough UAT catches problems before real customers hit them. The cost of fixing a bug in UAT is a fraction of the cost of fixing it in production: no customer impact, no urgent incident response, no damaged reputation.
If UAT reveals that large parts of the system don't meet requirements, that's a different conversation. It means either the requirements weren't clear enough earlier, or the developer's work didn't match what was agreed. Either way, the fix happens before go-live — and who bears the cost depends on where the gap originated.
This is why a solid requirements document and a formal scope agreement matter: when you get to UAT and something is wrong, you need an objective record of what was agreed, not a memory contest. This connects directly back to investing in discovery — the time you spend defining requirements precisely at the start is what gives you leverage at acceptance time.
What does UAT cost?
UAT itself isn't a line item on a development invoice — it's the client's time. For a mid-sized business application (€20,000–€60,000 build), expect to invest:
- Preparing test scripts: 4–8 hours, shared between project owner and key users
- Running the tests: 8–20 hours, depending on scope — spread across the team, not concentrated on one person
- Documenting and reviewing findings: 2–4 hours
Total: roughly €2,000–€5,000 in internal labor at a typical loaded hourly rate. That's the cost of protecting a €40,000 investment. The alternative — accepting software that doesn't work and discovering it in production — costs far more in emergency fixes, lost orders and your team's credibility.
Ready to get this right?
If you're commissioning custom software and want help structuring your UAT — test script templates, a sign-off checklist tuned to your project, or just a conversation about what to look for — get in touch. It's a short conversation that can prevent weeks of post-launch pain.