DEV Community: Dinuka Nilupul

How I Do Sprint Planning as a Solo Developer (No Standups, No Scrum Master, No BS)

Dinuka Nilupul — Mon, 08 Jun 2026 13:00:00 +0000

I ran "proper" sprint planning by myself for six weeks.

Monday planning session at 9am. Me, my backlog, a Notion board with swim lanes. Thursday retrospective. Me, my notes, and a growing sense of absurdity. I did the Daily Scrum for exactly one day before deciding that narrating your progress to an empty room is not the productivity hack anyone described.

The problem wasn't discipline. It was that I was running a ceremony designed for teams of 3-9 people as a party of one. Agile sprint planning doesn't scale down to a solo developer. It breaks. Building a lighter version of the same ceremony doesn't fix it. You need something structured around being alone from the start.

Here's the solo sprint planning system I actually use. It runs in about 30-45 minutes at the start of every two-week cycle. It's the main reason I went from three abandoned side projects to shipping FoundStep.

Why Scrum Sprint Planning Breaks for Solo Developers

The Scrum Guide specifies that a Scrum team needs "one Scrum Master, one Product Owner, and Developers." A sprint planning meeting exists as a negotiation between these roles. The Product Owner prioritizes what should get built. The developers push back on how much they can actually do. The Scrum Master keeps things from derailing.

That friction is the point. The sprint commitment comes from pressure between people with competing incentives.

When you're building alone, you play all three roles in the same planning session. The Product Owner in you wants to ship everything. The developer in you knows how long things actually take. And neither of them has anyone to referee. The negotiation becomes a monologue, and monologues rarely say "no" to themselves.

The result is what I'd call the solo dev planning trap. Either you over-commit (the Product Owner in you crushed the developer's objections) and ship late, or you under-commit (you listed vague tasks with no real goal) and don't really ship at all. Six weeks of that loop and I stopped doing "sprint planning" entirely.

	Team Scrum	Solo Sprint System
Who sets the goal	Product Owner, with developer input	You (Step 1, in writing)
Who pushes back on scope	Developers vs. Product Owner	Your Step 3 "necessary?" filter
Who protects the backlog	Scrum Master enforces it	Your written scope lock (Step 4)
How commitment is made	Group agreement in planning meeting	Solo written commitment
How progress is reviewed	Sprint Review + Retrospective with the team	10-minute end-of-sprint self-check

The 5-Step Solo Sprint Planning System

The system I settled on replaces Scrum's role-based negotiation with a series of explicit gates: decisions you force yourself to make before you start building. It takes 30-45 minutes at the start of each sprint. The rest of the sprint, you build without touching the plan.

Before you run this, you need a clear product roadmap: a written commitment to what you're building, in what order, and what you're not building yet. If you don't have one, build your product roadmap first, or write a one-page PRD that captures the same decisions in a format you can hand to an AI coding agent. Sprint planning is execution discipline; the roadmap is the strategy it operates on.

Step 1. Set ONE sprint goal (not a list)

Write one sentence. "By the end of this sprint, [specific user-facing outcome]."

Not "work on the auth flow." Not "improve performance and add dashboard." A specific thing that either happened or didn't, something like "Users can sign up, log in, and create their first project without hitting an error."

If you can't write that sentence in two minutes, the goal isn't clear enough to plan against. Stop and figure out what you're actually trying to accomplish before you do anything else.

One goal forces a choice. A list of goals lets you feel productive while building the wrong thing.

Step 2. Validate feasibility before you commit

Look at your actual calendar for the next two weeks. Not idealized. Real. Count the hours you genuinely have for focused building. Then multiply that number by 0.6.

That 40% disappears into context switching, debugging rabbit holes, the deployment issue you spend three hours fixing on a Sunday, the package that breaks after an upgrade. If you've been writing code for more than six months, you know exactly what I'm describing.

Can you reach the sprint goal in those buffered hours? If not, either shrink the goal or extend the sprint. Don't just start and hope.

Step 3. Cut your feature list down

List the features that deliver the sprint goal. Not everything in your backlog. Not the nice-to-haves you've been eyeing. The minimum set that gets you to the outcome in your sprint goal sentence.

Ask this about each feature: is this actually necessary to reach the goal? If the honest answer is "probably not, but it would be a nice improvement," move it to a separate "next sprint" list and stop looking at it. That list exists so the idea isn't lost, not so it can sneak back in mid-sprint.

Step 4. Lock the scope (the step most solo devs skip)

Read the feature list one more time. Then close the doc and commit. This is what you're building, and you're not adding to it.

The Agile Alliance describes protecting the sprint backlog from changes as a core principle. In Scrum, the Scrum Master enforces this boundary. Solo, the only protection is your own written commitment, made explicit and held to when something tempting shows up. FoundStep's scope locking feature builds this constraint directly into the workflow so your willpower isn't the only line of defense.

My track record here is simple. Every time I've broken this rule, I've regretted it. Not sometimes. Every time. The "let me just add this one small feature" never stays small. It needs another component. That component reveals an edge case. The edge case takes an afternoon. The original goal ships late or half-finished.

The scope lock isn't bureaucracy. It's what makes the sprint real.

Step 5. Ship at the end, not "mostly done"

At the end of the sprint, sit down for ten minutes and answer three questions:

Did I ship what I committed to? (Yes or no, not "mostly.")
What slowed me down that I could prevent next sprint?
What's one thing I'll do differently?

That's the retrospective. No sticky notes, no frameworks, no 90-minute ceremony. But answer honestly, especially question 1. "Mostly done" is not done. If you treat it as done, you'll never accurately scope the next sprint and you'll never build a real shipping rhythm.

That honesty is the point. If you keep stalling at the starting line instead of the finishing line, the problem might not be planning. It might be procrastination.

How Long Should a Solo Sprint Be?

Start with two weeks.

Most Scrum teams use two-week sprints because it's long enough to build something meaningful and short enough to catch a wrong turn before it costs a month. Agile sprint planning literature recommends this two-week rhythm for a reason: the feedback loop tightens without the overhead becoming the work. The same logic holds solo, and if anything, working alone means you need that loop faster, not slower.

I made the mistake of trying one-week sprints early on. They sound efficient. In practice, solo developers spend roughly 30% of their time on things that aren't building: debugging environment issues, researching implementations, handling infrastructure, reading documentation. One week doesn't leave enough build time after that overhead.

Two weeks is the default. Three weeks works if you're building large, complex features for an established product. Don't go past three. Beyond that, the cycle loses urgency and you're back to "let's see how it goes" territory.

Tools for Solo Sprint Planning

The common advice is Jira. Don't use Jira.

Jira was built for teams running Scrum with Scrum Masters managing boards and ceremonies. For a solo developer, it's ten times the interface you need and ten times slower than a plain document. Every hour spent managing a Jira board is an hour not building. If you're already convinced, the Jira alternative for solo developers comparison explains why in detail.

The best sprint planning tools for solo work have low friction and open fast:

A plain Notion page or Obsidian note with the sprint goal at the top, the feature list below it, and checkboxes is enough for most solo projects. The goal is something you'll open at the start of each sprint and at the end, not something that impresses anyone.

If you want a bit more structure without the ceremony, Linear works well. It's built for developers, not process managers.

I use FoundStep now. It's built for solo developer workflows and bakes both the validation step and the scope-locking step into the workflow directly. The discipline is in the tool, not just in your willpower, which turns out to matter a lot.

Pick something with low friction and actually open it at the start of each sprint. That's the whole trick.

The Solo Sprint Planning Template and Checklist

Run this at the start of every sprint. Total time: 30-45 minutes. This sprint planning template covers both phases: setup and review.

Sprint Setup (start of sprint)

[ ] Write ONE sprint goal in one sentence (specific outcome, not an activity)
[ ] Check your real calendar and count actual available hours for the next 2 weeks
[ ] Multiply available hours by 0.6 to get realistic output hours
[ ] List the minimum features that deliver the sprint goal
[ ] Remove anything that doesn't pass the "necessary for the goal?" test
[ ] Write the final feature list somewhere visible
[ ] Commit. This scope is locked until the sprint ends.

Sprint Review (end of sprint, 10 minutes)

[ ] Did I ship what I committed to? (yes/no, "mostly" counts as no)
[ ] What slowed me down?
[ ] What will I do differently next sprint?

Frequently Asked Questions

Can you do Scrum by yourself?

Technically, no. The Scrum Guide specifies that Scrum requires a Scrum Master, a Product Owner, and developers. It's a team framework built around role-based negotiation. You can't really have that negotiation with yourself.

What you can do is work with the same idea: time-boxed cycles, a defined goal, locked scope. That's what the 5-step system above implements. It's not Scrum. It's the same core concept, rebuilt for one.

How many story points should a solo sprint have?

Skip story points entirely. They exist to calibrate velocity across team members with different experience levels and working styles. Solo, you have exactly one velocity: yours. And you don't need points to compare it against anyone.

Use hours instead. Estimate each feature in rough hours, total them, compare against your Step 2 output hours. That's the only math you need.

What happens if I don't finish my sprint?

Carry the unfinished work into the next sprint goal. But first answer the retrospective question honestly: why didn't you finish?

If the answer is over-scoping, tighten Step 3 next time. If something unexpected derailed you, adjust the multiplier down to 0.5 because your workflow might need more buffer. If the scope lock broke mid-sprint, write down what pulled you off track and treat it as a pattern to eliminate.

Don't carry unfinished work forward and add the new sprint's scope on top. That's how sprints collapse into an endless backlog of half-finished things.

Start Your Next Sprint Right

The ceremonies Scrum built for teams don't survive contact with solo development. The discipline does.

Set one goal. Check your actual capacity. Pick the minimum features. Lock the scope. Ship.

Five steps, 30-45 minutes, every two weeks. I'm still refining mine, honestly. But it turned three dead repos into something I actually shipped, which is the test that matters.

If you want a tool that builds this discipline into the workflow itself, try FoundStep. It's what I built specifically for solo developers who need the planning layer, not just the building layer.

Agentic Coding Tools Are Getting Good. So Why Aren't You Shipping?

Dinuka Nilupul — Thu, 21 May 2026 00:33:47 +0000

Cursor wrote ~400 lines of code in 8 minutes last Thursday. By end of day I had three new features nobody asked for and a launch date that slipped another week.

The tools are extraordinary. The shipping discipline isn't.

Every "best agentic coding tools" article answers the same question: which tool? Nobody answers what happens after you open it. This piece covers both: the tools actually worth using in 2026, and the one thing you need before you touch any of them.

What makes a tool "agentic" (it's not just better autocomplete)

Agentic coding tools don't suggest the next line. They take a goal and run with it: reading your entire codebase, building a task plan, editing multiple files, running tests, catching failures, and trying again. Google Cloud defines this as a structured understand → plan → execute → verify loop.

GitHub Copilot suggests code as you type. Claude Code reads your whole project, finds the bug three files away, fixes it, runs the tests, and reports back. That's not autocomplete. That's agentic AI coding — an autonomous agent with a plan.

The distinction matters because it changes what can go wrong. Autocomplete can't build the wrong feature. Agentic tools absolutely can, and fast.

The tools worth using in 2026

Two broad categories: IDE-native agents for developers who want to stay in a visual environment, and CLI or extension agents for people who prefer command-line control.

The IDE side is dominated by Cursor right now. It's become the default AI-first editor for a lot of solo developers. VS Code fork, native agent mode, edits across multiple files. The reason it's popular is mostly that it works without a lot of configuration.

Windsurf is similar (also a VS Code fork) but runs the "Cascade" agent more autonomously. Where Cursor tends to check in more, Windsurf just goes. Better for heavy refactoring sessions where you want to step back and let it run. Trae is newer and worth keeping an eye on. The agent context management is genuinely different, though it's less battle-tested.

On the CLI and extension side, Claude Code is the one I'd reach for on a complex codebase. It reads repositories, runs shell commands, and reasons through bugs, and it's moved faster than anything else in this space through early 2026. Cline is open-source and runs as a VS Code extension; it asks for approval before any risky action, which makes it the sanest option if you want agentic speed with a review gate. Aider is the terminal native's tool that wires directly into your git history and gives you fine-grained control over every commit.

Tool	Category	Best for	Cost model
Cursor	IDE	Most developers, fast setup	Subscription
Windsurf	IDE	Heavy refactoring, autonomous runs	Subscription
Trae	IDE	Iterative development, newer projects	Free (as of mid-2026)
Claude Code	CLI	Complex repos, reasoning through bugs	Per-token (Anthropic API)
GitHub Copilot	VS Code ext.	Existing GitHub workflows, inline + agent mode	Subscription (GitHub)
Cline	VS Code ext.	Agentic speed + approval gates	Free / open-source
Aider	CLI	Git-native workflows, commit control	Free / open-source

One thing most roundups skip: the model matters as much as the tool. Claude Code running Claude Sonnet produces materially different output than Claude Code running Haiku. Match the model to the complexity of the task, not just the brand name.

Agentic coding vs. vibe coding: not the same thing

People use these interchangeably. It causes problems.

Vibe coding is fast, imprecise, accept-the-output development. You describe roughly what you want, the AI writes it, you ship it. Speed is the point. It works fine for throwaway prototypes and early exploration, the kind of thing where you don't care if it's messy, you just want to see if the idea runs.

Agentic coding is something different. You give the agent a structured goal and let it work across your whole codebase, across multiple steps, with verification loops that catch its own mistakes. You're not watching every line. You're operating at the level of goals.

The confusion does real damage. A developer who picks up Claude Code and treats it like extremely fast autocomplete gets output that technically compiles but doesn't fit their actual plan. The agent builds what you asked for, not what you meant. And it builds fast, so by the time you notice, four unplanned features are sitting in your architecture wondering why nobody invited them.

Vibe coding is for figuring out if an idea works. Agentic coding is for executing a plan you've already decided on. Use the wrong one at the wrong time and you'll end up with a codebase that impresses nobody, including yourself.

The real problem: scope creep at machine speed

Here's what nobody puts in their agentic tools roundup.

These tools genuinely compress implementation time. What took a full day takes a few hours. Developers who've shipped real products with these tools will tell you this. That's real.

The problem is that scope creep compresses at exactly the same rate.

When a feature took 4 hours to build, you had 4 hours to reconsider. Every slow keystroke taxed the decision slightly. "Is this actually worth adding?" When Claude Code ships a feature in 12 minutes, that tax disappears entirely. "I'll just add this one thing" now costs 12 minutes. So you add 10 things. None of them were in the plan. Half of them break when combined. (I still don't fully understand why this happens even when I know to watch for it. There's something about fast execution that bypasses the part of your brain that's supposed to say no.)

Drew Breunig captured it well in "10 Lessons for Agentic Coding" from May 2026: agentic code is "free as in puppies." The tools are cheap. The maintenance of everything they build is not.

Apiiro makes a similar point from the security side. One of the main organizational risks of agentic coding is code generation outpacing code review. Agents produce pull requests faster than humans can assess them. The same thing happens at the product level. Features get built faster than you can decide whether they belong.

The tools didn't create scope creep. They made it instantaneous.

The missing layer: plan before you prompt

Every "agentic coding tools" roundup covers which tool to open. Zero of them cover what to do before you open it.

Agentic tools are execution engines. They need inputs. "Build me a task management feature" and "build me a task management feature with drag-and-drop, recurring tasks, collaborative editing, tags, filters, and a Kanban view" both get built in roughly the same time. The agent doesn't know you have two weeks and no runway. You have to tell it by locking scope before you prompt.

Three things need to exist before you touch any agentic tool:

The idea needs actual validation, not gut feel. Does someone want this? Have you talked to a real person about it? Would they pay? A validation checklist takes 20 minutes and will save you weeks.

The MVP scope needs to be written down: 3 to 5 features, named, bounded. Not "we'll figure it out as we go." Actually named and listed, somewhere you can look at it.

The not-list needs to be explicit. What are you not building in this sprint? If it's not on the not-list, your brain will add it at 11pm and the agent will build it at 11:03.

Without those three, fast execution tools just make undisciplined thinking faster.

The agentic coding workflow: build to ship

This is the order that makes agentic tools useful rather than dangerous:

First, validate the idea before any code gets written. Is this a real problem for a real person? Target user, pain point, existing alternatives, willingness to pay. Work through it before opening a terminal.

Second, write down the MVP. Not a wishlist. The features that ship in v1. If it's not on the list, it doesn't exist yet. Three features that ship beat twelve features that never do.

Third, make a not-list. Every feature you thought of and decided to cut goes here. This stops mid-sprint additions and gives you a prioritized backlog for v2 you don't have to reconstruct later.

Fourth, open Cursor. Paste your scope definition into the prompt context: "We're building X, Y, and Z. We are explicitly not building A, B, or C in this sprint." The agent respects the constraint if you give it one.

Fifth, ship before you iterate. Feedback from a real user is worth more than ten features you guessed they'd want. Ship the thing. Then open the backlog.

FoundStep covers steps one through three: the validation questionnaire, feature planning, and version locking are built around this exact problem. The point isn't to slow you down. It's to make the thing you hand the agent worth building.

Frequently asked questions

What are agentic coding tools?

AI assistants that take a high-level goal and execute it autonomously: reading your codebase, planning the approach, editing across multiple files, running tests, and retrying when they fail. The key difference from autocomplete: they act without waiting for you to type each step.

What is the best agentic coding tool?

Depends on your workflow. Cursor or Windsurf if you want an IDE. Claude Code or Cline if you prefer working in the terminal or want a review gate before risky actions. The model you run matters as much as the tool. Claude Sonnet 4.6 and GPT-4o handle complex multi-file tasks better than smaller models, and the difference is noticeable.

Is agentic coding free?

Most tools have free tiers, but "free as in puppies" is the honest framing. API costs, compute, and the ongoing maintenance of everything the agent builds all add up. Cline and Aider are open-source. Claude Code charges per token via the Anthropic API. Cursor runs on a subscription. Budget for recurring cost, not just the first session.

What's the difference between agentic coding and vibe coding?

Vibe coding is fast and imprecise: describe what you want, accept what comes out, ship it. Good for prototypes. Agentic coding means giving an autonomous agent a specific goal and letting it execute methodically across your whole codebase. The failure mode with agentic tools is using them in vibe mode: prompting without a plan and getting a codebase that built the wrong thing very efficiently.

Stop prompting. Start planning.

The tools work. Genuinely.

What doesn't work, for most solo developers, is the part that has to happen before the tools. The locked scope. The not-list. The honest answer to "what exactly are we shipping and what exactly are we not shipping this sprint?"

Agentic tools execute whatever they're handed, at machine speed. Hand them a clear plan and they're the best thing that's happened to solo development in years. Hand them a vague idea and they'll build a very fast, very wrong product.

Ready to ship your side project?

FoundStep helps indie developers validate ideas, lock scope, and actually finish what they start. Stop starting. Start finishing.

Get Started Free

How to Validate a SaaS Idea Before You Write Any Code

Dinuka Nilupul — Tue, 12 May 2026 10:14:26 +0000

CB Insights has run the autopsy on hundreds of dead startups, and the same line keeps showing up. 42% died because there was no market need. They built something nobody wanted.

Most solo founders skip validation. Not because they think it's stupid. Because the standard advice is either academic ("interview 100 customers") or vague ("just build an MVP and see"). Neither of those is something you can actually start on a Tuesday night after work.

This article gives you a 7-step framework that fits in a weekend. Twelve hours, maybe sixteen if you're being thorough. By the end, you'll have a written verdict on your idea. Build, Wait, or Reject. With reasoning you can't quietly walk back two weeks later.

What does it mean to validate a SaaS idea?

Validating a SaaS idea means getting evidence (not intuition) that a defined audience has a specific painful problem, that current solutions fail them, and that they will pay for a better one. It's the difference between "I think this could work" and "three people just paid me to build it."

If you can't name the audience, the pain, the alternatives, and the price, you haven't validated. You've imagined.

This matters because "I think this is a good idea" is a statement about you. Not the market. Markets don't care what you think. They care what they pay for.

Why most SaaS validation advice fails solo founders

Almost every validation framework you'll find online was written for a team that doesn't exist yet. A team with a researcher, a designer, and a budget. You don't have any of those. You have evenings.

It assumes you have a team

Steve Blank's customer development model. The Lean Startup loop. These work. They were also designed for funded teams running build-measure-learn over months. As a solo dev with maybe ten hours a week, you can't run a six-week customer development sprint. You need something tighter.

It treats validation as one-time, not a gate

Here's the thing nobody tells you. Validation is not something you do once at the start and then forget. It's a gate you keep checking against as scope grows. The idea you started with at week one is rarely the idea you're shipping at week ten. If you don't re-validate, you're building on a foundation that already shifted.

It confuses interest with willingness to pay

This is the trap. Someone says "yeah I'd use that" and you treat it like proof. It isn't. Interest is free. Willingness to pay is the only signal that matters, and it's the hardest one to get because it requires asking for actual money or commitment.

The Mom Test (Rob Fitzpatrick's book) covers this in detail. The short version. People lie to spare your feelings. Especially people who like you. Stop asking them.

The 7-step framework to validate a SaaS idea

Here are the seven steps. Read them once, then we'll go deeper.

Define the exact problem (not the solution)
Score problem severity (frequency × pain)
Map existing alternatives (workarounds count)
Test feasibility (can you ship v1 alone in 4 weeks?)
Audit your motivation (build-for-self vs. build-for-market)
Make a written verdict (Build, Wait, or Reject)
Set a deadline and lock scope

Each step takes 30 to 90 minutes. Total investment is one weekend. If you can't spare a weekend, you can't spare three months building the wrong thing.

Step 1. Define the exact problem (not the solution)

Write the problem in one sentence, with the audience named, before you write a single line about the solution.

Wrong. "An app that helps freelancers track invoices."

Right. "Freelance designers with 3 to 10 active clients lose 4 to 6 hours per month chasing late payments because they don't have a system to send reminders automatically."

The first version is a product description. The second is a problem. You can validate the second. The first is just a feature waiting to be built.

If you can't write your problem statement this way, the rest of the framework won't help. Go back. Re-write it.

Step 2. Score problem severity (frequency × pain)

Two questions. How often does the problem hit? How much does it hurt when it does?

A problem that happens daily and costs the user thirty minutes is a real problem. A problem that happens twice a year and is mildly annoying is a vitamin, not a painkiller. Vitamins don't sell. Painkillers do.

Score each on a 1 to 5 scale. Multiply. Anything below 9 is probably not worth building for. Anything above 15 has commercial potential. The math is rough on purpose. Precision is a trap at this stage.

Step 3. Map existing alternatives (workarounds count)

People do not have your problem and just sit there. They cope. List every way they cope today. Other tools, spreadsheets, Notion templates, hiring an assistant, simply ignoring the problem.

Workarounds count as competitors. Maybe the most dangerous competitors. "We use a Google Sheet and it's fine" is harder to beat than a dedicated competitor with a worse UI, because the Sheet is free and already in their workflow.

If the existing alternatives are genuinely terrible and people are still using them anyway, that's a signal. Either the pain isn't bad enough, or there's something about your audience you don't understand yet.

I rejected one of my own ideas at this exact step. Gaplix was a second-brain tool for filling knowledge gaps as you research. Frequency × pain looked strong. Researchers, writers, and developers hit gaps every day. Then I mapped the workarounds. Notion templates, manual highlights in Readwise, Obsidian backlinks, ChatGPT in a side tab. None of them solved it cleanly. All of them were free, already in the audience's stack, and good enough. I wrote a Reject verdict and dated it. Not because the problem wasn't real, but because the workaround tax was too low for anyone to switch tools. Two months not spent building Gaplix is two months I got back to spend on something with a real switching wedge.

Step 4. Test feasibility (can you ship v1 alone in 4 weeks?)

Most solo founders fail at this step and don't realize it. The question is not "can I build this eventually." It's "can I ship a usable v1 in four weeks of part-time work."

Write down the smallest version that would solve the core problem for one paying user. Strip everything else. No onboarding flows. No team features. No mobile app. No integrations beyond the one critical one. If the smallest version still takes you six months, you have either picked the wrong problem or the wrong scope.

This is also where most solo developers get into scope trouble. The validation feels exciting. The roadmap balloons. By the time you're building, you've added eleven features that have nothing to do with the original problem. Lock scope here. Write down what's in v1 and what's not. Refer back to that list every time you're tempted to add something.

Step 5. Audit your motivation (build-for-self vs. build-for-market)

Be honest with yourself. Why are you building this?

There are two reasonable answers. "I'm building it because I have this problem and want to solve it for myself" is fine. So is "I'm building it because I see a market opportunity and the economics work." Both can lead to good products.

What's not fine is the muddy middle. "I think other people might want this even though I don't have the problem and haven't talked to anyone who does." That's not motivation. That's a wish.

If you're building for yourself, accept that the market might be small and you might not get rich. If you're building for the market, accept that you need to validate hard because you're not the user. Trying to do both badly is how most side projects die.

Quick self-test. Name three people who have this problem, who aren't you, and who you've talked to in the last month. Real names, not "designers in general." If you can't, you're in the muddy middle. Either go talk to three real people this week, or commit to building it for yourself with a small market and stop pretending otherwise.

Step 6. Make a written verdict (Build, Wait, or Reject)

This is the step almost everyone skips, and it's the one that matters most.

After steps 1 through 5, write a verdict. One of three options.

Build. The problem is real, the audience is reachable, you can ship v1 in time, and you have honest motivation.
Wait. The idea is interesting but something is missing. Maybe you don't know the audience well enough yet. Maybe you need to validate willingness to pay before committing. Write down what specifically needs to change before this becomes Build.
Reject. Something fundamental doesn't work. Write down what.

The verdict has to be in writing. Not in your head. In a document with a date on it. This is what stops you from quietly upgrading a Wait to a Build three weeks later when you're bored and your judgement is clouded.

Step 7. Set a deadline and lock scope

If the verdict is Build, set a ship date. Four weeks of part-time work, six at most. Write it down. Tell someone.

Then lock scope. The features in your v1 list at the end of step 4 are the features you ship. Adding anything else requires a written reason. Saving the reason matters. Reading it back two weeks later is humbling.

Most solo developers don't fail at building. They fail at finishing. A locked scope and a real deadline are the two things that turn "I'm working on it" into "I shipped."

Lightweight validation experiments (ranked by signal quality)

The seven steps tell you whether your idea has the shape of something worth building. To know whether the market actually wants it, run experiments. From weakest signal to strongest.

Search volume

Useful as a sanity check. If nobody is searching for the problem you're solving, the problem may not exist or it may be invisible to people who have it. Use Google Keyword Planner or Ahrefs.

But this is the weakest signal. Search volume tells you the problem exists. It tells you nothing about willingness to pay. People search for "free X" all day and never spend a dollar on it.

Reddit and X community signal mining

Find the subreddits or X communities where your target audience hangs out. Read the last six months of posts. Search for your problem in their words. Look for posts that describe the pain.

If you find the same complaint coming up over and over, that's a signal. If you find threads asking "what do you use for X" with twenty conflicting answers, that's a stronger signal. Conflicting answers mean nobody has solved it cleanly.

10 cold problem interviews

Talk to ten people in your target audience who aren't your friends. Don't pitch. Ask about their problem.

The Mom Test rule is simple. Ask about their life and habits, not your idea. "How do you currently handle X?" beats "Would you use a tool that does Y?" every time. They will lie about your idea. They cannot lie about what they did last Tuesday.

Ten interviews is the minimum that gives you actual signal. Five is anecdote. Twenty is a luxury you don't have time for.

Smoke test landing page

Build a landing page. Describe the product. Add an email capture. Drive traffic from communities or paid ads. Target a 15 to 20 percent conversion rate from visit to email.

Below 10 percent and the messaging or the offer is wrong. Or there's no demand. Below 5 percent, walk away.

Pre-orders or paid waitlists

The strongest possible signal short of an actual product. Ask people to put down a small deposit (even $5) to reserve a spot. Most won't. The ones who do are real signal.

A free email signup is interest. A paid pre-order is intent. The gap between those two numbers is the gap between a product and a project.

Common validation mistakes that kill SaaS ideas

These are the traps I've watched (and walked into) the most. Each one looks reasonable from inside the idea. Each one quietly kills the validation.

Asking friends and family. They love you. They will tell you the idea is great. Their feedback is poison. Use them for emotional support, not market data.

Confusing waitlist signups with willingness to pay. A waitlist is a list of people who said yes to a thing that costs nothing. You won't know what fraction will pay until you ask for money. Plan for 10 percent conversion at best.

Skipping validation because "I am the user." This is the most seductive trap. You think you don't need to validate because you have the problem. You still need to validate that other people have it, that they would pay to solve it, and that the way you'd solve it matches how they'd want it solved. Being the user is a starting point. Not a substitute for evidence.

Validating once, never re-validating. The idea you committed to in week one is not the idea you're building in week six. Scope creeps. Features get added. The original problem gets diluted. Re-validate every time you're tempted to add a feature that wasn't on the original v1 list.

When validation says Wait or Reject and how to decide

A verdict of Wait or Reject feels like a loss. It isn't.

The best code is the code you never wrote. Three months not spent building the wrong thing is three months you can spend on the right thing. Or on rest. Or on your day job. All of those beat a finished product nobody wants.

A documented kill is a win. You learned something. You saved months. You have a written record of why this idea didn't work, which means you won't waste another weekend revisiting it next year.

The trick is making the kill stick. If the verdict is Reject, archive the idea somewhere you can read later but not casually browse. If the verdict is Wait, write down the specific condition that would change it to Build. "If I find five people willing to pre-pay" is a real condition. "If I feel more confident later" is not.

If you want a structured way to record verdicts, the SaaS Idea Validation Checklist gives you the seven steps as a printable. One page. Front and back.

From validation to build, the next step

Once validation passes, you have a small window before scope drift sets in. Use it.

The features in your v1 list are the features you ship. Not the features you'd like to add. Not the features that came up in customer interviews and seemed interesting. The original v1 list. Period.

This is where most solo developers fail. A Google Doc with the seven steps and a dated verdict works fine. The point is the discipline. If your discipline is shaky (most of ours is), an app that won't let you start building until the verdict is signed off might be the difference between shipping and not shipping. That's the validation gate workflow inside FoundStep, but the doc version costs nothing and works on a Tuesday night just as well.

Frequently Asked Questions

How long should SaaS validation take?

A weekend if you're focused. Two weekends if you're being thorough. Anything beyond that is procrastination dressed up as research. The seven steps in this article fit into 12 to 16 hours of focused work.

How many people do I need to interview?

Ten is the floor. Five is anecdote. Twenty is research, and you don't have time for that. Ten cold problem interviews from your target audience, ideally not friends, is enough signal to make a Build, Wait, or Reject call.

Do I need a landing page to validate?

Not strictly. You can validate with interviews and community signal alone. But a smoke test landing page with email capture is the cheapest way to get a quantitative signal, and you should probably run one before committing to build.

What if my idea has no competitors?

Suspicious, not encouraging. The most common reason an idea has no competitors is that nobody wants it. Look harder. Check workarounds. People rarely have a problem that no one has tried to solve. If you genuinely find a gap, validate harder, not less.

Can I validate while I build?

You can build while you validate, in the sense that putting up a smoke-test landing page or running interviews while you also code in the evenings is fine. What you cannot do is skip validation, build the whole thing, and then "validate" by launching. That's not validation. That's a gamble with months of your life as the stake.

A weekend, not a quarter

If you're going to validate, validate honestly. Write down the verdict. Read it back to yourself before you start coding. The hardest part of validation isn't the seven steps. It's not quietly walking back the answer when you don't like it.

If you've shipped one already and you're picking the next idea, the shipping playbook covers what comes after validation. If you're trying to figure out whether the build is even financially viable, the startup cost calculator is the next thing to run.

Sources

The Top 12 Reasons Startups Fail (CB Insights) — cites no market need as the #1 reason at 42%.
The Mom Test by Rob Fitzpatrick (2013) — interview methodology for honest customer feedback.
The Four Steps to the Epiphany by Steve Blank — origin of customer development methodology.

I'm a Senior Software Engineer and solo developer. I built FoundStep because I was tired of watching my own side projects die in silence. It forces idea validation, locks scope, and keeps a permanent record of every change so side projects get finished instead of silently abandoned.

If you've killed an idea after running it through a process like this, I'd love to hear about it in the comments. The kill stories are the ones that teach the most.