The first feature you kill: cutting what nobody uses

For months the job has been addition. You scaffolded a validated idea, wired up auth and billing, shipped a first version, launched, kept a cohort alive, made a data-driven roadmap call. Every one of those beats ended with your product doing something it did not do before. Building means adding, and adding feels like progress, so you keep doing it.

Then one day you open your own app and notice it has quietly become cluttered. There is a screen you forgot you built. A toggle in settings nobody has ever mentioned. A whole section of the nav that exists because six weeks ago it seemed important. Your product has accumulated the way a desk accumulates. And the most valuable move you can make this week is not to add the next thing. It is to kill one of these.

This is the beat the build advice almost never covers, because subtraction does not photograph as well as shipping. But at 3 to 30 customers, cutting a dead feature is one of the highest-leverage half-days of work available to you. Here is how to find the right one and remove it cleanly.

A dead feature is not neutral, it is a tax

The instinct that stops founders killing features is that a built feature feels like an asset. You paid for it once, in build time, and now it just sits there. Leaving it costs nothing. Right?

Wrong, and the gap between that instinct and reality is where a lot of solo products slowly bog down. A feature nobody uses is not a dormant asset. It is a liability you pay for every single week, in four separate currencies.

Support surface. Every feature is a thing that can confuse someone, break, or generate a ticket. A dead feature still throws the occasional error, still gets a bewildered "what is this for" email, still needs to keep working when you change something nearby. It expands the surface area of things that can go wrong for zero benefit.

Cognitive load on new customers. This is the expensive one. Every screen, toggle and menu item is one more thing a new customer has to understand or consciously ignore. A cluttered product has a slower, more confusing onboarding, and onboarding is where you win or lose the customers you worked so hard to acquire. The dead feature is not just sitting there quietly. It is actively making your first-run experience worse for everyone who never wanted it.

Maintenance drag. The code behind the feature does not freeze. It has to keep compiling, keep passing tests, keep not breaking when you upgrade a dependency or refactor the thing next to it. Every dead feature is a small tax on every future change you make, because it is one more thing your changes must not break.

Identity dilution. The subtlest cost and maybe the biggest. Your product is supposed to be obviously about one thing. Every feature that is not core blurs the answer to "what does this actually do". A tight product that does one job brilliantly is easier to describe, easier to sell, and easier to recommend than a sprawling one that does five jobs adequately. Each dead feature smudges your positioning a little.

Add those four up and a feature nobody uses is not free. It is a standing charge on your focus, paid weekly, forever, until you cancel it.

Why the standard deprecation advice does not fit you

Search for how to remove a feature and you will drown in enterprise deprecation playbooks. Announce it 90 days in advance. Build a migration wizard that moves customer data automatically. Roll the removal out gradually behind flags to cohort after cohort. Run a two-way communication programme. Document alternative workflows. Monitor sentiment throughout.

All of that is sound advice for a product with ten thousand users, where you genuinely cannot contact everyone and a botched removal makes the news. It is wildly oversized for you. You do not have ten thousand users. You have a number you can say out loud from memory, and you probably know most of them by first name.

That changes the whole shape of the problem. You do not need a migration wizard to serve the two people who touched the feature. You need to send two emails. You do not need a 90-day public sunset schedule. You need a week of watching to be sure nobody misses it. The heavyweight process exists to solve a scale problem you do not have yet, and importing it wholesale just gives you an excuse to never cut anything, which is how the clutter got there in the first place.

The solo-scale version is not careless. It is precise, personal, and fast.

Find the dead one

You already built the instrument for this on your roadmap-call. The same usage data that tells you what to build next tells you what to remove. If you added a lightweight event layer, a handful of events written to a Supabase table or a free analytics tier, you can answer the only question that matters: how many distinct customers have touched this feature in the last two or three months.

Distinct customers, not total opens. One obsessive user opening a screen forty times is not proof of life, it is one person. You are looking for features where the distinct-customer count over a real window is zero, or close to it. Those are your candidates.

If you never instrumented events, you are not stuck, you are just doing it by hand this once. Vercel Analytics shows you route-level traffic out of the box, so you can already see which pages of your app are ghost towns. For anything finer, ask Claude Code to add three or four events on the features you suspect are dead, wait a week, and read the result. Either way, the goal is the same: replace your gut feeling about what is unused with a small, honest number.

The kill test: dead versus quiet but load-bearing

Here is the nuance that separates a clean cut from an expensive mistake. Low usage is a reason to investigate, not an automatic reason to kill. Some features are barely touched and absolutely must stay.

Picture a data-export feature that customers use exactly once a year, at tax time. Eleven months of the year its usage is zero. Read usage alone and it looks dead. But it might be the single reason three customers stay subscribed all year, because they know it will be there in January. That is not a dead feature. It is quiet but load-bearing, and killing it would quietly cost you three customers who would not even know why they were leaving until the moment they needed it.

So the kill test is two questions, and a feature has to fail both:

1. Usage. Does any meaningful number of distinct customers actually touch it over a real window.
2. Dependence. Is any revenue or retention attached to it. Did anyone buy because of it, stay because of it, or ever mention it in a cancel reason or a sales call.

If the honest answer to both is no, the feature is genuinely dead and safe to remove. If it fails usage but passes dependence, it is load-bearing and it stays, maybe with a note to make it more discoverable. Requiring both to fail is what stops you amputating something that was quietly holding a customer in place.

Kill it cleanly, in an afternoon

Once a feature fails both tests, do not agonise. Remove it in three moves.

First, tell the one or two people who ever used it, personally. Pull the list of distinct users, and if it is short, which it will be, email them directly. Explain that you are removing the feature to keep the product focused, and offer to help with whatever they were using it for. This is not a mass "we are sunsetting" announcement. It is a human message to a named person, and it is the entire reason you can move faster than a big company: you can actually talk to everyone affected.

Second, hide before you delete. Turn the feature off behind a flag so it disappears from the interface but the code still exists. Leave it hidden for a week or two and watch for anyone bumping into its absence. A flag is a boolean and a conditional, and Claude Code can add one in minutes. This is your cheap insurance: if your usage read missed someone, they surface now, while reversing costs you a single line.

Third, once the week passes quietly, delete the code for real. This is the step that actually cancels the tax, and it is a task Claude Code is genuinely good at, because removal has a clear shape. Point it at the feature's routes, components and database calls and ask it to map everything that touches them first. Then have it strip out the dead paths, run your existing tests, and hand you a reviewed diff. Keep the underlying data in your database even as you delete the interface. Storage is cheap and thrown-away data is the one thing you cannot get back. You keep the judgement about what dies. It does the tracing and the mechanical surgery.

What you get back

The reason to do this is not tidiness for its own sake. It is what the removal returns to you.

Your landing page gets shorter and clearer, because you have one fewer thing to explain and one more reason your product reads as being about a single job. Your onboarding gets faster, because every new customer has one fewer screen to make sense of. Your codebase gets lighter, so the next real feature is a little easier to build because there is less to avoid breaking. And you get the quiet, underrated satisfaction of a product that feels deliberate rather than accumulated.

Subtraction compounds the same way addition does. Cut one dead feature and the product is a little sharper. Make it a habit, one cut every few weeks whenever the usage data flags something truly dead, and over a year your product stays lean while your competitors' bloat. A focused product built by one person who ruthlessly removes what nobody uses is a genuinely hard thing to compete with.

When not to cut, and when to graduate

Two guardrails. Do not turn this into a purge. You are looking for genuinely dead features, the ones that fail both usage and dependence, not for an excuse to rip out anything with modest numbers. Aggressive cutting is as much a failure mode as never cutting, and it burns the customers who liked the quiet features. One deliberate removal at a time, each one earned by the data, is the whole discipline.

And know when this stage ends. The personal, email-the-two-people approach works precisely because you are small enough to reach everyone. Around 100 customers that stops being true, and that is when you graduate to the lightweight version of the formal process the enterprise playbooks describe: a short deprecation note, a couple of weeks of warning, a changelog people actually read. Until then, you have a superpower the big companies would love and cannot buy back: you can remove a feature this week, talk personally to everyone it affects, and have a cleaner product by Friday.

You spent months learning to add the right things. Learning to remove the wrong ones is the same skill, pointed in the other direction, and it is what keeps the thing you are building sharp enough to win.