I shipped a feature today by deleting thirty-one lines of code and building nothing. The product got more honest, the work took five minutes, and I think it is one of the more underrated moves in software.
Here is what happened, and why "delete the promise" belongs in your toolkit next to "build the feature."
The discovery
I was going through a live web app — a publishing platform — and its tagline read: "Quality articles, permanently stored." On every article page, there was a badge: "Permanently stored on Arweave" — Arweave being the blockchain network for permanent, tamper-proof storage. Permanence was, on paper, the product's headline differentiator against the big incumbents.
There was only one problem. It was not real.
I went looking for the code that wrote articles to Arweave, and it did not exist. The database had a column for the Arweave transaction ID, and the article template rendered that shiny badge — but only when the column had a value. And nothing, anywhere in the codebase, ever set that value. So the column was always empty, the badge rendered for exactly zero articles, and the tagline promised something the software had never once done.
Conditional dead code hides claims in plain sight
This is worth dwelling on, because it is a sneaky category of bug. The badge was not obviously broken. It was wrapped in the equivalent of:
if (article.arweave_tx_id) {
render("Permanently stored on Arweave")
}
That code looks live. It passes review. It even passes tests. But arweave_tx_id is never populated, so the branch is dead — a promise that renders only under a condition that never occurs. In the running app it is invisible; in the source it is quietly asserting something false. These "renders only if X" blocks, where X never happens, are a special kind of debt: not a crash, not a wrong result, just a claim your product makes that isn't true.
The tell that caught it was searching for the promise ("permanent"), not the feature ("arweave"). Grep for what you are claiming to users, not just for what you named the function.
The fork in the road
Once you find a promise with no implementation behind it, you have two options:
- Build it. Make the claim true — write the Arweave upload pipeline, fund a wallet, poll for transaction confirmation, backfill every existing article. Days of work, ongoing cost, a new external dependency, and a whole class of failure modes to handle.
- Delete the promise. Remove the badge, the dead column reference, and the tagline. Replace them with something true. Five minutes.
The instinct in our field is almost always option 1 — a gap between promise and reality reads as "unfinished feature, go finish it." But that instinct skips the actual question: does anyone want this feature, or did it just sound good in a spec?
In this case, no user had ever asked for blockchain permanence. It was an aspirational bullet point that made it into the marketing before it made it into the roadmap. Building it would have been days of work to satisfy a promise the product made to itself. So I deleted it: the badge, its dead styles, the tagline. The site's copy went from a lie to the truth in one small commit, and the headline became something the product actually delivers.
Honesty by subtraction
The reframe I want to leave you with is that removing a false claim is a legitimate way to ship. We measure progress in features added, so deleting one feels like going backwards. It is not. A product that honestly describes what it does is strictly better than one that promises something it doesn't — more trustworthy to users, and less confusing to the next engineer who reads "permanently stored" and wastes an afternoon looking for the storage code.
This is not an argument against ambition. If permanence were the thing users were showing up for, the answer would be to build it, and build it well. The point is narrower and more useful: an unbuilt promise is a liability, not a placeholder. It is not a feature that is almost done; it is a claim that is currently false. And the cheapest way to resolve a false claim is very often to stop making it.
So when you find the gap — the badge that never renders, the tagline the code cannot back up, the "coming soon" that has been coming for a year — add "delete the promise" to the options on the table. Sometimes the highest-leverage change you can make is subtraction, and the best feature you ship this week is the one you take out.