next.config.mjs had typescript.ignoreBuildErrors: true. The tsconfig.json had "strict": true. Both were present in the same codebase, at the same time.
That combination is self-cancelling. strict: true configures the type checker. ignoreBuildErrors: true tells the build to continue regardless of what the type checker finds. No typecheck script existed. CI ran a Playwright workflow that had been failing for weeks and was not being fixed. The effective correctness gate on a financial calculator site was: did the build finish without crashing.
An earlier article documented the raw event: flag removed, twelve errors surfaced, one afternoon of fixes. This piece makes the YMYL-specific argument. On a site where the product is financial calculators, the type gate is not a code quality signal. It is a trust signal.
What YMYL changes
YMYL is Google’s shorthand for “Your Money or Your Life”: pages where incorrect information has real-world consequences. Mortgage calculators, stamp duty calculators, and similar tools are YMYL by definition. The figures they produce inform financial decisions: what to offer on a property, whether a monthly repayment is affordable, what a remortgage will cost.
A type coercion error on a repayment formula is not an abstract correctness issue. It produces a wrong number. The user does not see the bug; they see a monthly figure. If that figure is off because a string was used where a number was expected, the downstream consequence is a user who has budgeted incorrectly before a significant financial commitment.
TypeScript strict mode, correctly enforced, catches that class of error at compile time. Under ignoreBuildErrors: true, it does not. The error exists in the code. The build passes. The user receives a wrong figure.
How the configuration ended up that way
ignoreBuildErrors: true is a documented Next.js escape hatch. It exists for legitimate reasons: initial scaffolding, partial type migration, triage mode during a deadline. The failure mode is that it persists after the original reason is gone, because removing it immediately reveals every type error that accumulated while it was in place.
strict: true in tsconfig.json is the mirror image: it signals intent. It looks correct in a repo scan. But without a tsc --noEmit step in CI, without the Next.js override removed, strict: true is a comment. It describes what the codebase aspires to, not what the build enforces.
The combination of aspirational strictness and systematic suppression is the specific failure mode. The type system knows there are problems. The build decides not to act on that knowledge.
Twelve masked product errors
Removing the flag surfaced twelve errors. Q.2a logged this: one afternoon, one config change, twelve errors identified and fixed, Quality Gate CI established.
The devlog does not enumerate the twelve by category. What the Phase R work landing the same day illustrates is the shape of one risk. R.1 shipped useCarriedNumberParam, a hook that reads a property price from the ?price= query string to carry figures between the mortgage and stamp-duty calculators. A query string value is a string, and a mortgage repayment formula expects a number. Without explicit coercion, strict TypeScript flags the mismatch. Under ignoreBuildErrors: true, that mismatch was invisible until runtime.
That is the class of error a financial calculator site cannot afford. Not because the compiler is fussy about types, but because a wrong type on a numeric parameter produces a wrong calculation. The type system is not wrong about what matters here.
Twelve errors is not a large count. On a YMYL site, it is not a code quality metric. It is twelve places where the compiler disagreed with how the product worked.
The cheapest trust signal
Phase Q ran three lanes in parallel. Q.0 removed fabricated trust signals and reframed stale rate articles honestly. Q.1 fixed internal link dead-ends so the four core calculator pages stopped being unreachable from the 48-article content corpus. Q.2a enforced the type gate.
Q.0 and Q.1 require editorial hours. Content rewrites, link strategy, article reviews. That investment recurs: every new article creates new link opportunities and new potential for stale claims. The work has no natural end state.
Q.2a required one config line and an afternoon of fixes. After Q.2a, a CI job runs on every push. A type error on a numeric parameter either gets fixed or the build fails. There is no deferred queue for type correctness. The gate does not forget.
For a YMYL site, that asymmetry matters. E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) is the framework applied to content quality on pages like these. Most of the editorial signals in E-E-A-T require ongoing human investment. The type gate does not. Once it is in CI, it is infrastructure, not process.
TypeScript strictness, enforced at build time, is the cheapest trust signal available on a YMYL site because it cannot be skipped by deadline pressure and does not degrade between audits. A wrong-typed parameter on a calculator function does not reach the user unless someone deliberately disables the gate. That property is worth more than the equivalent editorial signal because it is structural, not behavioural.
Quality Gate CI
The Q.2a devlog entry names what was established alongside the twelve fixes: Quality Gate CI. Not just the override removed: a CI job that makes the posture permanent.
Before Q.2a: strict: true was a tsconfig declaration with no enforcement path.
After Q.2a: a build failure is the enforcement path.
The Playwright workflow was separately red at the time Q.2a landed. End-to-end test coverage is a distinct layer from type correctness, and that repair is separate work. But the absence of type enforcement while E2E tests were failing meant the effective correctness gate was, in practice, nothing.
Phase Q as a whole is a coordinated quality posture: the three-lens assessment that triggered it, the content integrity work in Q.0, the link equity plumbing in Q.1, the type gate in Q.2a. Most of it costs ongoing editorial work. Q.2a costs one afternoon. On a YMYL site, an automated gate that never degrades is worth more than its setup time suggests. Permanently is the part that matters.
