Product Decisions This Supports
- Enforcing a "no new debt" quality gate. Catraca turns an aspirational policy ("don't make things worse") into an enforceable, automated rule. PM decision supported: adopt a ratchet-based quality gate as the definition-of-done for engineering, rather than a static "must be perfect" bar that legacy code can never meet.
- Roadmap sequencing between feature work and debt paydown. A ratchet makes quality trajectory visible: each merge either improves or holds the metric. That gives product a defensible answer to "are we getting slower?" without a multi-week measurement project.
- Build vs. buy for CI quality tooling. The alternative is a bespoke CI script that parses PHPStan/phpcpd output, stores a baseline, and diffs it — an ongoing maintenance cost owned by an already-loaded platform team. Adopting a package shifts that maintenance off your backlog.
- Which metrics to ratchet, and when. The tool is metric-agnostic in principle, so it supports staged decisions: start with duplication and static-analysis error counts (cheap, objective, low false-positive), defer coverage and complexity ratcheting until the team has CI hygiene.
- Legacy modernization strategy. Catraca enables the "boy scout rule at the system level" approach: rather than freezing features for a refactor quarter, you keep shipping while guaranteeing the codebase never gets worse. That is a materially different (and cheaper) roadmap commitment than a dedicated remediation project.
- CI gating policy: warn vs. block. The package's value is realized only when it can fail a build. Adopting it is a decision to move from advisory lint output to a blocking condition — a policy call product and engineering should make explicitly, not by accident.
- Vendor/stack standardization. Codifying quality enforcement in a Composer dependency makes the standard portable across teams and repositories, which supports onboarding and code-review consistency decisions.
When to Consider This Package
Good fit when:
- You have an established PHP/Laravel codebase with meaningful accumulated debt, and static analysis (PHPStan, Psalm, phpcpd, PHPMD) already runs in CI — Catraca adds enforcement, not new analysis.
- Incremental improvement is politically or commercially viable, but a "stop-the-world" cleanup is not.
- Your CI is trusted and reasonably fast; a new blocking step needs a pipeline that developers already respect.
- The team is small-to-mid and would rather adopt a focused Composer package than operate a quality platform (SonarQube, Qodana, Code Climate) with its hosting, licensing, and per-seat costs.
- You want a reversible commitment: the ratchet is a config file plus a baseline artifact, removable in one PR.
Look elsewhere when:
- You need reporting, not just enforcement. Catraca governs thresholds; it does not replace trend dashboards, per-team scorecards, or executive-level quality metrics. If stakeholders need charts, you need a platform alongside it.
- Greenfield or already-clean codebases. With near-zero debt there is little to ratchet; a strict static-analysis level and coverage floor deliver the same outcome with fewer moving parts.
- You require vendor assurance. At ~20 GitHub stars and a single-maintainer profile, this is a pilot-grade dependency. If your procurement process requires SLAs, indemnities, or a security-review trail, this will not clear it. Mitigate by pinning versions and treating it as a dev-only dependency with a documented exit path.
- Non-PHP stacks, or polyglot monorepos where one quality-enforcement mechanism must cover several languages.
- Very large monorepos needing per-package baselines, granular ownership attribution, and merge-conflict-tolerant baseline storage — expect to build custom tooling on top.
- Teams without CI discipline or code-review rigor. A ratchet without review of baseline changes is trivially bypassed; the tool then creates false assurance, which is worse than no gate.
Recommended posture: a timeboxed pilot (one repository, two metrics, one quarter) with a written success criterion — e.g., "duplication percentage non-increasing across 20 consecutive merges, zero baseline-widening PRs approved."
How to Pitch It (Stakeholders)
For executives — one paragraph:
Catraca is a low-cost, low-risk guardrail that stops code quality from silently eroding as we ship features. Instead of funding a large remediation project or accepting indefinite decay, we set a ceiling on our worst metrics and the build fails if anyone exceeds it. Cost is a Composer dependency and a CI step; commitment is reversible in a single pull request; there is no vendor lock-in and no new platform to operate. The business outcome is predictable delivery velocity and reduced long-term maintenance cost, with a decision we can trial on one team before scaling.
For engineering leadership:
It converts existing tooling output into an enforceable contract, keeps PRs small by forbidding "while I'm here" scope creep in either direction, and makes quality debt a tracked, monotonically improving number instead of an argument. It complements — not replaces — PHPStan, phpcpd, and code review.
Honest caveats to state up front:
- Maturity risk: small community, single-maintainer pattern, limited third-party documentation. Treat as a pilot; pin the version; keep the baseline in source control and review it.
- Baseline artifacts invite merge conflicts and, if unreviewed, quiet erosion of the standard. Pair with a review rule: baseline changes require explicit approval.
- Developer friction is real on first adoption (metrics start at "bad" and can only hold). Communicate that the ratchet is not a judgement on existing code — it freezes the status quo and monetizes future improvement.
- It measures what you configure, not what matters. Pick two metrics you would actually defend in a roadmap review; resist ratcheting everything at once.
Ask: approve a one-quarter, one-repository pilot with a named owner, a two-metric scope, and a go/no-go review at the end — not an org-wide mandate.