How to Validate a Side Project Idea (Before You Waste 3 Months)

The 20-Minute Problem

You know the pattern. You're in the shower, or walking to the kitchen, or half asleep at 1 AM, and an idea hits. A tool that does X for Y people. It's obviously needed. Nobody has built it. You can see the landing page already.

Within 20 minutes, you've bought a domain. Within an hour, you've initialized a Next.js project and picked your color palette. Within a week, you're knee-deep in auth flows and database schemas. You haven't talked to a single person who might actually use this thing.

Three months later, the repo is collecting dust alongside your other abandoned projects. The domain auto-renews because you forgot to cancel it. The idea that felt so obvious turned out to be obvious only to you.

I've done this. Multiple times. I know developers who have 12 unused domains from ideas they never validated. One guy told me he spent four months building a "better bookmark manager" before discovering that every single person he showed it to just used browser bookmarks and didn't care.

Learning how to validate a side project idea would have saved him those four months. It would have taken 30 minutes.

Why This Is Harder for Solo Developers

According to CB Insights, 42% of startups fail because there's no market need. That stat covers funded companies with teams and advisors. For solo developers building side projects at midnight, the number is likely worse.

When you work on a team, bad ideas die in meetings. Someone says "who would use this?" and the idea either survives or it doesn't. There's friction between the idea and the code. That friction is a feature.

Solo developers don't have that friction. You are both the person pitching the idea and the person approving it. You're the buyer and the seller. And guess what? You always sell yourself on your own ideas.

Your friends won't help here either. When you text a buddy "hey what do you think of an app that does X," they say "yeah that sounds cool." They're being polite. "Sounds cool" is not validation. "Sounds cool" is what people say when they don't want to hurt your feelings.

So you need a framework. Something that forces you to poke holes in your own thinking before you open VS Code. Idea validation for developers isn't about market research decks or customer personas. It's about asking yourself hard questions and being honest about the answers.

Here's the side project validation framework I use to validate a side project idea. It takes 30 minutes. Sometimes it kills ideas I'm excited about, and that's the point.

Step 1: Define the Problem (Not the Solution)

Most developers start with the solution. "I want to build a tool that..." Wrong starting point. Start with the problem.

Write down the answers to these three questions:

• Who has this problem? Be specific. "Developers" is too broad. "Solo developers who maintain multiple side projects and lose track of what they were working on" is specific enough.
• How often do they have it? Daily problems are worth solving. Problems that happen once a year aren't. If someone hits this problem once a quarter, they'll hack together a spreadsheet and forget about it.
• What do they do about it right now? This is the big one. If people have a problem and do nothing about it, they probably don't care enough to pay for a solution.

Here's a real example. I had an idea for a tool that tracks which side projects are actually making progress and which ones are stalled. The problem: solo developers start too many projects and lose track. How often: constantly, if you're the type. What do people do now: nothing, mostly. Some use Notion, some use Trello, most just let projects die.

That "what do they do now" answer is interesting. "Nothing" can mean "the problem isn't painful enough" or "nobody has built the right solution yet." You need to figure out which one it is.

If you can't answer all three questions with specifics, stop here. The idea isn't ready. It might never be ready. That's fine.

Step 2: Rate the Severity

Not all problems are created equal. There's a difference between a headache and a migraine. Headaches are annoying. Migraines make you willing to pay for relief.

Think about it this way. Would someone pay $10/month to solve this problem? $20? $50? If the answer is "probably not, but they might use it if it's free," you have a headache product. Headache products can work, but they need massive distribution to make money. As a solo developer, you probably don't have massive distribution.

Migraine products are different. People search for solutions. They compare tools. They pull out their credit card. If you can build a migraine product, you don't need a marketing budget. The pain does the marketing.

Here's how I rate severity:

• Level 1 (Mild annoyance): People notice the problem but work around it. They won't pay. They might not even sign up for a free tool.
• Level 2 (Recurring frustration): People complain about this on Twitter or Reddit. They've tried workarounds. They'd consider paying if the price is right.
• Level 3 (Active pain): People are already spending money or significant time on bad solutions. They'd switch to yours if it's better.

If your idea is Level 1, kill it. Level 2, maybe. Level 3, keep going.

The bookmark manager guy? Level 1. People don't care about bookmark management. They Google stuff again instead of finding their bookmarks. That's how little they care. If he'd been honest about severity, he'd have caught this immediately.

Step 3: Research Existing Alternatives

Open Google. Search for what you want to build. Search Product Hunt. Search Reddit. Search Indie Hackers (the validation discussions specifically are goldmines). Search GitHub.

Two outcomes are both informative:

You find 50 existing tools. This means the market exists, which is good. But it also means you need a clear reason why yours is different. "Better UI" is not a reason. "Built for solo developers specifically, where competitors target teams of 10+" is a reason. If you can't articulate why someone would switch from an existing tool to yours, the idea has a differentiation problem.

You find 0 existing tools. Your first instinct will be "great, no competition!" Wrong instinct. No competition usually means one of two things. Either the problem isn't painful enough for anyone to build a solution (most likely), or you've found a genuine gap (rare, but it happens). Assume it's the first one until you have evidence otherwise.

When you validate a side project idea, what you're really doing here is checking whether other people have already tried this and what happened. If three similar products launched and all died, that's data. Go find out why they died. Maybe the market isn't there. Maybe they executed poorly. Maybe the timing was wrong. But don't ignore the signal.

Look at the existing alternatives and ask yourself: would I use any of these? If one of them does 80% of what you're imagining, most users will use that instead of waiting for yours. You need to solve a problem they don't, or solve it for a specific audience they ignore.

Step 4: Assess Build Feasibility

Can you ship a working v1 by yourself in 2 to 4 weeks?

Not a polished v1. Not a feature-complete v1. A v1 that solves the core problem for one type of user. If the answer is no, the idea is too big for a side project. You either need to cut scope dramatically or move on.

This is where a lot of technically ambitious ideas die, and they should. "I want to build a better video editor" is a multi-year, multi-team effort. You're one person with evenings and weekends. Be honest about that.

Here's what I check:

• Tech stack: Can I build this with tools I already know? Learning a new framework mid-project is a guaranteed timeline killer.
• Core feature: What's the one thing this tool does? Can I build that one thing in a week? If the core feature alone takes a month, the scope is wrong.
• Dependencies: Does this need third-party APIs, payment processing, user-generated content moderation, real-time sync? Each dependency adds complexity and failure modes.
• Maintenance burden: Once this is live, how much time will it take to keep running? A tool with a database needs backups, migrations, monitoring. A static site doesn't.

If you've read my post on how to ship faster as a solo developer, you know that scope is the number one speed killer. Validation is where scope control starts. If you can't imagine a minimal version that ships in 2 to 4 weeks, the idea needs surgery.

Step 5: Check Your Motivation

This is the step nobody talks about, and it matters more than most people realize.

Why do you want to build this? Be honest. Here are the common answers and what they actually mean:

• "It would be cool to build" - You want a project, not a product. That's fine if you know it going in. But if you're hoping for users or revenue, "cool to build" has a 95% abandonment rate. You'll lose interest the moment the fun technical parts are done and the boring work starts (marketing, support, bug fixes, writing docs).
• "I want to make money" - Good motivation, but you need to pair it with a real problem. Lots of developers build things hoping to monetize and then discover that monetization requires users, and users require solving a real problem.
• "I have this problem myself" - Best starting point. You understand the pain firsthand. You're your own first user. But be careful: your version of the problem might be unusual. Validate that other people have it too.
• "I want to learn X technology" - Then build a learning project, not a product. Don't confuse a tutorial with a business.

The honest answer changes how you approach everything. If you're building to learn, skip the rest of this framework and go have fun. If you're building a product, keep reading.

Step 6: The Kill Question

Here's the question that separates ideas worth pursuing from ideas that sound good in the shower:

Would you still build this if it never made money and nobody used it?

If yes, build it. You'll finish it because you care about the problem, not the outcome. Products built from genuine frustration tend to be better anyway. You'll stick with them through the boring parts because the problem bugs you enough to keep going.

If no, that's not automatically a kill signal. But it means your motivation is external (money, users, status), and external motivation is fragile. When the project gets hard, and it will get hard, you need something pulling you through. "This might make $200/month eventually" is weak fuel.

I'm not saying you should only build passion projects. I'm saying you should be aware of what's driving you, because it predicts whether you'll finish.

Step 7: Make the Verdict

You've spent 30 minutes thinking through these steps. Now make a call. Three options:

Build. You've answered "should I build this side project?" with a clear yes. The problem is real, specific, and painful. Alternatives exist but miss something. You can ship v1 in 2 to 4 weeks. Your motivation will survive the boring parts. Start this week.

Wait. The idea has potential but something is off. Maybe you can't define the user clearly enough. Maybe you need to talk to more people. Put it in a backlog, revisit in a month. Don't start building.

Kill. The problem isn't painful enough, the market is saturated with better solutions, you can't ship it in a reasonable timeframe, or you're honest that you'll abandon it. Delete the domain. Delete the repo. Move on.

No "maybe." Maybe is where side projects go to die slowly. You end up with a half-built project that you feel guilty about every time you see it in your GitHub. Make the call. You can always revisit a killed idea later if new information shows up. But right now, it's Build, Wait, or Kill.

This is the core of the side project validation framework: a clear decision, made quickly, based on honest answers to hard questions.

How to Validate Without Spending Money

You don't need a landing page. You don't need ads. You don't need to hire a researcher. Idea validation for developers can be done with zero budget.

Reddit and forum mining. Search for your problem on Reddit, Hacker News, and Stack Overflow. Are people complaining about it? How often? How recently? Active discussions reveal whether others see the same gap.

Keyword research. Google your problem and check autocomplete suggestions. If Google completes your problem statement, people are searching for it. Free tools like Google Trends show whether search interest is growing or flat.

Competitor gap analysis. Find competing products and read their 1-star reviews. Every complaint is a validated pain point. Every feature request that keeps coming up is a potential MVP scope item.

The 10-DM test. Find 10 people who match your target user profile. Message them. Describe the problem — not your solution. Ask if they experience it and how they handle it today. If 7 of 10 say "yes, it's annoying," you have signal. If 7 of 10 say "not really," kill the idea.

The whole validation process for a developer-targeted product should take under two hours. More than that is procrastination wearing a responsible-looking outfit.

Common Mistakes That Bypass Validation

Even developers who know they should validate ideas find ways to skip it. Here are the patterns I see over and over.

"I Already Know This Is a Good Idea"

No you don't. You think you do because you're excited. Excitement is not market research. Every developer who spent months on a failed project was excited when they started. The excitement is the reason you need validation, not the reason to skip it. Idea validation for developers is about counteracting your own bias.

"I'll Validate After I Build the MVP"

This is backwards. You're saying "let me spend 200 hours building something, and then I'll check if anyone wants it." Would you drive 200 miles before checking if you're going in the right direction? Validate before you build. That's the entire point.

Asking Friends for Validation

Your friends will tell you your idea is good because they like you. Their opinion is useless for validation purposes. Talk to strangers who have the problem. Go to Reddit, go to Discord communities, go to indie hacker forums. Find people who don't care about your feelings and ask them: "I'm thinking about building X. Would you use it? What would you use instead?"

If people respond with "I'd just use [existing tool]," that's real feedback. If they respond with questions about features and pricing, that's also real feedback. Both are more useful than your friend saying "yeah that's sick bro."

Confusing "I Want This to Exist" with "People Will Pay for This"

You might genuinely want a tool that does X. That doesn't mean anyone else does. And even if others want it, wanting is different from paying. The gap between "I'd use that" and "here's my credit card" is enormous.

When you're trying to figure out whether you should build this side project, separate your personal desire from market demand. You can want something to exist and still recognize that it's not a viable product. Build it as a personal tool if you want. Just don't expect users.

Over-Validating as Procrastination

The opposite mistake. Some developers spend weeks on validation to avoid the scary part: actually building the thing. They do surveys, build landing pages, run ads, analyze competitors in spreadsheets. This is procrastination wearing a responsible-looking outfit.

Validation should take 30 minutes to 2 hours. If you're on day three of "validation," you're stalling. Make the decision. Build, Wait, or Kill.

How to Validate a Side Project Idea in Practice

The next time an idea hits you at 1 AM, don't open your laptop. Don't buy a domain. Open your notes app and write down the answers to the questions from Steps 1 through 6. Set a timer for 30 minutes if that helps.

If the idea survives those 30 minutes, it's earned the right to become a project. If it doesn't, you just saved yourself weeks or months. Both outcomes are good. That's the whole point of learning how to validate a side project idea: fast, honest decisions.

FoundStep was designed with exactly this kind of workflow in mind. When you're managing multiple side project ideas and need a systematic way to track what's validated, what's in progress, and what's been killed, having a single place for that matters. But the framework itself is tool-agnostic. Use it in a notebook, a text file, or a Notion alternative built for solo developers. The tool doesn't matter. Doing the work does.

If your idea passes validation, the next step is scope control. Read how to avoid scope creep as a solo developer before you write a single line of code. Validation tells you what to build. Scope control tells you how much to build. Get both right and you'll actually ship things.

If you're specifically validating a SaaS idea, the how to validate a SaaS idea before building guide goes deeper on monetization signals and pricing validation. And once you have a Build verdict, going from idea to MVP as a solo founder walks you through turning that validated problem into a shipped product.

Frequently Asked Questions

How do I know if my side project idea is worth building?

Ask yourself: who has this problem, how often do they have it, and would they pay to solve it? If you can't answer all three specifically, the idea needs more thought. The side project validation framework above walks you through this step by step.

Should I build a landing page to validate my idea?

Only if your idea targets non-technical users. For developer tools, talk to 5 to 10 developers who have the problem. A landing page tests marketing copy, not product value. You'll learn more from five honest conversations than from a thousand landing page visits.

How long should idea validation take?

30 minutes to 2 hours for the initial verdict. If you're spending days on validation, you're procrastinating. Run through the seven steps, make a Build, Wait, or Kill decision, and move on.

What percentage of side project ideas are worth building?

Honestly, maybe 1 in 5. Most ideas feel exciting in the moment but fail basic validation. That's the point of learning how to validate side project ideas. You want to kill bad ideas fast so you can find the good ones.

Can I validate an idea without talking to potential users?

You can do a rough validation using Steps 1 through 4 without talking to anyone. But talking to 5 to 10 people who have the problem you're solving will give you information you can't get any other way. If you skip that step, your confidence in the verdict should be lower.

What if my idea fails validation but I still want to build it?

Build it. Seriously. If you're aware that it's a personal project and not a business, there's nothing wrong with building something you want. Just set your expectations accordingly. Don't spend money on marketing or hosting infrastructure for something you haven't validated. Keep it small and personal.