Rollback Is Deleting a Link

I counted the sections on one page of a workforce dashboard I run. Twenty, stacked top to bottom. The same candidate was drawn more than ten different ways on that one page. Two different modals could edit the same record, and they disagreed about what the record was. The daily loop, the thing staff actually did every morning, was split across three surfaces that were not even next to each other. Everyone knew the page was bad. And I could not take it down to fix it, because people used it to do their jobs.

01How a page gets like that

Nobody designs a page with twenty sections. You design a page with three, and then you add one. Each addition is reasonable. Each one is a ten-minute change that solves a real request from a real person. The twentieth section went in for the same good reason as the fourth. That is the trap. A page like this is not the product of bad decisions. It is the product of seventeen good ones.

So the page needed a rewrite. But rewriting a live surface is one of the most dangerous things you can do in software. The graveyard is full of v2s that shipped half finished, quietly broke something the old version did, and got rolled back in a panic. Every operator has seen one. So the interesting question is not how to build the new page. It is how to earn the right to ship it.

02One rule

I gave myself one rule: the rewrite does not touch the API. Not one endpoint changed, not one field renamed, not one migration. The new module, Voucher HQ, had to be built entirely out of contracts the old page already used. If the new page wanted data the old API could not give it, that was the new page's problem, and it had to wait.

The entire backend diff for the whole rewrite was one additive flag, cached=1, so the new page could ask for a cheaper read. That is it. The old page changed in exactly two places: a button and a card that link into the new module.

Look at what that buys. If Voucher HQ is wrong, nobody is stranded; the old page still works exactly as before. If Voucher HQ is down, nothing else is. And if I decide the whole thing was a mistake, rollback is deleting a link. Not a migration rollback, not a deploy, not a war room. Deleting a link. That is why I could ship it without asking anyone. There was nothing to ask permission for.

03The same shape in healthcare

I trusted the rule because I had already used it in a different industry. I run a denial management agent called Daniel in healthcare revenue cycle. When it came time to wire Daniel into a live portal, same rule. The integration reads what it needs, and the only runtime write in the whole thing goes to its own audit table. It cannot corrupt a claim, because it cannot reach one. Rollback there is flipping an environment variable.

Workforce development and healthcare revenue cycle have nothing in common on the surface. One moves candidates through job training. The other moves claims through insurance companies. But the risk has the same shape in both: a live system people depend on, and a new thing that wants to sit beside it. The answer has the same shape too. Constrain the new thing until its blast radius is zero, and you can ship it whenever you want.

04What a rewrite should cost

If your rewrite needs a migration, you are not rewriting. You are gambling.

Tests do not earn you the rewrite. Tests tell you the new thing probably works. They say nothing about what happens to the old thing when the new one turns out to be wrong. For a live system, that is the only question that matters: what breaks if this is garbage? If the answer is nothing, you delete a link. And if the answer is nothing, you can ship on a Tuesday afternoon without asking anyone.

1. 1Earn the rewrite with blast radius, not test coverage. Zero blast radius is the license.
2. 2Reuse every contract the old system already has. If the old API cannot power the new UI, that is a separate project with its own risks. Do not smuggle it into the rewrite.
3. 3Make rollback a deletion or a flag flip, never a procedure.
4. 4If the plan includes a migration, stop calling it a rewrite. A migration is a bet, and bets need a different kind of approval.

The old page is still up. It still has its twenty sections. People drift over to the new module a little more each week. One day the traffic will hit zero, and I will retire the old page the same way I could have retired the new one: quietly, by deleting a link. If you are staring at your own twenty-section page, do not wait for permission. Build where you cannot break anything, and you will not need it. That is what a rewrite should cost.