The phase nobody plans for
Ask a team to estimate an integration and they’ll estimate the build: endpoints, auth, data mapping, done. Then comes the phase that was a single line on the plan — “UAT” — and the schedule quietly doubles. Credentials that won’t verify. Endpoints that behave differently than they did last month. A test case that passed on Tuesday and nobody can say why it fails on Thursday. A vendor contact who answers every third email.
I’ve run this phase from both sides — as the vendor guiding customers through onboarding, and as the integrator being guided — across dozens of engagements. The pattern is remarkably consistent, and it has almost nothing to do with engineering skill.
Three structural reasons it stalls
It has no owner. UAT sits in the seam between two companies. The vendor assumes the customer is driving, the customer assumes the vendor is, and the engineers on both sides have a roadmap waiting for them somewhere else. Work that belongs to everyone gets done by nobody, and it doesn’t fail loudly — it just goes quiet.
It has no memory. It all lives in Postman tabs, email threads, and one engineer’s recollection of what they already tried. When that person is on holiday, or leaves, the engagement quietly starts over. Questions that were answered a month ago get answered again on the next call, which is about the slowest clock a project can run on.
Nobody can prove anything. “Does the integration work?” ought to be a factual question. In most engagements it’s a feeling. Someone ran some calls a while back and it seemed fine. Ask which endpoints were verified, when, against which environment, and what came back, and nobody can tell you. So sign-off turns into two groups of anxious people negotiating, instead of anyone reading a list.
What the fix actually is
None of those are tooling problems at heart — they’re foundation problems: a process nobody defined, and no shared account of what’s true. Which means the fix is structural, and it works the same whether you build it into software or just hold the line on it yourself:
Make every call real, and record every result. No claims based on mocks or memory. If an endpoint is marked working, that mark points at an actual sandbox execution with a timestamp and a response.
Give every endpoint a verification state. Untested, verified, failing — visible to both sides. The moment integration status is a ledger instead of a feeling, sign-off meetings get short.
Let failures file themselves. A 4xx or 5xx during testing should become a tracked issue on its own, attached to the exact request that caused it. Then reproducing it later is reading, not detective work.
Build the documentation out of the evidence. Runbooks written by hand start drifting from the system the day they’re finished. Ones generated from what the API actually did can’t, because there’s nothing separate to drift from.
Where this went for me
I got tired of rebuilding this discipline by hand for every engagement, so I built it into software: UAT-Ops, which handles the whole cycle: spec ingestion, credential checks, flow testing, issue tracking, UAT campaigns and generated docs. Every call it makes is a real one and it keeps all of them, which is why the numbers on that page are checkable rather than claimed.
The software is the smaller half of this, though. If your integrations keep dying in UAT, the problem usually isn’t testing. It’s that nobody owns the phase and nobody can prove what’s been done — and both of those are fixable without buying anything.
If your onboarding or integration engagements keep stalling in exactly this phase, I take it on as outsourced UAT: the whole phase, owned, with the evidence at the end. Here’s what that looks like in practice.