14 April 20268 min read
A client emails to say the last release broke something, and the thread that follows reveals that nobody on your side had looked at the work in three weeks. The partner did what was asked. What was asked was ambiguous, and the ambiguity was resolved by someone who did not know your client, in a direction that was reasonable and wrong.
This is the most common quality failure in subcontracted delivery, and it is not a failure of skill. It is a failure to define, to review, and to notice drift while it is small.
Define done before anyone writes anything
Most quality problems are specification problems wearing a costume. A team cannot meet a standard it has not been told, and standards that live in the heads of your senior people are not standards, they are preferences that get discovered through rejection.
A definition of done that is actually usable is short and checkable. It names the test expectations, the review requirement, the documentation that must exist, the accessibility and performance thresholds if they matter, and what must be demonstrated before something is called finished. If a point on the list cannot be checked by someone who was not in the conversation, rewrite it until it can.
Write it once and reuse it across partners and projects. Agencies that maintain one real definition of done find their onboarding time drops, because the thing new people most need is not a tour of the codebase but a clear statement of what good looks like here.
Review has to happen on your side, before the client
There is one non-negotiable structure in white-label delivery: work passes through someone accountable to you before it reaches the client. Not a glance at the demo. An actual review of what changed.
That does not mean re-doing the work or reading every line. It means a named senior person on your side who reviews the significant changes, who is briefed enough to have an opinion, and whose time is budgeted in the margin. The failure mode is treating review as something people do in the gaps of their real job, at which point it is the first thing to disappear under pressure, and it disappears precisely in the weeks when it was most needed.
If the only person checking the work is the person paying for it, you have outsourced quality control to your client.
Front-load, then thin out
Reviewing everything forever is expensive and it insults a good partner. The workable pattern is heavy at the start and progressively lighter as evidence accumulates.
- First weeks: review essentially everything, and treat every correction as a gap in the specification rather than a fault in the person. Most early corrections are things you never wrote down.
- Once patterns hold: review anything touching a sensitive area, anything client-visible, and a sample of the rest.
- Mature partnership: review by exception, with the sample kept alive so drift is still detectable.
The mistake is jumping to the third stage in month two because things seem fine. Seeming fine early is normal; the difficulties surface when the easy work runs out and the team starts touching parts of the system nobody explained.
The signals that catch drift early
Quality declines quietly and shows up loudly. A few observable signals move before the client notices.
- Questions stop. A team asking nothing is not a team that understands everything; it is usually a team that has started guessing.
- Estimates get uniformly optimistic, which often means someone is being pressured about velocity.
- Review comments repeat. The same correction three times is a standards problem, not a person problem.
- Tests are added but nothing is exercised by them, which is what happens when coverage is a target rather than a purpose.
- The same person answers for everything on a team of five, which usually means one person is carrying four.
None of these require instrumentation. They require someone paying attention weekly, which is again a budgeted-time question rather than a tooling question.
Give feedback to one person
In a partner arrangement your feedback should go to the partner's lead, not scattered across individuals, unless the individual is doing something in your review tooling where the comment naturally belongs. There are two reasons. The partner's lead can distinguish a pattern from an incident and is responsible for their people's development, and going around them undermines the person you most need to be effective.
Keep it factual and specific. Vague dissatisfaction produces defensive teams and no change: not this quality is not good enough, but these four pull requests missed the test requirement in the definition of done, and here is the section it is written in. Written standards make feedback impersonal, which is the only way it lands well.
When quality does not recover
Sometimes the problem is not fixable by clearer standards. The honest sequence is: name the specific gap in writing, agree a remediation with a date, and say plainly what happens if the date passes. If it does pass, the choices are replacing individuals on the team, which a good partner will offer before you ask, or ending the arrangement.
What is not acceptable is letting a client absorb the difference while you hope. If work has already reached a client below your standard, the cost of fixing it is yours, and taking that on your own margin rather than negotiating it with the client is what buying accountability from you was supposed to mean.
What to put in place this week
Three things, none of them large. Write or fix the definition of done and send it to every partner you use. Name the person on your side who reviews before the client sees anything, and put that time in their calendar rather than their goodwill. Pick a weekly moment to look at the five signals above. Everything else in quality control is refinement of those three.