Here’s a scene I’ve watched play out more times than I’d like to admit.
A product team signs with a QA vendor. There’s a kickoff call, everyone’s polite, slides get shared. Then week one goes by. Week two. The client is paying for a team of “senior engineers,” but what they’re actually getting is a stream of questions in Slack. Where’s the staging environment? Who has the credentials? What does this feature even do? By week three the founder is quietly wondering if they made a mistake, and nobody on the vendor side has shipped a single automated test yet.
This is the part of QA outsourcing nobody puts on their landing page. And it’s the single biggest reason these partnerships fall apart.
I want to talk about it honestly, because the onboarding period – those first 30 days – is where the whole relationship is decided. Not the sales call. Not the case studies. The first month.
Why “we’ll ramp up quickly” is usually a lie
Every vendor says it. Fast onboarding, plug-and-play teams, hit the ground running. Then reality shows up.
The truth is that a QA engineer dropped into an unfamiliar codebase is, for a little while, slower than useless. They don’t know the product. They don’t know which flows are critical and which ones nobody cares about. They don’t know that the payment module breaks every other Tuesday and the team just lives with it. So they do what untrained people do – they write a few shallow tests for the obvious stuff, file some bugs that turn out to be known issues, and generate a lot of noise that your internal team now has to triage.
You’re paying senior rates for what feels like a junior throwing things at the wall. And here’s the uncomfortable part: that’s not always the vendor being lazy. Sometimes it’s just the nature of the work. Context takes time to build. The question is whether the vendor has a system for building it fast, or whether they’re winging it on your dime.
Most are winging it.
The black box problem
The second thing that kills these relationships is visibility, or the lack of it.
You hand over access, the team disappears into their own tools and their own process, and you get a status update on Friday that says something vague like “continued working on automation framework.” Cool. What does that mean? How many tests exist? What’s covered? What’s still exposed? If a release went out tomorrow, would you know whether it’s safe?
When a client can’t answer those questions, they stop trusting the partnership. And once trust goes, it doesn’t come back with a nicer report template. I’ve seen six-figure engagements die not because the testing was bad, but because the client never felt like they knew what was happening. Quality work in a black box is worth almost nothing, because the person paying for it can’t tell it apart from bad work in a black box.
So what should the first 30 days actually look like?
This is where I’ll get specific, because vague advice helps nobody.
Days one to three are pure access and orientation. Environment credentials, repo access, Jira, CI/CD pipeline, documentation – all of it sorted in the first 72 hours, not dragged out across two weeks of back-and-forth. If a vendor can’t organize this quickly, that tells you something about how they’ll handle everything else.
The next stretch, roughly days four through ten, is deep analysis and it should look boring from the outside. The team is learning your product, mapping the critical user journeys, identifying where the real risk lives. No vanity tests yet. A QA engineer who starts automating on day two is automating blind, and you’ll pay to rewrite all of it later. This phase is where a good team earns its keep quietly – they’re asking sharp questions, not random ones.
By the middle of the month you should see a concrete test plan and the automation setup taking shape. Not promises. An actual document that says: here are your critical functions, here’s our coverage target, here’s the framework we’re building in, here’s what we’re prioritizing and why.
And by day 30, something should be live. In our case that means a working automation suite running in your CI/CD pipeline – Playwright, integrated, executing on real builds – plus a report that tells you exactly where your quality stands. Not “we set up some tests.” A release-readiness picture you can actually act on.
If you reach the end of month one and you don’t have working automation in your pipeline and a clear-eyed map of your risk, the onboarding failed. It doesn’t matter how nice everyone was on the calls.
The thing nobody wants to charge for
Here’s my slightly contrarian take. The best vendors treat onboarding as a deliverable, not a warm-up.
Most of the industry treats the first month as overhead – a cost they eat to land the contract, something to get through. That mindset is exactly why onboarding is so consistently bad. When you think of week one as “the boring part before the real work,” you don’t build a process for it, you don’t measure it, and you definitely don’t make it transparent.
I think that’s backwards. The onboarding is the real work. It’s the part that determines whether everything after it succeeds. A team that nails the first 30 days has earned the right to the next six months. A team that fumbles it has told you everything you need to know.
What to actually ask a vendor before you sign
If you’re evaluating QA partners right now, skip the questions about how many engineers they have or which tools they know. Everyone knows the tools. Ask these instead:
What does day one look like? What will I have in my hands by day 30? How will I know, week to week, what you’re actually doing? What happens if two months in, the results aren’t there?
A vendor with a real system answers those instantly and specifically. A vendor without one gets vague, starts talking about “flexibility,” and pivots to their client logos. You’ll know within about ninety seconds which kind you’re dealing with.
The teams that survive outsourcing don’t get lucky. They just refuse to treat the first month as a formality – and they make damn sure you can see what they’re doing the whole way through.