Here is something I see constantly in indie hacker communities right now. Someone ships three apps in a month using Claude Code and Cursor, posts about it, gets some attention for the shipping velocity, then quietly mentions in the comments that none of them have users.
The tools made them faster. The tools did not help them figure out what was worth building.
This is the quiet crisis underneath all the vibe coding content. Execution is no longer the bottleneck. A solo developer in 2026 can go from idea to deployed product in a weekend. That is genuinely remarkable. It also means that picking the wrong problem to solve now costs you a weekend instead of three months, but you can make that mistake twelve times a year instead of twice.
The speed makes it easier to learn, yes. But it also makes it easier to stay busy while making no real progress.
I have been guilty of this. I have shipped things because I could, because the technical challenge was interesting, because I thought “someone must want this.” The failures I remember most were not failures of execution. They were failures of problem selection. I built something well and nobody needed it.
The question that solves this is not “how do I build faster.” It is “how do I know whether this problem is real enough to be worth building for.”
What Changed When Building Got Easy
Two years ago, the bottleneck for a solo developer building a SaaS product was time. You had an idea, you had skills, but turning the idea into a working product took months. That time acted as a natural filter. You were forced to think about the idea for a while before you could validate it through a real product. You interviewed potential users because you had to fill that time somehow. You built small things to test assumptions because you did not have the capacity to build the full thing.
That filter is mostly gone now. You can go from idea to MVP in a weekend and spend the next few weeks wondering why nobody is signing up.
The irony is that the best indie hacker success stories have always been about problem selection, not execution speed. Pieter Levels succeeds because he spends his time in communities where he can directly observe what people struggle with. The founders who hit their first dollar in revenue fastest are usually solving problems they have personally experienced. They do not need extensive research because they are their own primary user.
What changed is that execution speed no longer compensates for weak problem selection. When it took six months to build, you had time to discover problems with your assumption and pivot before launch. When it takes a weekend, you can launch before you have learned anything.
The Founder-Market Fit Concept That Actually Matters
Product-market fit gets discussed constantly. Founder-market fit gets discussed rarely, which is strange because for a solo founder, it is more actionable.
Founder-market fit is not about passion (though that helps). It is about information asymmetry. Do you know something about this problem that most people building in this space do not know?
If you have worked in healthcare for five years and you are building a scheduling tool for small clinics, you know the regulatory constraints, the workflow realities, the way staff actually behave versus how software designers imagine they behave. That knowledge is a competitive advantage that no amount of user interviews will fully replicate for a developer building in the same space without that background.
If you are building a tool for a problem you have personally struggled with and solved, you know the actual friction points. You know which features feel important in a demo and which ones matter when you are doing the work at midnight. You know the workarounds people currently use, which tells you something about their tolerance for pain versus their price sensitivity.
The practical version of founder-market fit validation: before you start building anything, write down three things you know about this problem that are not obvious from the outside. If you cannot identify three, that is a signal. It does not mean you should not build it. It means you should go learn those things before you start, or find a co-founder who already knows them.
A Seven-Day Validation Framework
This framework is specifically for developers who are good at building and want a structured way to slow down before starting. It is designed to run in seven days without writing any code.
Day one: Problem articulation. Write a single sentence describing the problem you are solving, who has it, and what they currently do instead. Do not describe your solution. Describe the problem. “Small marketing agencies waste two hours per client per week manually exporting data from three different platforms and reformatting it for client reports” is a problem statement. “A unified dashboard for marketing agencies” is a solution statement masquerading as a problem.
The clarity of your problem statement predicts a lot about whether you have actually identified a real problem or you are pattern-matching to “this seems like it should exist.”
Day two: Find the people. Identify three online communities where people with this problem spend time. Subreddits, Slack communities, Discord servers, LinkedIn groups, niche forums. Search those communities for the language people use when talking about the problem. Do not post anything yet. Just read.
If you cannot find communities where people are actively discussing this problem, either the problem is not painful enough to drive behavior, or you have misdescribed the people who have it.
Day three: Read the complaints. Go back to those communities and read specifically for complaints. What do people say they wish existed? What workarounds do they describe? What tools do they say are close but not quite right?
The language people use in these complaints is valuable beyond validation. It is the language that belongs in your landing page copy, your onboarding flow, and your support documentation. People who have been frustrated by a problem long enough to post about it have figured out exactly how to describe it.
Day four: Talk to three people. Reach out to three people in those communities and ask if they would talk for fifteen minutes about how they currently handle the problem. Do not mention your product. Do not pitch. Ask them to walk you through exactly what they do today.
Three conversations is not statistically significant. It is enough to test whether your problem statement is accurate. You are looking for whether the problem you described matches the problem they are actually experiencing. Frequently they will describe the problem differently, and the way they describe it is more accurate than the way you described it.
Day five: Pre-sell. Write a landing page. Do not build anything. The page describes the problem, describes the solution you are planning, and has a form where people can enter their email and optionally pay a deposit to be a founding member.
Drive traffic to this page from the communities where you found people in days two and three. A week of visibility in the relevant communities, a few cold DMs to people who expressed the problem clearly, maybe a post on X describing the problem and asking if others have it.
You are not looking for conversions at scale. You are looking for a signal. If ten people see the page and nobody is interested enough to enter their email, that is information. If someone pays a deposit before there is any product, that is a different kind of information.
Day six: Study what is already out there. Look at every existing product that overlaps with what you are planning to build. Not to see if the space is “too crowded,” but to understand why none of them fully solve the problem. The gap in the existing solutions is where your product lives.
The saaspocalypse conversation is real: there are a lot of SaaS products for common problems. But “crowded” categories often have underserved segments. Five tools for enterprise teams with six-figure deal sizes does not mean there is no room for a tool targeting solo operators at one-tenth the price with one-tenth the complexity.
Day seven: Decision. Review what you learned. Does the problem exist at the scale and intensity you assumed? Do you have founder-market fit (three things you know that outsiders do not)? Did anyone pre-sell? What would it take to get the first paying customer within thirty days of launch?
If you cannot answer that last question with a specific plan, you have not validated enough.
Niche Selection and Why Specificity Wins
The most common validation mistake I see is stopping at “there is a market for this” and not going further to “this is the specific market where I can win.”
Building something for everyone is the same as building something for no one. Not because broad markets are bad, but because as a solo founder, you cannot reach everyone. Your distribution channels are limited. Your support capacity is limited. Your ability to understand and serve deeply varied use cases is limited.
The specific niche version of this: a project management tool for everyone is competing with Asana, Linear, Notion, and a hundred others with engineering teams larger than your entire life. A project management tool specifically for documentary filmmakers managing research, footage, and interview transcripts has a much smaller market and also much lower competition, a defined distribution channel (filmmaker communities and film schools), and use cases specific enough that the big tools genuinely underserve them.
The question for niche selection is not “is this big enough.” It is “can I become the obvious choice within this specific niche.” A thousand paying customers in a well-defined niche is a real business. Ten thousand signups across a fragmented audience without a clear reason to choose you over the alternatives is not.
How to find a defensible niche: start with a category (project management, invoicing, scheduling, documentation) and ask “who uses this in a way that the generic tools do not serve well.” Look for industries with specific terminology, regulatory constraints, or workflows that general tools do not accommodate. Those specifics create natural barriers that protect you even when larger competitors notice your category.
The Distribution Test You Should Run First
Distribution is the moat. Shipping something well is not enough. You need a reason people will hear about it and a place where they congregate that you can reach.
The distribution test: before validating your product, validate your distribution channel. Can you reach your target customer? Do you have a presence in the communities where they spend time? If you launched tomorrow, what would your actual path to the first ten paying customers look like?
If your answer is “I would post on Product Hunt and hope,” you do not have a distribution strategy. Product Hunt works occasionally. It is not a channel you can count on or repeat.
If your answer is “I am active in the [specific community] Slack and have helped fifty people there, and three of them have already told me they would pay for this,” you have both distribution and validation in one place.
The cheapest form of distribution is being a known, helpful presence in the community you are building for before you ask them to buy anything. It is also the most durable. Running ad campaigns is expensive and stops the moment you stop paying. Being genuinely useful in a community builds a reputation that compounds.
Common Validation Mistakes That Feel Like Progress
Talking to people who are too polite. Your friends will tell you it is a great idea. Your professional network will say encouraging things to be supportive. The only useful validation comes from strangers who have no reason to spare your feelings. If you have only validated with people who know you, you have not validated.
Counting signups as validation. Email signups on a landing page are a weak signal. People sign up for things they are mildly curious about and never open. What you want is: did someone give you money, schedule a call unprompted, or tell three other people about it?
Optimizing the product before validating the problem. I have watched developers spend weeks making their landing page “more polished” before they have a single user. The polish does not matter before validation. Get the problem statement right and put it in front of people. If the problem is real and the page explains it clearly, you will get signal without perfect design.
Confusing “people have this problem” with “people will pay to solve it.” Every problem is not a business. Some problems are painful enough that people live with them rather than pay for a solution. Some problems are solved adequately by existing tools that are free. The gap between “yes, that is annoying” and “yes, I would pay fifty dollars a month to solve that” is real and you need to test for it specifically.
What Validation Actually Looks Like When It Works
The things that tell you a problem is real and worth building for:
Someone contacts you to ask when it will be available before you have launched. Someone pre-pays for early access to something that does not exist yet. Multiple people in separate conversations use almost identical language to describe the frustration. You try to help someone manually with the problem and they ask if you have a tool that does this automatically. You post about the problem and the replies are from people saying “yes, I have this exact problem and here is how I currently hack around it.”
That last one is particularly telling. People who have developed workarounds have validated that the problem is real enough to invest time in. They have also told you exactly what your minimum viable product needs to beat.
The first dollar of MRR matters more than most metrics not because of the revenue, but because it validates the entire chain: real problem, real willingness to pay, real ability to reach the customer. Getting that first dollar before you have written a line of product code is the goal of validation.
The Actual Work
The framework above requires you to do things that feel slower than building. Talking to people, reading community posts, writing landing pages for products that do not exist. Developers are trained to build. This feels like stalling.
It is not stalling. It is the work that determines whether the building that comes after it is worth doing.
Shipping speed is a real advantage and moving fast still matters. The combination of validated problem plus fast execution is where the good outcomes come from. Validation without shipping is daydreaming. Shipping without validation is the same thing you have been doing when you build things nobody uses.
Seven days before you start building. That is the commitment. At the end of those seven days, you will know whether the problem is real, whether you can reach the people who have it, and whether anyone will pay for a solution. If the answers are good, you will build faster and more confidently because you know what you are building toward. If the answers are bad, you saved yourself a weekend, which you can spend starting the seven days over with a better problem.
That is the whole framework. Start with the problem, not the solution.