Stop Building Features Nobody Asked For

You’re doing it again

You have 12 users. You’re building an API.

Nobody asked for an API. Nobody even hinted at wanting one. But it’s a fun engineering problem, and you can already picture the docs page. So you spend two weeks on it instead of fixing the onboarding flow that’s losing you 80% of signups.

This is the indie hacker’s curse. When you’re the founder, the PM, and the developer, there’s nobody to stop you from building whatever feels most interesting on a Tuesday morning.

The symptoms

You know you’re in feature creep territory when:

• You’re adding dark mode before you have 50 users
• You’re building integrations with platforms none of your users are on
• You redesigned the settings page three times but haven’t talked to a customer in a month
• Your changelog has 10 entries and your MRR hasn’t moved

These are all real examples from indie hackers I’ve talked to. Smart people, building well-crafted features that nobody needed.

Why it happens

Building is comfortable. Talking to users is not.

When you build, you’re in control. You pick the problem, you pick the solution, you see progress. It feels productive. Ship a feature, commit the code, tweet about it. Dopamine.

When you talk to users, you might hear things you don’t want to hear. “I don’t understand what this does.” “I tried to sign up and gave up.” “I’m using your competitor because they do X.” That’s not fun. But it’s the only information that matters.

The rule: 5 users before any feature

Before you build anything new, talk to 5 users. Not a survey. Actual conversations. Ask them:

1. What’s the most frustrating part of using this?
2. What were you trying to do last time you used it?
3. Is there anything that almost made you stop using it?

If your planned feature doesn’t come up in any of those conversations, it’s a hobby project. That’s fine. Just don’t confuse it with product work.

What to build instead

Open your support inbox, your feedback channel, your analytics. Write down the top 3 things users actually complain about or struggle with. That’s your roadmap.

It’ll probably be boring stuff. Confusing onboarding. A broken flow on mobile. Missing CSV export. Nothing that makes for an exciting launch tweet.

But here’s the difference: fixing real problems retains users. Building fun features entertains you.

The hard question

Ask yourself honestly: am I building a product or a portfolio piece?

If it’s a product, the users decide what gets built. Your job is to listen, prioritize, and execute on their problems.

If it’s a portfolio piece, build whatever you want. Just don’t be surprised when the user count stays at 12.

Make it a habit

Every Monday, before you write any code, answer two questions:

1. What is the biggest problem my current users have?
2. Is the thing I’m about to build solving that problem?

If the answer to the second question is no, stop. Go talk to someone who uses your product. Then come back and build the thing that actually matters.

Your users are telling you what to build. You just have to stop long enough to listen.