The First 90 Days of an Embedded QA Team

What a founder actually wants to know before signing an embedded QA engagement is rarely the pitch. It is what week one through week thirteen actually look like, day to day, before anyone commits budget or a seat on the team to it. The details below are a composite, generalized across the shape this tends to take across engagements we run, not one identified client, since every real engagement varies in specifics while following the same underlying pattern.

What happens in the first 90 days of an embedded QA engagement?

A well-run embedded QA engagement moves through three phases in its first 90 days: an audit and initial coverage push in the first 30 days, full integration into sprint ceremonies and the first enforced quality gate by day 60, and measurable, reportable results by day 90. The order matters as much as the content, since skipping the audit to jump straight to coverage is the most common way an engagement stalls.

Days 1 to 30: audit and first coverage

The first week is a real QA audit, not a courtesy scan, reviewing the existing codebase, whatever test documentation already exists, and the last few releases' worth of defect history to find where coverage is thin and where risk actually concentrates. This step gets skipped more often than it should, usually because a team wants to see test cases being written immediately, but an engineer testing without first understanding where the real gaps are ends up covering what is easy to test rather than what is actually risky.

By the end of week one, the audit produces a written list of coverage gaps ranked by risk, not a vague impression. Weeks two through four turn that list into active test coverage on the highest-risk items first, with the engineer already filing real defects against the current codebase, not just building a plan for later. A reasonable bar for day 30 is a handful of genuine, previously unknown defects found and reported, proof the audit was real rather than a formality.

Days 31 to 60: full sprint integration and the first quality gate

By day 60, an embedded QA engineer should be a normal participant in sprint planning, writing test cases alongside the ticket itself rather than after the fact, and filing defects the same day they are found instead of batching them into an end-of-sprint report. This is also the phase where the first real CI/CD quality gate typically goes live, an automated check on the highest-risk category of change that blocks a merge rather than just flagging it, since a gate proposed in week one before anyone trusts the coverage behind it rarely survives contact with a deadline.

The middle 30 days are also where the second wave of defects tends to surface, often more than the first 30 days found, not because the engagement is going worse, but because a fresh set of eyes with a full sprint of context behind it starts noticing patterns a team stopped seeing in code they see every day.

Days 61 to 90: measurable results and release sign-off

By 90 days, a team should be able to answer three questions without a meeting: what was tested this release, what is a known and accepted gap, and who signed off before it shipped. That is the real test of release readiness, not a green test suite on its own. Engagements that reach this point on schedule tend to show the same shape of result across the board: escaped defects trending down toward the 45% reduction range seen across engagements we have run, and release coverage climbing toward the 95% mark, not because more hours got logged, but because testing finally has a process and a gate behind it instead of running on individual diligence alone.

What a healthy 90 days looks like versus a stalled one

The clearest way to tell whether an engagement is on track is to check it against real checkpoints at each 30-day mark, rather than waiting until day 90 to find out something drifted early.

• Day 30, healthy: a written, risk-ranked list of coverage gaps and at least a few real defects already filed. Day 30, stalled: the engineer is still reading documentation with nothing concrete filed yet.
• Day 60, healthy: the engineer is a visible participant in sprint ceremonies and one quality gate is live and actually blocking merges. Day 60, stalled: testing still happens off to the side, reported in a weekly summary instead of inside the sprint itself.
• Day 90, healthy: escaped defects and coverage numbers exist and are trending in a known direction. Day 90, stalled: nobody can name a number, only a general sense that things feel better.

A stalled pattern at any checkpoint is not usually a sign the wrong engineer was hired, it is almost always a sign the audit step got skipped or rushed, since every other phase depends on that first 30 days producing a real, risk-ranked map to work from.

Why this pattern holds across different engagements

This is not a coincidence repeated by chance across unrelated engagements, it is the same underlying pattern applied to whatever a given product and team actually look like: audit first, prioritize by risk, integrate into the real process, gate the highest-risk work, then measure. The specific numbers vary by engagement, a fintech product supporting a client past $1B in revenue surfaces a different set of highest-risk areas in its first 30 days than an early-stage product would, but the sequence itself does not change, because the sequence is what makes the specific numbers achievable in the first place.