I Spent 6 Months Building Features Nobody Asked For -- Here's What I Changed
July 21, 2026
I built a domain appraisal tool with 5 valuation sources, an AI summary, trademark checks, and historical sales data. Beautiful architecture. Used it myself, proudly showed it to other domain investors.
Two people used it. One was me. The other tried it and said “it’s too complex. I just want to know if a domain is worth buying.”
I spent 2 weeks building features nobody asked for. The user wanted a yes/no answer. I gave them a dashboard.
The Problem: Builders Build What Interests Them
When you can build things (code, systems, tools), the temptation is to build what fascinates you as a builder, not what solves problems for users.
I’ve done this repeatedly:
Domain-ion CLI. Powerful command-line tool for domain appraisal. I added 50+ features. Most users just want to check a batch of domains and see the best ones.
Content generation system. Complex multi-model pipeline with 4 providers, fallback logic, and content scoring. Users wanted “write a post about this topic.”
Order management system. I added analytics, charts, and export features before the basic order capture flow was solid. Users entered orders, forgot about them, and the charts showed nothing useful.
Every time, I built the advanced version before the basic version was validated. The result: wasted time and a complex tool with no users.
The Fix: Ask First, Build Second
I now follow a simple rule: talk to 5 potential users before writing any code.
Not “what features do you want” (they’ll say everything). Specific questions:
- “How do you handle X right now?” (current process)
- “What’s the most frustrating part?” (pain point)
- “If you could fix one thing, what would it be?” (priority)
- “Would you pay $X/month for a tool that does just that?” (willingness to pay)
Question 4 is the filter. If they won’t pay, they won’t use it.
What I Should Have Done
For the domain appraisal tool, I should have asked 5 domain investors: “How do you appraise domains now? What’s the hardest part?”
The answer would have been: “I check manually and it takes too long. I wish I could paste a list and get the top picks.”
Instead I built: “Enter a domain, see 5 valuation sources, AI analysis, historical trends, trademark risks, and comparable sales.”
The right answer was a 3-line output. I built a 30-line dashboard.
How You Can Do It Too
For builders (freelancers, founders, product people):
-
Identify the 20% that delivers 80% of value. Build that first. Nothing else.
-
Ship to one person. Not a beta launch, not a Product Hunt post. One real user who has the problem right now.
-
Watch them use it. Don’t ask “how is it?” – watch them click. Where do they get stuck? What do they ignore?
-
Add features only when users ask for the same thing 3 times. One person’s feature request is a niche. Three people’s is a pattern.
When This Doesn’t Work
If you’re building for yourself (internal tools, personal automation), build whatever you want. You’re the user.
If you’re building a platform play (marketplace, social, network effect), the “talk to 5 users” approach doesn’t scale. You need to validate the concept differently.
FAQs
Q: How do I find people to talk to?
A: Twitter, Reddit, Facebook groups, LinkedIn. Search for people talking about the problem you want to solve. DM them: “I’m working on X, would love your opinion.”
Q: What if I can’t find 5 people to talk to?
A: That’s a signal. If you can’t find 5 people who have the problem, there probably aren’t 50 who will use your solution.
Q: How do I know if someone’s feedback is useful?
A: Someone who has tried to solve the problem themselves (spreadsheet, manual process, workaround) and is frustrated gives useful feedback. Someone who says “that sounds useful” in theory gives useless feedback.
Q: What if the feature I built gets used by nobody?
A: Delete it. You learned something. The cost of deletion is the lesson fee.
Related: Build Your Own Tools – building for real needs vs hypothetical ones. Custom App vs SaaS – deciding what to build vs what to buy.