The Sunk Cost Trap That Kills Indian Startups
You're not alone. In India, I see this constantly: founders hold onto features because they've invested time. Six weeks on the analytics module. Three months on the API integration. Two quarters on the white-label system.
Zero users. But you can't delete it.
Why? Sunk cost fallacy. You've already spent the money and time. Deleting it feels like admitting failure. But here's the hard truth: maintaining a dead feature is spending money twice.
Every feature you keep costs you:
- Time to maintain it (15-30% of your sprint capacity)
- Cognitive load (developers think about it even when not touching it)
- Slower deploys (more code paths to test)
- Confusing onboarding (users see features they don't need)
- Demoralized teams (shipping for ghost users kills momentum)
One unused feature? Annoying. Five? You've stopped being a startup and become a feature museum.
The YC Framework: Measure, Cut, Repeat
Michael Seibel's advice is blunt: if nobody uses it, delete it. Not after 6 months of hand-wringing. Not after a retro with stakeholders. Now.
Here's the actual system:
1. Define Usage Ruthlessly
Not "might use later." Not "we built it for enterprise customers." Actual usage.
What counts:
- Daily active users interacting with the feature (not just logging in)
- Repeat usage (if they use it once then never again, it failed)
- Growth trajectory (usage flat or declining? It's dead)
What doesn't count:
- "Internal team uses it"
- "Early customer asked for it once"
- "It's part of our premium tier"
For a SaaS product at 200 users, a feature with 5 active users isn't niche. It's unused.
2. Set a Kill Timeline
Pick a metric. Track it for 30 days.
Trigger for deletion:
- Feature X < 2% of active users accessing it weekly
- Zero growth in 60 days
- Support tickets about it vs. monthly active users = terrible ratio
Once triggered, you have 2 weeks to build a migration path for the <1% who do use it. Then delete.
In India, I've seen founders wait 6-12 months. By then, you've lost 3 quarters of development velocity. Don't do this.
3. Document Before You Kill
Before deletion:
- Screenshot the feature
- Log usage data (you might need it for sales conversations)
- Email the handful of users: "We're deprecating this. Here's why. Use X instead."
This isn't cruelty. It's respect. Most won't care. Some will suggest an alternative.
The Non-Obvious Insight: Killing Features Accelerates Learning
Scott Belsky's Messy Middle nails this: constraints force creativity.
When you cut features, you're forced to ask: What's the core problem?
Let's say you built:
- Advanced scheduling (3 users)
- Custom branding (7 users)
- Role-based access (2 users)
You delete all three in a month. Now you have two developers back. What do you build?
You run a survey. You find 60% of users struggle with your onboarding flow. You rebuild it in 3 weeks. Retention jumps 12%.
You only learned this because you stopped maintaining the three features that felt important but weren't.
Dead features hide the truth. They make your metrics look busier than they are. They're the startup equivalent of a busy fool—lots of motion, zero direction.
How to Actually Do This in Your Company
Week 1: Audit List every feature built in the last 18 months. Export usage data for each.
Week 2: Kill List Anything with <5% active user engagement for 60+ days goes on the kill list.
Week 3: Communication Post in your Slack: "We're cleaning house. Features X, Y, Z are being removed [date]. If you use one, let us know why."
Wait 5 days. Usually, nobody responds.
Week 4: Execute Delete the code. Remove from docs. Remove from UI. Update your feature list.
India-Specific Context
Indian founders often over-build for hypothetical enterprise customers. You'll hear: "This feature is for future deals worth ₹50 lakhs."
Then the deal never closes. But you maintain the feature for 2 years.
Focus on what paying customers actually use. Today. Not what they might need.
VCs in India also respect execution speed. Showing you can ship faster by cutting cruft is more impressive than shipping slower with more features.
Takeaway
Next sprint, identify one feature zero% of users touch. Delete it. Not next quarter. Not after design review. This week.
Watch what happens: deploys get faster. Onboarding gets clearer. Teams focus.
Repeat monthly. This is how startups actually accelerate.