We audited every control on our own operations board and asked one question of each: does this actually persist anything? The answer for a meaningful number of them was no.
They were not broken. They were scaffolding — built to make an early demonstration coherent, never wired, and then simply not removed. They animated. They gave feedback. They looked exactly as functional as the controls beside them that did real work.
Why this is worse than a missing feature
A missing feature is an honest absence. A user notices it, asks for it, and the conversation is straightforward. A control that responds and does nothing is a claim, and every claim a product makes that turns out to be untrue spends credibility that the true claims then have to earn back.
It is also corrosive internally. Once a team is comfortable with three controls that only look real, the fourth is easy. The standard for what counts as done quietly moves.
A control that lies is worse than a missing feature, because a missing feature does not teach the user to distrust the ones that work.
Delete, do not wire
The instinct is to implement them — they are already designed, the surface exists, how hard can it be. We deleted instead, on the grounds that the demand for each was exactly zero. Nobody had asked for them, because nobody knew they were not real.
Where a control represented something genuinely planned, it was replaced by an honest statement of what the system does today rather than an interactive element that implies more. Where it represented nothing, it went.
The rule that came out of it
Scaffolding gets a removal date at the moment it is built, and the demo it exists for is the date. If it survives the demo it becomes debt, and this particular debt accrues in a currency — user trust — that is very slow to earn and very fast to spend.