The month I killed the feature everyone asked for at $14K MRR: a founder diary (2026)

By the numbers, the month I reached $14,000 MRR looked like a straight line up. Roughly 380 paying accounts. A product people said they loved. And a shiny new feature, the one thing the customer survey had begged for, sitting right in the main navigation.

Then I looked at who actually opened it. And I had to admit the most expensive thing I built that year was the thing everyone told me to build.

Quick answer (2026): At about $14K MRR and roughly 380 paying accounts, I shipped the single most-requested feature from my customer survey, a custom report builder. Six weeks of work. Ninety days later it had been opened by around 3 percent of active accounts and used more than once by a handful. It generated close to a fifth of my support load. So I deprecated it. Almost nobody cancelled. The lesson: a request is a signal to investigate, not an order to build, and the real cost of a feature is not the six weeks to ship it, it is the years you carry it.

The survey that felt like a mandate

I did what every "listen to your customers" post tells you to do. I sent a survey. About 210 people answered, which for a small B2B SaaS felt like a landslide.

One request dominated. Roughly 44 percent of respondents wanted "better reporting," and a loud subset wanted to build their own reports: pick the columns, pick the date range, save it, export it. Comment after comment. "This is the one thing keeping me from upgrading." "If you had custom reports I'd move my whole team over."

I read those comments the way a founder low on confidence reads anything. As a promise. Build this, and the upgrades come.

So I built it. Six weeks, a drag-and-drop report builder, more edge cases than I want to remember. I even pulled in a contractor for two of those weeks. It shipped. It demoed beautifully. I put it in the primary nav because, obviously, this was the headline.

What the usage data actually said

Ninety days later I did the thing I should have designed before I wrote a line of code. I looked at who used it.

Read those two ends against each other. About 3 percent of accounts touched the thing, and it generated close to 18 percent of my support tickets. It had two recurring bugs I never fully killed. And it had quietly become the reason a database change I needed took three times longer, because the report builder queried tables in ways nothing else did.

The feature everyone asked for was used by almost no one and maintained by only me.

I did not want to believe it, so I went looking for whether I was a special case. I am not. Pendo's 2019 Feature Adoption Report found that 80 percent of features in the average software product are rarely or never used. Two decades earlier, a Standish Group study reported by Martin Fowler at XP 2002 found 45 percent of features were never used and only 20 percent were used often or always. My little report builder was not an anomaly. It was the base rate.

Why "asked for" and "used" are different numbers

Here is the gap I had walked straight into. A request tells you someone can imagine wanting a thing. Usage tells you whether the thing, once it exists, is worth the friction of learning it. Those are not the same measurement, and the distance between them is where roadmaps go to die.

The people who asked for custom reports were mostly imagining a version of themselves who had time to sit down and build a report. That person rarely showed up. What they actually wanted was one specific number, delivered without effort. A report builder made them do work. The two customers who stuck with it had a genuine ongoing need. The other 208 survey responses were a hypothesis I had treated as a purchase order.

I had also confused volume with value. Forty-four percent is a big number in a survey. It is not a big number of accounts who will change their behavior, and it says nothing about how often, or whether they will pay more. I never asked the follow-up questions: how often would you run this, and would it change your plan? Those two questions would have saved me six weeks.

Killing it, and the churn that never came

Deprecating a feature you shipped with pride is a specific kind of awful. It feels like admitting the survey was wrong, which feels like admitting I was wrong to trust the people paying me.

I gave 30 days notice. A short, honest in-app note and an email to the eleven accounts who had ever opened it: this feature is being retired on this date, here is the one export that replaces the common case, reply if this breaks something for you.

I braced for a wave. Three accounts replied unhappy. Two of them were the genuine power users, and for them I built a tiny, boring, one-click export that covered 90 percent of what they actually did, in about a day. In the 60 days after the removal, zero accounts cancelled and named the report builder as the reason. The catastrophe I had imagined was three emails.

What I got back was real. Somewhere around a day and a half a week of maintenance, support, and mental overhead vanished. My support load dropped noticeably, which mattered more than I expected, because reactive weeks had been eating my building time the same way they did in the month support tickets ate my week at $25K MRR. Removing surface area is one of the few things that reduces support without you answering a single ticket faster.

I put the reclaimed time into fixing onboarding, the thing usage data actually pointed at. MRR held at $14K and drifted up toward $15K over the next two months. I will be honest and call that correlation, not proof; I changed more than one thing. But the product got simpler and the number did not punish me for it. That is the opposite of what the survey had made me fear.

Subtraction as a growth move is not intuitive, and it took me a second time to trust it. When I later pulled a whole pricing tier, in the month I killed my free plan at $16K MRR, I went in far less afraid, because I had already learned that removing the thing people claimed to want rarely produces the exodus you picture.

The one takeaway

If you take one thing from this, take the rule I now run every request through before it touches the roadmap:

1. Treat a request as a question, not an instruction. When customers ask for a feature, ask back: how often would you use this, and would it change what you pay? "I want it" and "I would use it weekly and upgrade for it" are different answers, and only the second one justifies six weeks.
2. Define the success metric and the sunset trigger the same day you greenlight the build. Write down what usage would make this feature worth keeping, and what usage would mean you remove it. If you cannot name the number, you are not ready to build.
3. Price a feature by its lifetime, not its build time. Six weeks to ship is the small cost. The support tickets, the edge-case bugs, the migrations it complicates, the onboarding it clutters, that is the bill, and it arrives every month for years. A feature you are not allowed to kill is not an asset. It is a liability wearing an asset's clothes.

The month I killed the feature everyone asked for is the month I stopped mistaking the loudest request for the most valuable one. The survey was not lying to me. I was just reading it as a mandate when it was only ever a hypothesis.

This is a composite founder diary. The company, segment, and exact dates are anonymized, and all figures are self-reported and rounded to protect the founder's privacy. The pattern, the numbers, and the decision are faithful to real accounts I have worked with; no quotes or MRR figures are fabricated beyond the rounding and anonymization noted here.