UAT Is a Weapon for Vendors to Make Money

UAT — User Acceptance Testing — sounds like the safest thing a client can ask for. You wrote the spec with the vendor. You signed the document. You sit down at the end of the build, click through every screen, and confirm that what you asked for is what you got. The vendor delivers. You sign. The relationship ends clean. That's the brochure.

The reality, in custom software, is the opposite. UAT is the moment the bill starts climbing. And the part that hurts is this: it climbs legally, with your signature on every invoice, because you asked for the gate that lets the vendor charge you.

What UAT pretends to be

The official story goes like this. A custom software project has a scope document. The scope document describes features, screens, flows, and behaviours. UAT is the moment, near the end of the build, where the client tests those features against the document. If a feature behaves as specified, it passes. If it doesn't, the vendor fixes it before sign-off. Once everything passes, the client signs the UAT form and the project closes.

Sounds bulletproof. The scope is locked. The features are mutually agreed. The sign-off is the client's own pen on the client's own form. Nobody can rip the client off, because the client is the one approving every line.

That story is true. It's also exactly what makes UAT a perfect weapon, because in custom software the scope document was always a guess.

What UAT actually is in custom software

Here is the part nobody says out loud at the kick-off meeting. In custom software development, nobody has built this exact system before. Not the client. Not the vendor. Not the consultant who wrote the scope. Everyone in the room is describing software that does not yet exist, using words, in a document, on a Tuesday afternoon.

The scope document is two parties guessing in the same direction. The features in it are imagined features. The screens in it are imagined screens. The workflows in it are how someone thinks the work should flow, before anyone has actually clicked through it.

UAT is the first time anyone — including the vendor — sees what that guess looks like running. And the moment a real human clicks a real button on a real screen with real data, the guess collapses. The dropdown that made sense in the spec turns out to need a search box. The "edit after submission" rule that nobody discussed turns out to be load-bearing for half the workflow. The report that read fine in the document looks like nonsense on a Monday morning.

How a CR is born during UAT

Watch a UAT session run. The client sits down at the demo machine. The first feature loads. They click around. Then a perfectly reasonable sentence comes out of their mouth:

"Wait — can the dropdown also filter by region?"

"Can users edit their submission after they've sent it?"

"Why does the report look like that?"

Three sentences. Three small, sensible, obvious requests. None of them are unreasonable. None of them are scope creep in the manipulative sense — the client genuinely needs all three for the system to be useful on day one.

Here is where most clients get a comforting surprise. The vendor doesn't push back. They nod, take notes, and at the next demo two of those three things are quietly fixed — no CR raised, no invoice, no awkward conversation. "Part of the build," they say. "Don't worry about it." The client breathes out. This vendor is reasonable. This vendor cares. We picked the right partner.

That feeling — the one that whispers "see, they're flexible, we can trust them" — is the entire point of the exercise. The vendor's job during UAT is not to bill you. The vendor's job during UAT is to get the form signed. Every small tweak absorbed "for free" is a deposit toward that signature.

The bigger items do still come back as CRs, of course. The dropdown that turns into a full search-and-sort component: RM 1,800. The post-submission edit that needs an audit trail: RM 4,200. The report that has to be redesigned from scratch: RM 6,500. Each one quoted calmly, signed without much fuss, folded into the project total — because relative to all the things the vendor fixed for free, these still feel fair. Still feels like you're getting a good deal.

You're not getting a good deal. You're being prepared for the next twelve months.

And the real CRs only start after UAT

Here is the part that should keep you up at night: UAT only ever catches the surface. The dropdown filters, the post-submission edits, the report layouts — those are the obvious gaps, surfaced in a controlled room with a vendor sitting next to you and a notepad. Even with all the CRs raised in that room, the bill is still in its early innings.

The real change requests start the week after sign-off. You go live. Twenty, fifty, two hundred staff start using the system every day, for real work, with real customers, against real deadlines. And every single day, somebody hits something the UAT never tested.

None of these are theoretical. They are what every live custom system produces in its first six months — because reality is bigger than any specification, no matter how diligent the meeting was. UAT was the warm-up. Daily operations are where the real changes appear, and they appear faster than the vendor can invoice them.

And here is the trap closing tighter: at this stage you have less negotiating power than during UAT, not more. The system is live. Your staff are using it. You cannot pause operations to "renegotiate scope." You need the change in two weeks, not two months. The vendor knows this. The CR price reflects it.

The legal armour

This is what makes UAT so structurally elegant for the vendor. Every step of the bill is the client's own decision. The client asked for UAT. The client agreed to the scope document. The client approved every feature inside that document. The CR is on a letterhead, with a price, with a description, signed by the client themselves.

There is no argument to be had. The client cannot say "you didn't deliver." The vendor did deliver — exactly what the document said. The client cannot say "this was always part of the brief." The brief is sitting on the table, and the dropdown filter isn't in it. The client cannot even say "you should have known we'd need this." The vendor will reply, kindly, that custom software is built to spec, and spec changes are change requests.

Every word of that reply is technically correct. That's why it works.

Why this is structurally inevitable

It would be comforting to think this is a few bad vendors behaving cynically. It isn't. It's the natural shape of fixed-scope contracts applied to software that has never existed before.

A fixed-scope contract for a building works because someone has built that building, or one like it, ten thousand times. The plumbing is known. The wiring is known. The load-bearing calculations are known. The contractor can quote you a price and absorb most of the variance, because the variance is small.

A fixed-scope contract for custom software is the opposite. The "building" has never been built. The plumbing is being invented as the walls go up. The vendor who quotes a tight fixed price for novel software is doing one of two things: (1) losing money, or (2) pricing the gap as CRs. Almost all of them are doing the second. The original quote is the loss-leader. CRs are the margin.

We've written about the same dynamic from other angles — why hidden CR fees are killing IT projects, how CRs quietly inflate budgets, why your vendor isn't your partner. UAT is the specific mechanism that turns the dynamic into invoices.

What clients should actually look for

The question to ask a vendor is not "will you give me a fixed price?" Every vendor will say yes. The question to ask is "what happens when reality disagrees with the spec — and how is that priced?"

The honest answers sound boring. The dishonest answers sound bulletproof.

None of this means UAT itself is bad. Acceptance testing is genuinely useful when the system is well-understood and the spec is genuinely stable — buying a piece of off-the-shelf software, integrating a known API, replacing one ERP module with another. In those contexts, the document can describe reality, and UAT does what the brochure says.

But the moment you're paying somebody to build something nobody has built before, a single UAT gate at the end is the wrong tool. What you actually need is a vendor who is in the build with you, week after week, surfacing the disagreements between spec and reality as they appear — not stockpiling them for the invoice.

The honest version

UAT isn't evil. It's just a tool that was designed for one kind of software (well-understood, repeatable, off-the-shelf) and has been quietly repurposed for a kind it was never built for (custom, novel, one-of-a-kind). In that second context, it stops being protection and starts being a tollbooth — one the client themselves volunteered to install on the road they're driving down.

The vendors who use it as a weapon are not lying to you. Every CR is real. Every signature is yours. Every invoice is for work that genuinely needed to happen. The trap isn't fraud. The trap is the structure: a fixed scope for unfixable software, with a checkpoint at the end where every disagreement between the document and reality becomes a billable line item.