Quality in a VDC engagement isn't customer-imposed. It's platform-default. Three layers of quality assurance — pod-level code review, automated testing, milestone-level acceptance — operate in concert to produce code that's auditable, shippable, and consistent with the rest of your codebase.
This piece walks through each layer, who owns it, what good looks like, and the procurement-stage questions that surface whether a vendor's quality posture is real or marketing.
Layer 1: Pod-level code review
The first quality gate. Every PR goes through code review before merging — not as an option, as a policy. The pod's tech lead is the final reviewer for non-trivial changes; specialists review each other's work for the rest.
What good looks like
- No PR merges without an approving review.
- Reviews check correctness, conventions, security implications, and architectural fit.
- Review turnaround SLA: first feedback within 4 hours, final approval within 1 working day.
- Reviewer is qualified — for complex PRs, the pod's tech lead reviews; for routine changes, peer review suffices.
- Customer's senior engineers can opt into specific reviews (architectural changes, security-sensitive PRs) but don't need to gate every PR.
What's enforced through tooling
- Branch protection rules (no direct push to main; required reviews; required passing CI).
- Required signed commits where security policy demands it.
- Status checks blocking merge until tests pass.
Customer-side senior engineers who want visibility can subscribe to PR notifications without being required reviewers. Visibility without gating is the right shape — it lets them weigh in on architectural decisions without being the bottleneck for routine work.
Layer 2: Automated testing
The second quality gate. The pod's QA engineer (or specialist engineers in pods without dedicated QA) builds and maintains the test suite alongside production code.
The test pyramid for VDC engagements
- Unit tests: Run on every commit. Cover business logic, edge cases, error paths. Fast (under 5 minutes for the suite).
- Integration tests: Run on PR. Cover service boundaries, database interactions, third-party API calls. Slower (up to 15 minutes).
- End-to-end (E2E) tests: Run on PR for critical user flows. Slowest, most expensive to maintain.
- Performance / load tests: Run on milestone completion. Cover scalability assertions.
- Security tests: SAST / DAST scans on every PR. SCA for dependencies.
Test coverage targets
Coverage isn't the goal — confidence is. Targets vary by component:
- Business logic: 80%+ coverage with thoughtful test cases.
- API surface: 100% of endpoints tested at integration level.
- UI components: 60–80% coverage; visual-regression tests for critical paths.
- Infrastructure code: review-only or 30–50% coverage; runtime monitoring catches what tests miss.
The customer's existing engineering standards determine the actual targets. Pod adopts them rather than imposing different ones.
Layer 3: Milestone-level acceptance
The third quality gate. Milestones don't sign off until acceptance criteria pass. The customer's product owner reviews; the pod's DM facilitates.
What's checked at acceptance
- Each acceptance criterion (defined at milestone planning) demonstrably passes.
- All tests in the relevant suite pass.
- Performance / non-functional requirements met (where applicable).
- Documentation updated for new functionality.
- Security review completed; no high-severity findings.
If any criterion fails, the milestone doesn't sign off. The pod addresses; the cycle repeats. Healthy engagements sign off in the same sprint as the demo. Unhealthy ones drift into multi-sprint sign-off cycles — that's a process failure, not a quality failure (see anti-patterns).
How quality scales with pod composition
The QA model varies by pod size and work shape:
- Small pod (3–4 specialists): No dedicated QA; specialists handle their own test discipline. Tech lead enforces quality gates in code review.
- Standard pod (5–7 specialists): Dedicated QA engineer in the pod. Owns test strategy, test automation, milestone-acceptance gate enforcement.
- Multi-pod engagement: Each pod has its own QA capacity, or a shared QA function across pods. Engagement architect aligns test standards.
- Regulated industries: Additional QA discipline — independent verification, audit-trail integration, sometimes a separate validation function. See VDC compliance and audit.
Customer-side quality involvement
Customer engineering doesn't run the pod's quality gates — but they participate in three ways:
- Acceptance criteria definition. Customer's product owner writes acceptance criteria during milestone planning. The pod implements against them.
- Architectural review participation. For PRs affecting downstream systems, customer's senior engineers review.
- Final acceptance sign-off. Customer's product owner signs off on milestone completion.
If customer engineering is reviewing every PR or running QA tests themselves, the model has reverted to staff augmentation. The pod owns operational quality; customer reviews outcomes.
The procurement-stage quality questions
Five questions to surface quality posture before signing:
- Who reviews each PR before merge? (Right answer: pod's tech lead for non-trivial; peer review for routine. Wrong answer: customer's senior engineers.)
- What's the test-coverage target for new code, and how is it enforced? (Right answer: target with CI enforcement. Wrong answer: "we encourage testing.")
- How does the pod handle security review? (Right answer: SAST/DAST on PR + dedicated security review for milestone-impactful changes. Wrong answer: "we leave security to the customer.")
- What happens when acceptance criteria aren't met at milestone close? (Right answer: pod addresses, milestone doesn't sign off until criteria pass. Wrong answer: "we work with you to scope what's possible.")
- How is technical debt tracked and addressed? (Right answer: visible debt log, periodic remediation milestones. Wrong answer: "we don't accumulate debt.")
Vague answers indicate the platform's quality posture is marketing copy. Specific answers indicate operational discipline.
How quality compounds over the engagement
Quality at month 1 is different from quality at month 6:
- Month 1: Pod is calibrating to your conventions. Some PRs need second rounds. Test coverage is establishing a baseline.
- Month 3: Conventions internalized. PRs go through cleanly. Test suite matches the pod's understanding of "done."
- Month 6: Pod's tech lead catches issues your senior engineers wouldn't. Test suite has caught regressions before they reached your team. Pod is contributing improvements to your existing testing infrastructure.
The quality curve mirrors the velocity curve — both compound from month 3 onward in a healthy engagement.
Frequently asked questions
What if the pod's code style differs from ours?
Pod adopts your style. Style guide is reviewed during onboarding. Linting / formatting tooling enforces it on PR. By month 2, the difference shouldn't be visible in the codebase.
How do we handle quality issues escalating across multiple sprints?
Pattern, not incident. If 2–3 sprints in a row have quality issues, that's a structural signal — either pod composition is wrong (specialist mismatch), governance is breaking (review SLAs slipping), or expectations are unclear (acceptance criteria too vague). Diagnose the structural cause, don't just escalate the symptom.
Can the customer's senior engineers participate in code reviews?
Yes, by opting in on specific PRs. Don't make them required reviewers on all PRs — that bottlenecks the pod and reverts the model. Architectural changes, security-sensitive PRs, and conventions establishment are good candidates for opt-in customer review.
What about technical debt the pod inherits from your existing codebase?
Visible from day 1. Pod surfaces inherited tech debt during the codebase walkthrough; customer decides whether to remediate as part of the engagement scope or note for future work. Either way, the debt isn't the pod's responsibility unless explicitly in scope.
Where to start
If you're scoping a new engagement, agree quality standards at kickoff. Don't leave them to drift. Specifically: code review SLAs, test coverage targets, and acceptance criteria writing pattern.
For quality-posture conversations specific to your engagement, schedule a 30-minute call. For broader context on roles and governance, see roles inside a VDC and defining outcomes for a VDC.