Originally published at chudi.dev
I almost built a meal planning app.
The idea felt solid: busy professionals want healthy eating but hate planning. Obvious pain point, right?
MicroSaaSBot's validation: 42/100. Kill.
Why? The market is saturated. Users expect free. Retention is abysmal. The problem is real, but the business isn't viable.
That's 6 weeks of development I didn't waste.
Why Does Validation Have to Come Before Code?
Most failed products don't fail on execution — they fail on problem selection. Founders build things that aren't painful enough, frequent enough, or valuable enough to sustain a business. Running validation first catches these failures in one to two days rather than after weeks of development, before sunk-cost bias makes killing the idea emotionally difficult.
Why Validation First
The default builder mindset:
- Have idea
- Get excited
- Start building
- Finish building
- Realize nobody wants it
The validation-first mindset:
- Have idea
- Score it
- Kill it or build it
- (If build) Know you're solving a real problem
Most failed products don't fail on execution. They fail on problem selection. They solve problems that aren't painful enough, frequent enough, or valuable enough. Y Combinator's startup advice frames this as the single most common mistake founders make: building something nobody wants.
Validation catches this before you waste weeks or months.
How Does the Scoring System Work?
MicroSaaSBot's Researcher agent scores ideas across four dimensions: Severity (0–30), Frequency (0–20), Willingness to Pay (0–30), and Competition (0–20), totaling 100 points. Problems scoring below 60 are killed regardless of founder enthusiasm. StatementSync scored 78 — high severity, proven willingness to pay, and a clear differentiation opportunity in flat-rate pricing.
The Scoring System
MicroSaaSBot's Researcher agent evaluates four dimensions:
Total: 0-100 points.
Severity (0-30 points)
The most important dimension. If the problem isn't painful, nothing else matters.
High severity (25-30): "I spend 10 hours a week on this and hate every minute."
Medium severity (15-24): "It's annoying but I've learned to live with it."
Low severity (0-14): "I guess it would be nice if it were easier."
StatementSync: 24/30 - Bookkeepers genuinely hate manual transcription. It's tedious, error-prone, and takes real time from billable work.
Frequency (0-20 points)
How often the problem occurs determines retention.
High frequency (16-20): Daily or multiple times per week.
Medium frequency (10-15): Weekly or a few times per month.
Low frequency (0-9): Monthly or less.
StatementSync: 16/20 - Bookkeepers process statements constantly. Multiple times per day for active professionals.
Willingness to Pay (0-30 points)
Are people already spending money?
High WTP (25-30): Active market with multiple paid solutions.
Medium WTP (15-24): Some paid options, mostly free workarounds.
Low WTP (0-14): Expectation of free, resistance to paying.
StatementSync: 22/30 - Competitors charge $0.25-1.00 per file. Bookkeepers are already paying. The question is price point, not price existence.
Competition (0-20 points)
Counterintuitively, some competition is good.
Good competition (16-20): Competitors exist but have clear weaknesses.
Okay competition (10-15): Crowded market but differentiation possible.
Bad competition (0-9): Dominated by well-funded players or no market exists.
StatementSync: 16/20 - Competitors exist but all charge per-file. Flat-rate pricing is a clear differentiation opportunity.
The Kill Decision
Below 60: Kill.
No architecture. No coding. No deployment.
Killing ideas hurts. You've already imagined the product, maybe even named it. But building a 45-point idea costs the same time as building an 80-point idea. The opportunity cost is massive.
Ideas I killed:
- Meal planning app (42/100): Saturated market, free expectation
- Email cleanup tool (38/100): Exists as built-in features, low WTP
- Meeting scheduler (51/100): Calendly dominates, differentiation unclear
Ideas I built:
- StatementSync (78/100): Clear persona, proven WTP, differentiation path
The math is simple: kill 3 bad ideas, build 1 good one, save 18 weeks.
Why Does Persona Specificity Matter So Much?
A vague persona like "small businesses" produces marketing that resonates with nobody. A specific persona like "freelance bookkeepers processing 50+ statements monthly" dictates feature priorities, pricing strategy, marketing channels, and support expectations. The Researcher agent forces precise persona definition because specificity is what converts a validated problem into a viable product.
Persona Definition
Vague personas kill products.
Bad persona: "Small businesses"
- Which small businesses?
- What do they do?
- How do they work?
Good persona: "Freelance bookkeepers processing 50+ bank statements per month for multiple clients"
- Specific profession
- Quantified behavior
- Clear context
StatementSync's persona enables:
- Feature prioritization: Batch upload matters, mobile doesn't
- Pricing strategy: Flat-rate wins at volume
- Marketing channels: Bookkeeper communities, not general SMB
- Support expectations: Professional, not consumer
The Researcher agent forces specific persona definition. "Who exactly has this problem?" isn't optional.
Competitive Analysis
Competition isn't just "who else does this?" It's:
- What do they charge? (Price anchoring)
- What do users complain about? (Feature gaps)
- What's their positioning? (White space)
- How long have they existed? (Market maturity)
StatementSync competitive analysis:
| Competitor | Price | Weakness | Opportunity |
|---|---|---|---|
| TextSoap | $0.50/file | Expensive at volume | Flat-rate |
| HappyFox | $0.25/file | Complex setup | Simplicity |
| Manual OCR | Free | 80% accuracy | 99% accuracy |
| Zapier connectors | $1.00/file | Requires setup | Drag-drop |
The differentiation: Flat-rate pricing for unlimited conversions.
Not "better" generically. Better at a specific thing for a specific persona.
The Validation Report
The Researcher agent outputs a structured report:
# Validation Report: StatementSync
## Score: 78/100
- Severity: 24/30
- Frequency: 16/20
- Willingness to Pay: 22/30
- Competition: 16/20
## Recommendation: PROCEED
## Persona
Freelance bookkeepers processing 50+ bank statements monthly.
Pain: 10+ hours/week on manual transcription.
Current spend: $25-100/month on per-file solutions.
## Differentiation
Flat-rate $19/month vs per-file competitors.
Pattern-based extraction (99% accuracy, no LLM cost).
Simple drag-drop interface vs complex workflows.
## Risks
- Bank statement format changes
- Niche market size
- Competitor response to pricing
## Constraints for Architecture
- Must support batch upload (volume users)
- Must achieve near-zero marginal cost (flat-rate viability)
- Must cover top 5 US banks initially
This report becomes input to the Architect agent. Validation decisions flow forward. The same multi-agent architecture that powers the build phase starts here — each agent specializes in one judgment call.
What Does Validation Actually Prove?
Validation proves that a problem exists and that people are already paying for solutions. It does not prove that your implementation will win, that users will love your UX, or that you'll achieve product-market fit. A 78/100 score means the problem is worth building for — not that success is guaranteed. Execution still determines the outcome.
What Validation Doesn't Do
Validation is screening, not proof.
Validation proves: The problem exists and people pay for solutions.
Validation doesn't prove: Your solution will win, users will love your UX, or you'll achieve product-market fit.
Think of validation as "Should I spend time on this?" not "Will this definitely succeed?" This same evidence-first mindset applies to AI code verification — never trust confidence alone.
A 78/100 score means: "This problem is worth solving, and there's a viable path to differentiation."
It doesn't mean: "StatementSync will definitely make money."
Execution still matters. But at least you're executing on a validated problem.
The Lesson
The Kill Threshold in Practice: 3 Ideas That Didn't Make It
The 60/100 threshold sounds clean in theory. In practice, killing ideas you're excited about is uncomfortable. Here are three real examples where I had to override my own enthusiasm.
Idea 1: Personal finance dashboard for freelancers (Score: 51/100)
I freelanced for years. I know the pain. Tracking income across Stripe, PayPal, and direct transfers is genuinely annoying.
Severity: 18/30. Real pain, but not acute--most freelancers have a spreadsheet that handles it.
Frequency: 16/20. Monthly reconciliation at minimum.
WTP: 10/30. This is where it collapsed. Every bank already offers this. Copilot exists. QuickBooks handles it. Users expect free or bundled.
Competition: 7/20. Dominated by well-funded players with better data access.
Total: 51. Kill.
I spent two days arguing with the score before accepting it. The WTP number was the honest one. I'd personally pay $5/month max for a better version of something I can already do for free.
Idea 2: AI meeting notes with action item extraction (Score: 44/100)
This felt like a layup. Everyone hates meetings, everyone forgets action items.
Severity: 20/30. Real pain.
Frequency: 15/20. Regular pain.
WTP: 5/30. Otter.ai, Fireflies, Notion AI, and half a dozen others do this. For free or bundled in tools people already pay for. Market has been commoditized.
Competition: 4/20. Otter raised $50M and has enterprise deals. There's no angle.
Total: 44. Kill.
The lesson: "everyone has this problem" doesn't mean "there's room for another solution." Sometimes a problem is solved and the market just needs distribution. Jobs-to-be-done theory distinguishes between problems people have and problems worth building a business around—the former is nearly infinite, the latter is scarce.
Idea 3: GitHub PR review summarizer (Score: 58/100)
Developers review dozens of PRs a week. Context switching between them is painful. A summarizer that explains what changed and why would save real time.
Severity: 22/30. Genuine pain for anyone doing lots of code review.
Frequency: 18/20. Daily for active developers.
WTP: 12/30. GitHub has Copilot. Linear has AI. Most developers are already paying for AI tools that partially solve this. Standalone tool has a hard pitch.
Competition: 6/20. The large players are moving into this space directly.
Total: 58. Kill--just barely.
This one hurt. I still think the idea is directionally right. But building a standalone tool in a space where GitHub is the distribution channel and also building the feature is a losing position. The score captured that even when I didn't want to hear it.
Those three kills saved me somewhere around 16-20 weeks of development time. StatementSync at 78/100 was worth building. None of those three were.
The most leveraged phase of product development is validation. One day of research can save weeks of building. Eric Ries called this validated learning—the idea that every product decision should be treated as an experiment with a measurable outcome, not a bet on intuition.
MicroSaaSBot's Researcher agent isn't magic--it's structured thinking. Score the problem before you fall in love with the solution.
Kill bad ideas early. Build good ideas faster.
Related: Introducing MicroSaaSBot | From Pain Point to MVP: StatementSync
Sources
- Validated Learning - The Lean Startup (Lean Startup)
- Minimum Viable Product: a guide - Eric Ries (Eric Ries)
Top comments (1)
Validation before building is the single most important lesson in software. The number of projects that die because nobody validated demand first is staggering. Getting real signals from potential users - whether through surveys, landing pages, or community voting - saves you from the worst outcome: building something polished that nobody wants. Good writeup on making this systematic.