We deleted a fully tested feature 48 hours after shipping it

On a Monday we shipped a feature to every organisation on our platform. It had a written spec, a careful implementation and a full test suite. On Wednesday we deleted it.
Nothing was broken. The feature worked exactly as designed. The problem was simpler and more expensive: nobody needed it. The table sitting right next to it on the same page already answered the question it was built to answer.
This post is about what we changed in how we decide what to build, because a good test suite turned out to be no protection at all against this kind of mistake.

Tests answer "does it work", not "should it exist"

Our feature was a comparison panel for the prompts our customers track. You could pick two prompts and see them side by side. It looked useful in the spec. It was useful in isolation. But the prompts table already showed every prompt with the same columns, sortable, in one place. Comparing two rows of a table is something people already know how to do.
Every check we had was green. Types, lint, unit tests, component tests. None of them can fail on "this duplicates something users already have", because that is not a property of the code. It is a property of the product.
The only place that question can be asked is before the work starts.

The filter we use now

Before an issue gets scheduled, we ask one question: what data does this need, and do we already hold it? The answer sorts every idea into one of four buckets.

• We hold the data and do not show it. The cheapest work there is.- We show the data wrongly. Cheap, and it is where trust is won or lost.- We do not hold it, but we can derive it from data we already fetch.- We do not hold it and must start collecting it. A new pipeline, a vendor, or setup on the customer's side.Buckets 1 and 2 are where credibility comes from. Bucket 4 is where features get built and then deleted. So bucket 4 work now needs a named customer who asked for it, not an inference from a competitor's feature list. ## The red 0% The same week, we fixed a bug that shows the other side of this. Every prompt that had never been tested displayed a red 0% in the dashboard. To a customer, that reads as "you are invisible here". In reality it meant "we have not measured this yet". Those are very different statements, and the dashboard was making the wrong one to every customer. The fix was to render a count we already stored on every row. One field, one afternoon. A number that had been lying started telling the truth. No new pipeline, no new screen. That is a bucket 2 fix, and it did more for user trust than the comparison panel ever could have. ## An empty table is not a missing feature One more lesson from the same period. Someone opened an issue asking us to show device, browser and country on a visitor card. The whole pipeline already existed. It had shipped a few hours earlier. The table simply had no rows yet. If you look at production data and see nothing, check when the code that fills it shipped before you conclude it does not exist. It is an easy mistake, and it is how teams end up building the same thing twice. ## Three checks before we write an issue
• Is it already fixed? Our issues only auto-close from the release branch, so open issues routinely describe work that already shipped.- Is it already built? See the empty table above.- Which bucket is it? If it is bucket 4, name the customer.## What we did not do We did not add a process document with approval steps. Process tends to grow into the thing it was meant to prevent. The filter is a single question that anyone on the team, or any coding agent working in the repo, can ask in thirty seconds. We also did not stop building new things. We just stopped pretending that "well tested" and "worth having" are the same claim. If you have deleted a feature shortly after shipping it, I would like to hear what tipped you off.