UAT Is a Weapon for Vendors to Make Money

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

In custom software, it works the other way around. UAT is the moment the bill starts climbing. And what stings is that 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. That document lists the features, screens, flows, and behaviours. Near the end of the build, the client tests those features against the document. If a feature works the way the spec says, 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 solid. The scope is locked, both sides agreed on the features, and the sign-off is the client's own pen on the client's own form. Nobody can rip the client off, because the client approves every line.

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

What UAT actually is in custom software

Nobody says this out loud at the kick-off meeting. In custom software, 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 doesn't exist yet, using words, in a document, on a Tuesday afternoon.

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

UAT is the first time anyone, the vendor included, sees what that guess looks like when it's running. The moment a real person clicks a real button on a real screen with real data, the guess falls apart. 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 hold up 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 fair 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 requests. None of them are unreasonable, and none of them are sneaky scope creep. The client needs all three for the system to be useful on day one.

This is where most clients get a nice surprise. The vendor doesn't push back. They nod, take notes, and at the next demo two of those three things are already fixed. No CR raised, no invoice, no awkward chat. "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 whole point of the exercise. The vendor's job during UAT isn't to bill you. It's to get the form signed. Every small tweak done "for free" is a deposit toward that signature.

The bigger items still come back as CRs, of course. The dropdown that turns into a full search-and-sort tool: 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, and folded into the project total. Next to all the things the vendor fixed for free, these still feel fair. It 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

And UAT only ever catches the surface. The dropdown filters, the post-submission edits, the report layouts are the obvious gaps, caught in a quiet room with the vendor sitting next to you and a notepad. Even with all the CRs raised in that room, the bill has barely started.

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 made up. They're what every live custom system throws up in its first six months, because reality is always bigger than any spec, no matter how careful the meeting was. UAT was the warm-up. Daily use is where the real changes show up, and they show up faster than the vendor can invoice them.

The trap gets tighter here too. At this stage you have less bargaining power than during UAT, not more. The system is live and your staff depend on it. You can't pause work to "renegotiate scope," and you need the change in two weeks, not two months. The vendor knows this, and the CR price shows it.

The legal cover

This is what makes UAT so safe for the vendor. Every step of the bill is the client's own call. The client asked for UAT, agreed to the scope document, and approved every feature in it. The CR comes on a letterhead, with a price and a description, signed by the client.

There's no argument to win. The client can't say "you didn't deliver," because the vendor delivered exactly what the document said. The client can't say "this was always part of the brief," because the brief is right there on the table and the dropdown filter isn't in it. The client can't even say "you should have known we'd need this," because the vendor will reply, politely, 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 almost inevitable

It would be nice to think this is just a few bad vendors being cynical. It isn't. It's what naturally happens when you put a fixed-scope contract on 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, the wiring, the structural maths are all known. The contractor can quote you a price and soak up most of the surprises, because there aren't many.

A fixed-scope contract for custom software is the opposite. The "building" has never been built, and the plumbing is being figured out as the walls go up. A vendor who quotes a tight fixed price for brand-new software is doing one of two things: losing money, or pricing the gap as CRs. Almost all of them do the second. The first quote is the bait, and the CRs are where they make their money.

We've written about this from other angles: why hidden CR fees are killing IT projects, how CRs quietly inflate budgets, and why your vendor isn't your partner. UAT is the exact moment that turns all of this into invoices.

What clients should actually look for

The question to ask a vendor isn't "will you give me a fixed price?" Every vendor says yes. The real question is "what happens when reality doesn't match the spec, and what does that cost me?"

The honest answers sound boring. The dishonest ones sound rock-solid.

None of this means UAT itself is bad. Acceptance testing is useful when the system is well-understood and the spec is stable: buying off-the-shelf software, plugging in a known API, swapping one ERP module for another. In those cases the document can describe reality, and UAT does what the brochure says.

But the moment you're paying someone to build something nobody has built before, a single UAT gate at the end is the wrong tool. What you need is a vendor who's in the build with you, week after week, catching the gaps between spec and reality as they show up, instead of saving them all for the invoice.

The honest version

UAT isn't evil. It was made for one kind of software (well-understood, repeatable, off-the-shelf) and then used for a kind it was never built for (custom, brand-new, one-of-a-kind). In that second case it stops protecting you and turns into a toll you asked to pay on your own road.

The vendors who use it as a weapon aren't lying to you. Every CR is real, every signature is yours, and every invoice is for work that needed doing. The trap isn't fraud. It's the setup: a fixed scope on software you can't really fix in advance, with a checkpoint at the end where every gap between the document and reality becomes a billable line.