Launch-Blocking Finding

Fourteen findings, six days to launch, a security function of six supporting two hundred engineers. Block on all fourteen and the review is removed from the release path within two quarters, because the business will not accept a function that cannot tell a missing header from a misplaced encryption key. Block on none and the review is a newsletter.

The decision that matters is not which findings are severe. It is which findings become expensive the moment real users arrive.

Why it matters

Remediation cost is a function of time, and the function is not smooth. Some fixes cost the same forever: a missing rate limit, an absent response header, an over-broad log field. Others cross a threshold at launch and never come back. Once those are in production, they stop being review findings and become programmes.

• Identifier schemes. Customer identifiers in URL paths reach access logs, browser history, bookmarks and partner referrer reports. Changing them later means a redirect layer and a data migration.
• Where personal data sits in the data model. Moving a column across a trust boundary after 300 customers is a migration with downtime risk, not a refactor.
• Key custody. A key generated on the wrong side of a boundary means re-encrypting every row at rest, re-issuing derived credentials and migrating live sessions.
• Tenancy. A shared schema with no row-level enforcement is cheap on day one and a multi-quarter programme at 300 tenants.
• Anything in a client you cannot force-upgrade, where the old version's behaviour is permanent.

A review that spends its blocking budget on the first list and waves through the second produces the paperwork of assurance and none of the effect.

Implementation patterns

• Classify every finding into three buckets at the review: irreversible by launch, expensive later, cheap anytime. Only the first blocks.
• Publish the blocking classes in advance. The list doubles as the review trigger, so teams self-check and bring the right things early. A secret blocking list produces late surprises and resentment.
• Non-blocking findings become issues with a named owner and a date, enforced by the same expiry mechanism as waivers, or they are never done.
• Apply a reversibility test out loud: what would changing this cost at 1 million users and 10 integrated partners? If the answer is a programme, it blocks.
• The review's output is a decision record, not a findings list - what was accepted, by whom, until when.
• Measure the block rate. Zero percent means the classes are wrong or review arrives too late to matter; above roughly 20% means review is happening after designs are fixed, and the fix is the trigger.

Industry example

The pattern recurs in multi-tenant B2B products. A team puts a single shared schema keyed by tenant id in production with enforcement in application code, which is reasonable at 5 customers and a known risk at 500: one missing predicate in one query is a cross-tenant disclosure, and retrofitting row filtering in the database touches every query path. Identified as irreversible-by-launch it costs one sprint; accepted as medium severity and revisited two years later it costs a migration plan, a customer communication and usually an incident in between.

Failure scenarios

• Blocking on severity score, which holds launches for header fixes and lets the data model through.
• Non-blocking findings with no expiry, so the backlog becomes the accepted architecture.
• Review scheduled in launch week, where even an irreversible finding is waived because the date is fixed. The defect is the trigger, not the reviewer.

Trade-offs

Blocking on irreversibility means knowingly launching with real, fixable weaknesses that somebody carries as accepted risk with dates, and it requires judgement the review function must defend publicly. In exchange the review stays in the release path, which is the only way it finds anything.

When not to use it

Where a single exposure is reportable or catastrophic - regulated health data, card data, a safety function - block on severity as well, because the asymmetry between a fine and a sprint reverses the calculation. For an internal tool with ten users and reversible everything, do not block at all. And before product-market fit, with a data model that will be rewritten anyway, the irreversibility argument is mostly hypothetical.

Interview question

Q: A review a week before launch produces fourteen findings and the launch date is contractual. Which ones do you block on, how do you argue it to the product director, and what do you change so this does not recur?

What a strong answer covers: the irreversibility test and which findings pass it; converting the rest into dated owned commitments with enforced expiry; the argument framed in remediation cost rather than severity; and the structural fix, a trigger that brings this design class to review while it is a diagram.

Quick check

Quiz: Which design review finding blocks a launch? — The one whose remediation cost rises by orders of magnitude once real users exist: identifier schemes, personal data placement, key custody, tenancy, client-embedded behaviour. Severity alone does not decide it.

Flashcard: Why is blocking on severity score worse than blocking on irreversibility? — It holds launches for one-line fixes and waves through choices that become multi-quarter migrations, and the review function loses its place in the release path for no safety gain.