Revisit on the Premise, Not the Failure
Most organizations only reopen a decision once something is on fire. A vendor misses an SLA, a system falls over at scale, a customer complaint reaches a director's inbox, and suddenly the thing that's been running fine for years gets a review meeting. That's the only trigger most feedback loops are built to notice: visible breakage. Nothing about a working system generates an alert on its own.
Which is what makes it worth sitting with when a company walks back a bet that was, by their own account, still working. Shopify picked React Native in 2020 to avoid building the same app twice, once in Swift and once in Kotlin. That reasoning rested on a specific cost assumption: native duplication is expensive, expensive enough to eat the overhead of a cross-platform framework instead. Years later, they unwound the bet, and they were careful to say React Native hadn't failed them. What had happened instead was that coding agents made writing an app twice, natively, cheap enough that the original tradeoff no longer pencilled out. The framework didn't get worse. The reason for choosing it got quietly obsolete.
That's a different kind of review than the incident-driven kind, and it's rarer for a structural reason. An incident produces a ticket. Someone has standing to ask "why are we still doing this" because something visibly went wrong, and the org's own machinery routes the question to a person with the authority to answer it. A premise going stale produces nothing. No error, no ticket, no owner whose job it is to notice. The React Native integration kept shipping releases, kept passing whatever health checks it had, and would have kept doing so indefinitely if nobody had gone looking for the argument against it. Someone had to schedule the audit with no complaint driving it, which is the part almost no organization does by habit. You need a person willing to ask "is the reason we did this still true" on a system nobody's mad at, and most incentive structures don't reward that question. They reward putting out the fire that's currently burning.
The tell that this wasn't a nostalgia project or a rewrite for its own sake is in what they built to support it. Coding agents can write Swift and Kotlin without much trouble, but the actual bottleneck turned out to be verification: simulators are slow, and checking a UI change by screenshot or accessibility tree closes the loop too slowly to be usable. So the fix wasn't "throw an agent at the old codebase." It was decoupling business logic from the UI so it can run headless behind a command line, and building a migration tool that forces checkpoints, tests, visual diffs, and two independent reviewers before anything moves forward. That's the shape of an organization that took its own premise-check seriously enough to go solve the boring problem underneath it, rather than declaring victory and shipping a demo.
The asymmetry is what I keep coming back to. Reviewing on breakage is nearly free, institutionally. The system announces its own failure and someone gets assigned to fix it. Reviewing on premise costs someone's attention on a system that isn't complaining, and it requires that person to hold the original justification in mind well enough to notice when the world has moved out from under it. Almost nobody keeps a running list of "reasons we made this call" that gets checked against reality on a schedule. Decisions get made, the reasoning gets buried in a doc nobody rereads, and the decision just persists until it breaks or until someone happens to remember why it was made in the first place and happens to check whether that's still true.
Most working systems are quietly running on premises nobody's checked in years, not because the premises are still good but because nothing forces the check. The rare move isn't fixing what's on fire. It's going looking for the fire that hasn't started yet, in a system that's giving you no reason to look.