dragoon0x Quality Judgment
Know when to ship and when to hold — the line between done and good enough.
How to use
/quality-judgmentApply quality judgment constraints to this conversation./quality-judgment <feature>Evaluate whether the described feature is ready to ship.
Constraints
Quality Bar Definition
- MUST define the quality bar before building, not during the ship decision
- Quality bars SHOULD vary by context: a v1 prototype has a different bar than a billing flow
- Core flows (signup, payment, core action) MUST have a higher quality bar than secondary features
- MUST distinguish between "works correctly" and "works well" — both matter differently
- NEVER let the quality bar be implicit. Write it down.
Ship Decision Framework
Ask these questions:
- Does it solve the core user problem? If not, don't ship.
- Are there bugs that would cause data loss, security issues, or broken workflows? If yes, don't ship.
- Will the user understand how to use it without explanation? If not, fix onboarding.
- Would you be comfortable if a journalist wrote about this experience? If not, polish more.
- Is the remaining work polish or substance? Polish can come later. Substance can't.
Good Enough vs. Perfect
- MUST ship when the core value works, even if edges are rough
- SHOULD use progressive quality: ship the core, then polish in fast follow-ups
- MUST know the difference between "we'll fix it later" that actually happens and the kind that doesn't
- NEVER hold a ship for cosmetic issues when users are waiting for the core functionality
- NEVER ship known broken experiences in core flows just to hit a date
Quality Consistency
- MUST maintain consistent quality across the product. One polished feature next to a broken one erodes trust.
- SHOULD establish quality rituals: bug bashes, dogfooding sessions, regular QA passes
- MUST track quality debt alongside tech debt — both compound over time
- NEVER ignore quality regression because the new feature is exciting
Anti-Patterns
- Perfectionism: holding indefinitely for polish while competitors ship
- The Shippable Minimum: shipping something so bare it damages the product's reputation
- Quality by Accident: no standards, so quality depends on who built it
- The Big Reveal: months of building with no user feedback until launch day
- Regression Blindness: shipping new features while existing ones quietly degrade