Built-in quality
Built-in quality is the SAFe principle that quality is engineered into the product as it's built — through test automation, pair programming, continuous integration, code review, definition of done — rather than inspected in afterwards by a separate QA phase. The practice cluster makes 'quality late, regress under deadline' impossible.
The SAFe phrasing is borrowed from Lean manufacturing's 'jidoka' (build quality in, not inspect quality after). The concrete practices: automated tests run on every commit, CI gates prevent merge of red builds, code review is a first-class activity not optional polish, definition of done includes test coverage and accessibility, technical debt is tracked and paid down per PI. The trap is treating these as box-checked items rather than cultural commitments: a team can have CI/CD pipelines and still skip tests under deadline pressure if leadership's actual reinforcement is 'ship'. Built-in quality is as much a leadership stance as a tooling investment.
Discussed in our use-cases
ICP-targeted pages where built-in quality is part of the framing.
Related terms
- Definition of Done
Definition of Done (DoD) is a team-wide checklist that every story must satisfy before being marked complete — typical entries include: code reviewed, tests passing, documentation updated, deployed to staging, AC verified.
- TDD
Test-Driven Development is a workflow where you write a failing test first, write the minimum code to make it pass, then refactor — repeated in tight loops.
- CI/CD pipeline
A CI/CD pipeline is the automated chain of build / test / deploy steps that runs on every code change.