Back to blog
·3 min read

Quality Gates: Why Checklists Don't Work

The difference between quality checklists and quality gates — and why only one of them actually works.

The Checklist Illusion

Every development team has quality checklists. "Before merging, make sure you've done X, Y, Z."

How often do developers actually follow them? Be honest.

Checklists are suggestions. Under deadline pressure, they get skipped. "I'll come back to it later." Later never comes.

What Quality Gates Actually Are

A quality gate is different. It's not a suggestion — it's a **blocker**.

Your code doesn't merge unless:

  • Security checks pass
  • Tests cover the new code
  • Documentation is updated
  • RLS policies exist for new tables
  • No hardcoded secrets detected

    • Not "should have." **Must have.**

    Why Blocking Works

    Human willpower is finite. When you're tired, under pressure, or just ready to be done, you'll skip optional steps.

    But if the system literally won't let you merge? You do the work.

    Quality gates turn optional best practices into mandatory requirements. They remove the decision entirely.

    ZipBuild's Quality Gates

    Every ZIP (build step) in ZipBuild has quality gates:

    Code Quality

  • TypeScript strict mode passes
  • ESLint clean
  • No console.logs in production code

    • Security

  • No secrets in code
  • RLS policies on all new tables
  • Input validation on all endpoints

    • Testing

  • New functionality has tests
  • Critical paths covered
  • Tests actually pass

    • Documentation

  • IMPLEMENTATION-LOG.md updated
  • DECISIONS.md records any architectural choices
  • TECHNICAL-FLUENCY.md explains changes in plain language

    • Nothing ships without passing every gate.

    The Result

    Products that are actually production-ready. Not "we'll fix it later" ready. Actually ready.

    Quality gates turn aspirational standards into enforced reality. That's the difference.

    Written by ZipBuild Team