User acceptance testing: the non-technical founder’s guide
How to decide whether the software your vendor built is actually done, what to test when you can’t read the code, and how to define “done” before the first line gets written.
A founder we work with once forwarded us a one-line email from his developer: “All features complete, ready for launch.” He’d paid for a customer portal over four months. He asked us a simple question before he wired the final invoice: how do I know that’s true?
He couldn’t read the code. He couldn’t tell a passing test suite from a screenshot of one. What he had was a feeling that “ready for launch” was the developer’s opinion, not a fact he could check. That gap, between someone telling you the work is done and you knowing it’s done, is exactly the gap user acceptance testing closes.
User acceptance testing (UAT) is the final check before software goes live, where real users confirm the product does what the business actually needs in real-world conditions. It’s not about finding bugs in the code. It’s about answering one question: does this thing do the job we paid for? For a non-technical founder, UAT is the single most important hour you’ll spend on a build, because it’s the one part of the process you’re qualified to run without knowing how to program.
What user acceptance testing actually is
Most definitions you’ll find online are written for QA engineers, so they bury the part that matters to you. Strip it down and UAT is this: a person who represents the business uses the software the way a real customer or employee would, against a written list of things it’s supposed to do, and signs off only when each one works.
The “user” in user acceptance testing is the point. The software industry’s own standards body, the ISTQB, defines acceptance testing as testing that establishes whether to accept a system, which is a polite way of saying it exists to answer a yes-or-no business question. Earlier testing checks whether the code behaves the way the engineers intended. UAT checks whether what the engineers intended is what the business needed. Those are different questions, and the second one is yours. A developer can build a flawless checkout flow that charges the wrong tax rate for your market. The code is correct. The product is wrong. Only someone who understands the business catches that, and that someone is usually you.
This is why UAT is the founder’s job, not the vendor’s. When you outsource the build to a software house or a freelancer, you can outsource the engineering, the architecture, even the project management. You cannot outsource the judgment of whether the result serves your business. That stays with the person who owns the business outcome.
UAT versus QA: who tests what
Founders mix these up constantly, and the confusion costs them money. Here’s the clean split.
Quality assurance (QA) is the developer’s responsibility. It’s internal testing, run by people on the build team, checking that the software works as specified: the buttons click, the data saves, the API returns what it should, nothing crashes under load. Good vendors do this before they ever show you the product. If a screen throws an error the moment you open it, QA failed, and that’s on them.
User acceptance testing is your responsibility. It happens after QA passes, and it checks something QA can’t: whether “works as specified” matches “works for the business.” A vendor’s QA can confirm the invoice generator produces a PDF. Only you can confirm the PDF has your company’s legal name, the right payment terms, and the tax breakdown your accountant needs.
The practical rule we give founders: if a failure is “the software is broken,” that’s QA, send it back without ceremony. If a failure is “the software works but it’s not what we need,” that’s UAT, and it’s a conversation about scope, not a bug report. Knowing which bucket a problem falls into tells you whether you’re owed a free fix or whether you’re asking for new work. We wrote more about how scope quietly expands in our piece on feature creep, and UAT is where that tension comes to a head.
The mistake that makes UAT a fight
Here’s the trap. Most non-technical founders first hear the words “user acceptance testing” at the end of the project, when the vendor says “we’re ready for your sign-off.” By then it’s too late to do it well, because UAT has no meaning without acceptance criteria, and acceptance criteria have to exist before the build starts.
Acceptance criteria are the written, specific, testable conditions that define “done” for each feature. Not “build a login system.” Instead: “a user can sign up with email and password, receives a confirmation email within two minutes, can reset a forgotten password, and is locked out after five failed attempts.” That’s something you can test. “A login system” is something you can argue about.
The reason this matters so much for founders who didn’t write the spec themselves: if “done” was never defined in writing, then at the end of the project “done” becomes whatever the vendor says it is, and you have no standing to disagree. We’ve watched founders lose this argument in real time. The developer says the feature is complete. The founder feels it isn’t. Neither can point to a document. The founder pays, because the alternative is a fight with the person holding their codebase.
Define the criteria up front and the dynamic flips. Now “done” is a checklist both sides agreed to, and UAT is just walking the checklist. This is why acceptance criteria belong in two documents before anyone writes code: your software requirements document, where each feature gets its testable conditions, and your software development contract, where acceptance is tied to final payment. If your contract releases the last payment on “delivery” rather than “acceptance,” fix that before you sign. The word does a lot of work.
A UAT playbook you can run without writing code
You don’t need to know how software is built to run a rigorous acceptance test. You need to be organized and a little stubborn. Here’s the sequence we hand founders.
1. Test against the criteria, not your mood. Open the acceptance criteria you wrote earlier. Go feature by feature, condition by condition. For each one, the answer is binary: it does this, or it doesn’t. Resist the urge to test “how it feels.” Feelings are real but they’re a separate conversation; right now you’re checking facts against a list.
2. Use real data and real scenarios. This is where founders find the problems that matter. Don’t test the invoice tool with “Test Company” and a $1.00 charge. Run your actual largest client’s real numbers through it. Run the edge case you know is messy: the refund, the partial payment, the customer in a different state. A concrete example from a build we reviewed: the software handled new subscriptions perfectly and broke completely on cancellations, because nobody tested a cancellation. The criteria said “manage subscriptions.” Cancellation is managing a subscription. It shipped broken because UAT only tested the happy path.
3. Test on the devices your users actually use. If half your customers are on phones, test on a phone, not just the laptop the developer demoed on. “Works on desktop” is not “works.”
4. Write down every failure precisely. “The thing is buggy” helps no one. “When I click Submit on the contact form with a Gmail address, nothing happens, and the page doesn’t show an error” is a report a developer can act on the same day. Specificity is the difference between a fix this week and a back-and-forth that takes three.
5. Separate “broken” from “not what I wanted.” Sort every failure into the two buckets from earlier. Broken goes back as a defect, fixed at no cost. “Not what I wanted but matches the criteria” is a change request, which means new scope and possibly new money. Being honest about which is which keeps the relationship with your vendor from turning adversarial.
6. Sign off in writing, criterion by criterion. When a feature passes, record it. When the full list passes, that’s your acceptance, and that’s the trigger for the final payment your contract should be tied to. Don’t sign off on the whole thing in one email to get it over with. The checklist is your leverage and your record.
Run those six steps and you’ve done something most founders never do: you’ve replaced “I think it’s fine” with “here is what I verified.” That’s worth more than any technical knowledge you don’t have.
When UAT tells you something is wrong
Sometimes the test fails and the vendor pushes back. They’ll say the failing item wasn’t in scope, or that it’s an edge case, or that fixing it is extra. Occasionally they’re right. Often the disagreement is exactly why you wrote criteria in advance, so go back to the document and see what it says. If the criteria covered it, it’s a defect. If they didn’t, you learned something about your own spec, and now you’re negotiating change, not litigating opinion.
If UAT surfaces problems deep enough that you start doubting the whole build, that’s a different and more serious signal. A single broken feature is a fix. A pattern of features that technically run but consistently miss the business need usually means the spec and the builder were never really aligned, and no amount of acceptance testing patches that. That’s the moment to bring in an independent read of the codebase before you pour more money in. We covered how to do that in our guide to technical due diligence.
The healthy version of this relationship isn’t a vendor who passes every test on the first try. It’s a vendor who built their QA seriously enough that your UAT finds business-fit gaps, not crashes, and who treats your checklist as the contract it is. The good ones want the criteria up front as much as you should. It protects them too.
Frequently asked questions
What is user acceptance testing in simple terms?
It’s the final check, run by someone who represents the business, confirming that finished software does what the company actually needs before it goes live. It tests fitness for purpose, not code quality.
What is the difference between QA and UAT?
QA is the build team confirming the software works as specified. UAT is you confirming the specification was right for the business. QA catches “it’s broken.” UAT catches “it works but it’s wrong.”
What is an example of user acceptance testing?
Running your real largest customer’s actual numbers through a new invoicing tool, including a refund and a partial payment, and confirming each invoice shows the correct legal name, payment terms, and tax. If every condition on your written list passes, the feature is accepted.
Who should run UAT in a startup?
The person who owns the business outcome, usually the founder or whoever wrote the requirements, possibly with one or two real users. It should not be run by the vendor who built the product; that defeats the purpose.
How much do UAT testers make?
This question comes from people researching QA careers, not founders buying software. For your purposes, UAT isn’t a salaried role on a small build; it’s a responsibility you hold as the buyer. On larger products, dedicated testers exist, but the business sign-off still belongs to the business.
When should acceptance criteria be written?
Before the build starts, inside your requirements document, and referenced in your contract. Criteria written after delivery are nearly worthless, because by then “done” is whatever the vendor says it is.