Ship fast and ship unsafe are not the same axis

Two surfaces, and the only question that matters

Every decision you ship lives on one of two surfaces, and the test to tell them apart is a single question: if I am wrong, can I quietly fix it next week, or is the damage permanent the moment it ships?

Reversible surfaces are the ones where being wrong costs you a bad afternoon and a patch. A clunky onboarding flow. Copy that does not land. A layout that tests badly. A missing feature. A slow page. Get these wrong and you learn something from real users and you fix it. Perfectionism here is pure waste. The hours you spend polishing a reversible surface to a mirror finish are hours stolen from shipping and learning, and the polish rarely survives contact with the first real user anyway.

Irreversible surfaces are the ones where the damage lands the instant you ship and you cannot un-ring the bell. A security hole. Data loss. A money bug that moves real funds. A privacy breach. A compliance violation on a product serving children. There is no "fix as you go" here, because by the time you would fix it, the data is already exposed, the funds are already gone, the trust is already broken. On these surfaces, the caution that looks like perfectionism is not a vice. It is the job.

The teams that get burned are almost never the teams that moved fast. They are the teams that could not tell which surface they were standing on, and so they applied one posture to both. Sometimes that means agonizing for a week over a button color while a credential sits unprotected. Sometimes it means shipping the credential and the button color with the same shrug. Both are the same error: a failure to sort.

"Ship fast, iterate in public" was always domain-specific

The defining business advice of the last AI cycle was "ship rough and iterate in public," and it was correct, but it was never the blanket permission slip people heard.

Look at what actually happened. The breakout AI products shipped genuinely rough: they hallucinated, the interfaces were bare, they fell over under load constantly. That roughness was on the reversible surface, the product experience, where every embarrassing flaw was a thing real users would help them fix. What those same products did not do, at least not the ones that survived, was ship rough on the irreversible surface. Your account was not getting popped. The roughness was a deliberate trade on one axis, paid for with discipline on the other.

That is the part the cargo-cult version dropped. "Move fast and break things" became a slogan, and the things that got broken were supposed to be the recoverable ones. Break a layout, break a feature flag, break a deploy you can roll back. Do not break the trust boundary. The companies that took the slogan to mean "break anything" eventually broke something they could not put back, and then the pendulum swung to "slow down," and now we have a generation of teams afraid to ship at all. Both swings missed the actual rule, which never changed: be rough where rough is recoverable, be paranoid where it is not.

How we engineer the sort

A sorting rule that lives only in someone's head is not a discipline, it is a hope. The work is to build the sort into the system so it does not depend on anyone remembering it under deadline pressure. Concretely, this is how we do it.

On the irreversible surfaces, the defaults fail closed. Security on a product we build is not "explicitly unprotected, the customer wraps it later." It is mandatory tokens, refuse-to-start when a required secret is missing, deny by default, least privilege on every credential. The system is built so that the unsafe configuration is the one that does not run, not the one that quietly ships. When an AI agent touches anything that matters, it gets scoped tools instead of raw access, an approval queue on the high-impact actions, and policy encoded in the tool layer where it cannot drift, not in a prompt where it can.

On the reversible surfaces, we move. We ship the working version, put it in front of real users, and improve it on the evidence instead of on a hunch. We do not hold a launch hostage to a perfect onboarding flow, because the onboarding flow is exactly the kind of thing real usage will redraw for us.

And the line between the two is not left to vibes. Every project we ship runs through an engineering review before handoff, and the review is explicitly severity-sorted: nothing ships with an open finding rated Critical, because Critical is our word for "this is the irreversible surface and it is not safe yet." A cosmetic finding can ship and get fixed next sprint. A Critical one cannot. The review is the sort, written down and enforced, so the judgment does not have to be re-made, correctly, by a tired person at 11pm.

What this article is not

This is not an argument that careful engineering is slow. The opposite: sorting by reversibility is what lets you be genuinely fast, because you stop spending irreplaceable hours hardening things that did not need it and spend them where being wrong is permanent.

This is not a claim that every irreversible mistake is foreseeable. Some are not. The argument is that most of the famous ones were entirely foreseeable and got shipped anyway, because the team applied a reversible-surface posture to an irreversible-surface decision.

This is not a single threshold you can copy. Where exactly a surface becomes irreversible depends on the business: the line for a regulated health product is not the line for a marketing site. The discipline transfers. The specific cutoffs are an engineering judgment we make per system.

One-sentence takeaway

You can iterate your way to a great product, but you cannot iterate your way back from a breach, so sort every decision by whether being wrong is recoverable, move fast where it is, and be paranoid where it is not.