Built a product nobody wants? Fix the order, not the code

The short answer

This guide is the reverse sequence, step by step, plus a diagnosis for the case where you have already launched with zero users. It is not a guide to generating ideas from scratch; for that, start with how to come up with a business idea. This one is for the founder who already built something and watched nobody arrive.

Idea, code, launch, 0 users: the sequence behind it

A founder on r/founder (78,000+ members) posted this October asking how to come up with an idea people actually want. They had built more than 20 products in a few years and said about 90% failed. Their old process fit in one line:

“Come up with an idea → Code it → Launch it → 0 users.”r/founder, original post

The new one adds the step that was missing:

“Come up with an idea → Talk to people → Pivot → Start over → Launch → Ready made customers.”r/founder, original post

Same founder, same skills, different order. Later in the thread they added the line that sums up this whole guide:

“If you properly evaluate the data you have before starting the work, you won’t need to change direction for the 14th time.”r/founder, original poster in the comments

The top-voted reply rejected the premise of “coming up with” anything:

“You dont ‘come up with an idea’, you find yourself in the right place, at the right time, to identiy a problem.”r/founder, top comment

The thread is not unusual. The top Google result for “built a product nobody wants” is an r/startups post titled I spent 14 months building a product nobody wanted. The founder describes a B2B workflow tool where the build never stopped:

“Every week we shipped new features. Every month we added something else.”r/startups, 14 months building a product nobody wanted

“We got some users, a few demos, some trial signups. But nobody was excited”r/startups, same post

Two founders, two markets, one pattern: the product was finished before anyone outside the team had a say in it.

Why founders build products nobody wants

No market need is the most cited reason in startup post-mortems: CB Insights put it at 42% in its analysis of failed startups. The threads above show three habits that produce it.

1. Building inside the bubble

Code needs focus, and focus faces inward. The r/startups founder said it directly:

“Meanwhile I was sitting in my own bubble building features nobody had asked for”r/startups, 14 months building a product nobody wanted

A commenter on the same post described the moment the bubble broke: after five customer interviews, “the thing people loved was a tiny feature I built in an afternoon as an afterthought. the ‘core product’ I spent months on? nobody mentioned it unprompted.”

2. Treating features as the fix

When usage is flat, the instinct is to ship more. In the r/founder thread, a commenter asked whether the founder focused on “packing up more features instead of an MVP that solves a targeted problem?” The reply:

“Adding new features doesn’t really change much; on the contrary, it only complicates the product.”r/founder, original poster

3. Asking for opinions instead of watching money

“Would you use this?” gets a polite yes. A widely shared r/startups list of founder lessons opens with “Validate idea first. I wasted at least 5 years building stuff nobody needed” and later adds “Sell features, before building them.” Another founder on r/startups found the same gap between talk and payment with beta users:

“The feedback and behavior of users who don’t pay is not at all a reflection of actual paying users.”r/startups, founder on free beta users

All three habits have the same root. The founder decides what to build before checking whether anyone already spends money on the problem. Our data shows why that check matters more than any survey.

What 560,000+ reviews say about “I’d pay for that”

A common shortcut for finding an idea people will pay for is to search for “I’d pay for” posts. We tested how often that phrasing appears in the places where paying users write most: software reviews and app store reviews. It almost never does.

That is about 1 review in 700. And the few that do say it are weaker than they look:

• About a third hedge it. 33% of the matches put “if”, “but”, “for a” or “one-time” right after the phrase: I would pay, but not this price, not as a subscription, not until it works.
• Most are said while complaining. In the 125,000+ app store reviews we can link to an app, 58% of the “I’d pay” lines sit in 1- and 2-star reviews (against 65% of all linked reviews). The phrase is usually a condition attached to a complaint.

“I would happily pay a small fee per month or annually, but not at $40 a month just so I can keep track of my collection. It’s time to look elsewhere, I guess.”App store review, 3 stars, inventory app

Now compare the cons section of Capterra reviews, written by people who already chose and pay for a tool:

This is the finding the rest of the guide builds on. Paid demand rarely announces itself as a promise. It shows up as a complaint about something people already pay for. On Capterra, missing-capability complaints outnumber “I would pay” lines by more than 250 to 1. And 88.8% of those complaints come from reviewers who rate the product 4 or 5 stars: customers who are staying, paying and still asking for more.

“It was missing some features that would be helpful so I then needed to get another tool to fill the gaps, it doesn’t integrate with many other systems”Capterra review, 5 stars, billing and invoicing software

“The exercise prescription is not user friendly so we use another program that costs a lot of money which is frustrating.”Capterra review, 4 stars, chiropractic software

Each of those is a person who has already proved willingness to pay, twice. That is a stronger starting point than any survey answer. You can read these complaints by category in the Capterra analysis, and our guide to validating a SaaS idea with real reviews before coding covers the reading in more depth.

Where paying users ask for more

The missing-capability share is not flat. Across the 74 Capterra categories with 1,000+ reviews each (108,000+ reviews in total), the average is 15.2%. Practice and appointment software sits well above it, which is what you would expect where small operators run their whole day on one tool.

Two readings matter for someone deciding what to build. A high missing-capability share with a modest price share (Electronic Medical Records, Classroom Management) says users would rather have more than pay less: a feature or add-on wedge. A high price share (Billing and Invoicing, Competitive Intelligence) says the tool does the job but costs too much for part of its base: a cheaper, narrower wedge. Both start from people already paying.

“I wish it had a referral program or points tracking system. I want to be able to keep track without doing it manually.”Capterra review, 5 stars, appointment reminder software

Category shares are a place to start reading, not a verdict. For a ready-made list of problems already scored this way, see business ideas that solve real problems.

How to avoid building a product nobody wants: the 8-step fix

Each step puts evidence before effort. Steps 2 to 6 need no code at all. Step 7 is where the code starts.

Step 1: Freeze the roadmap

Stop shipping for two weeks. If usage is flat, new features add weight, not users. Write two sentences: who you built this for, and what that person paid for before your product existed. If you cannot answer the second, steps 2 to 4 will.

Step 2: Start from a complaint, not an idea

Collect 20 or more complaints about the same problem from unrelated people, in their own words. The best sources are unprompted: the cons section of software reviews, 1- and 2-star app reviews, niche subreddits and freelance job posts. One complaint is an anecdote; twenty from different people is a pattern. The method is laid out in how to find problems to solve for business ideas, and how to find business ideas on Reddit covers the forum side. A commenter on the r/startups post described the habit that fixed it for them:

“I spend a full week just lurking in communities where my target users hang out. not posting, not promoting, just reading what they complain about in their own words.”r/startups, comment on 14 months building a product nobody wanted

Reading at scale is faster with the complaints already grouped: the pain points search covers 1M+ complaints across Reddit, G2, Capterra and the app stores, and the complaint analysis guide explains the scoring.

Step 3: Find the tool they already pay for

For each complaint, name what the person uses today: a product, a spreadsheet, a freelancer, an agency. Money moving toward the problem is the strongest demand signal there is. If nobody pays for anything, that is usually a warning, not an open field. Our Stripe Index shows 30,000+ companies taking payment by category, which tells you quickly whether a market already charges.

Step 4: Read that tool’s cons, not its pros

Pull the negative and mixed reviews of the paid tool and sort the cons into four piles: missing capability, price, integration, and “we bolted on a second tool”. The biggest pile is your wedge. On Capterra overall, missing capability wins at 14.9% of reviews, ahead of integration at 8.5% and price at 7.2%. The Capterra analysis walkthrough and how to analyze app store reviews show how to do this per product. An existing competitor is not a reason to stop; it proves the market pays.

Step 5: Talk to ten of the people complaining

Reach the people who wrote the complaints, or people who match them closely. Ask about the last time the problem happened, what it cost them and what they already tried. Do not pitch. The r/founder thread raised the obvious next question, and nobody answered it:

“But where? Most subReddits don’t seem to allow market research or ask people for feedback”r/founder, reply to 'ask on Reddit'

The answer is the complaint itself. A reviewer who wrote three sentences about a missing feature, or a poster who described a workaround, is already pre-qualified. For the communities that allow outreach and the ones that ban it, see where to find people to talk to about your idea. Use our customer discovery questions for what to ask once you reach them.

Step 6: Ask for money before you write code

Offer a paid pilot, a pre-order or a done-for-you version delivered by hand. A deposit, a signed pilot or a card on file counts. A compliment, a waitlist sign-up or “I would pay for that” does not; the table above shows how rarely even that phrase appears, and how often it comes with conditions. Test willingness to pay with a paid pilot has the scripts.

Step 7: Build only what removes the complaint

Ship the smallest version that fixes the one complaint people paid to remove, to the people who paid. Every other feature waits until a second paying customer asks for it. This is the opposite of the 14-month build: a narrow product with buyers waiting, instead of a broad one with none.

Step 8: Set kill rules in advance

Write the thresholds that end the idea before you start, so a sunk week does not become a sunk year. The kill rules section below lists five, built from founders who learned them the hard way.

Already launched with zero users? Diagnose before you add anything

If the product is live and nobody is using it, the reflex is to add features or redesign the landing page. Diagnose first. Zero users has three possible causes, and they need different fixes.

Most zero-user launches fail row 1, and the r/founder founder later said distribution was part of their story too. Rows 2 and 3 are worth fixing only once row 1 passes. If it does, how to get your first 100 SaaS users and how to get your first customer cover reach.

Talk to the people who tried it and left before anyone else. A commenter on the r/startups post said that moved things more than studying competitors: the people “who churned or never converted” will “tell you exactly what story you’re failing to tell.” Another named the harder truth:

“finding people with the problem is often harder than building the solution itself.”r/startups, comment on 14 months building a product nobody wanted

Kill rules: five thresholds to set before you build

The most useful comment on the r/startups thread was a list of reasons to cancel. Three of its lines map directly onto the evidence in this guide:

“If almost nobody is complaining about the competition: Cancel.”r/startups, comment on 14 months building a product nobody wanted

“If people claiming to have a problem never searched for a solution: Cancel.”r/startups, same comment

“If those claiming to have a problem spent a grand total of zero to fixt it: Cancel.”r/startups, same comment

Turned into thresholds you can check before writing code:

1. Fewer than 20 independent complaints about the same problem after a week of reading. Move on.
2. No tool, service or workaround anyone pays for. If money never moved toward the problem, it probably will not start with you.
3. The incumbent’s reviews have no repeated con. If paying users are content, there is no wedge. On Capterra, 15.2% of reviews in the average category name a missing capability; a tool well below that is hard to undercut on features.
4. Ten conversations, zero people agree to pay a deposit or pilot fee. Stop and revisit the problem, not the pitch.
5. You would need to explain the problem to the people who have it. If they do not already describe it in their own words, you are selling education, not relief.

Write these down with dates. Our free business idea evaluator scores an idea against similar criteria in a few minutes, and how to validate a startup idea goes deeper on each test.

How to come up with an idea people will actually pay for

If you are starting over, the r/founder thread’s advice converges on one move: stop generating ideas and start noticing problems.

“Stop trying to come up with ideas. Walk around and listen and talk to people. They have ideas if you listen closely enough. Frequently, the people who have them refer to them as ‘problems’”r/founder, comment

Put that together with the review data and an idea people will pay for has three properties:

• It is a complaint first. Many unrelated people describe it unprompted. Another commenter: “Most people start from the industry they work in”, because that is where they hear the complaints.
• Money already moves toward it. Someone pays a tool, a person or their own time to deal with it today.
• The current fix falls short in a repeatable way. The same con shows up across reviews: the missing report, the absent integration, the price that pushes the smallest users out.

“Would pay more for ability to use on and between multiple devices, especially laptop.”App store review, 4 stars, rent tracking app

That reviewer is the shape to look for: already a user, already satisfied enough to stay, naming the exact gap and offering more money to close it. For the full idea-generation process see how to come up with a business idea, and if you are starting with nothing at all, I want to start a business but have no ideas.

Pre-code checklist

Tick every line before step 7. If one stays unticked, the order is still wrong.

1. Freeze the roadmap. Stop shipping features for two weeks. More features on a product nobody uses only add weight. Write down who you built it for and what they paid for before you existed.
2. Start from a complaint, not an idea. Collect 20 or more complaints about the same problem from different people, in their own words, from reviews, forums and job posts. One complaint is an anecdote. Twenty is a pattern.
3. Find the tool they already pay for. Name the product, spreadsheet, freelancer or agency the complainers use today. If you cannot find any money moving toward the problem, treat that as a warning, not a gap.
4. Read that tool's cons, not its pros. Pull the negative and mixed reviews of the paid tool. Sort the cons into missing capability, price, integration and a second tool bolted on. The biggest pile is your wedge.
5. Talk to ten of the people complaining. Contact people who wrote the complaints or match them closely. Ask about the last time the problem happened, what it cost and what they tried. Do not pitch.
6. Ask for money before you write code. Offer a paid pilot, a pre-order or a done-for-you version. A deposit, a signed pilot or a card on file counts. Compliments and waitlist sign-ups do not.
7. Build only what removes the complaint. Ship the smallest version that fixes the one complaint people paid to remove, to the people who paid. Everything else waits for a second paying customer to ask.
8. Set kill rules in advance. Write the thresholds that end the idea before you start: no paid tool in the market, no money spent by the people with the problem, no one agreeing to pay after ten conversations.

For a longer framework with scoring, see our idea validation hub and how to find product-market fit. For the wider failure numbers, read startup failure statistics.

What this data cannot tell you

The review figures come from keyword matching on 560,000+ reviews, read on October 9, 2026. Five limits matter:

• Keywords, not meaning. “I wish” also catches “I wish I had found this sooner”, and “willing to pay” also catches “not willing to pay”. The shares are approximate; the gap between them (more than 250 to 1 on Capterra) is too large for that noise to close.
• Reviews skew positive. 91.5% of Capterra reviews rate 4 or 5 stars, so the 88.8% of gap complaints from 4- and 5-star reviewers is close to the base rate. The point is that satisfied, paying customers still name gaps, not that they name more.
• Review sites are not the whole market. People who never bought software, and buyers who never write reviews, are missing. A problem with no reviews can still be real; it just has no paid tool yet, which is its own risk.
• Category coverage is uneven. The Capterra scrape is denser for categories early in the alphabet, so the category table compares what we hold, not every category. Treat it as a reading list.
• Reddit quotes are self-selected. Founders who post failure stories are not a sample of all founders. We use them for voice and phrasing, not for rates.

Methodology and sources

We ran read-only SQL against BigIdeasDB’s review tables on October 9, 2026. Willingness-to-pay phrasing was matched case-insensitively on “would pay” (with “gladly”, “happily”, “definitely”, “totally”), “I’d pay”, “willing to pay”, “happy to pay”, “gladly pay”, “happily pay”, “take my money” and “shut up and take”, across title and body (and, for Capterra, pros and cons). Hedged matches were those followed within 80 characters by “if”, “but”, “for a”, “one-time” or “once”, or preceded in the same sentence by “if”. Capterra cons were matched on whole words for missing capability, price, integration and second-tool language. Category shares use categories with 1,000+ reviews. All counts are rounded down with a “+”.

Frequently asked questions