Indie Hacker Project Decision Framework: Anti-Burnout, Pro-Cash
Core Principle (Memorize This)
If a product does not create repeat usage or urgent pain, it will not make money fast.
Everything below enforces this principle.
Core Concepts & Terminology
Before diving into the framework, understand these foundational concepts:
Repeat Usage (Stickiness)
Definition: How often users return to your product without external prompting.
Why it matters: Products with repeat usage create habit loops and predictable revenue. One-time products require constant customer acquisition.
Examples:
- High repeat: Email management tool (daily), habit tracker (daily), analytics dashboard (weekly)
- Low repeat: Logo generator (one-time), resume builder (one-time), landing page template (one-time)
Related concept: Retention rate – the percentage of users who return after their first use. Aim for >40% monthly retention for sustainable products.
Resources:
Urgent Pain vs. Nice-to-Have
Definition: Urgent pain is a problem users face regularly that costs them time, money, or stress. Nice-to-have is a convenience improvement.
Why it matters: Users pay for urgent pain. They don’t pay for convenience.
Examples:
- Urgent pain: “I spend 2 hours daily on manual data entry” → Users will pay to eliminate this
- Nice-to-have: “It would be nice if this process were faster” → Users won’t pay
Related concept: Problem-solution fit – confirming that your solution actually solves the stated problem.
How to identify urgent pain:
- Users are already paying for a solution (even if it’s not ideal)
- Users complain about the problem unprompted
- Users spend significant time on the problem (>30 min/week)
- The problem costs them money or revenue
Resources:
Product-Market Fit (PMF)
Definition: A state where your product satisfies strong market demand. Users actively seek it out, recommend it, and pay for it.
Why it matters: PMF is the inflection point between struggling and scaling. Without it, growth is impossible.
Indicators of PMF:
- Users request features (not you pushing features)
- Organic word-of-mouth growth (>30% of new users from referrals)
- Users willing to pay without discounts or incentives
- High retention rates (>40% monthly)
- Users describe your product as “must-have” not “nice-to-have”
Related concept: Traction – measurable evidence that users want your product (signups, revenue, engagement).
How to measure PMF:
- Track NPS (Net Promoter Score) – aim for >50
- Monitor organic growth rate
- Measure willingness to pay
- Calculate customer lifetime value (LTV)
Resources:
- How to Know if You Have Product-Market Fit
- How to Measure Product-Market Fit (15 Metrics to Monitor)
Monetization
Definition: The mechanism by which you convert user value into revenue.
Why it matters: A great product with no monetization strategy is a hobby, not a business.
Common models for indie hackers:
- Subscription: Monthly/yearly recurring revenue (SaaS) – best for repeat-use products
- One-time purchase: Single payment for lifetime access – good for tools with clear value
- Credits/Pay-as-you-go: Users pay per action or usage – works for variable usage patterns
- Freemium: Free tier with paid premium features – good for user acquisition
- Affiliate: Earn commission by recommending products – passive income model
Related concept: Unit economics – revenue per user minus cost to serve that user. For indie hackers, this must be positive at small scale.
How to choose a monetization model:
- Subscription: If users need the product regularly and value is recurring
- One-time: If the product solves a one-time problem with clear value
- Pay-as-you-go: If usage varies significantly between users
- Freemium: If you need to acquire users quickly and have a clear upgrade path
Resources:
- [SaaS Pricing Models](How to Measure Product-Market Fit (15 Metrics to Monitor) )
- Monetization Strategies for Indie Hackers
MVP (Minimum Viable Product)
Definition: The smallest version of your product that solves the core problem and allows you to test your hypothesis.
Why it matters: MVP lets you validate assumptions with minimal time and money investment. It’s not about building less; it’s about building smarter.
Common mistakes:
- Building too many features (not “minimum”)
- Building features users don’t need (not “viable”)
- Launching without validation (not “minimum” effort)
- Confusing MVP with “beta” or “incomplete”
Related concept: Scope creep – the tendency to add features beyond the original plan, delaying launch.
How to define your MVP:
- Identify the core job your product does
- List all features needed to do that job
- Remove anything that’s not essential
- Remove anything that can be done manually initially
- Launch with what’s left
Example MVP scope:
- ❌ Full-featured project management tool with teams, permissions, integrations, mobile app
- ✅ Single-user task list with basic filtering and email reminders
Resources:
Distribution
Definition: How users discover and access your product.
Why it matters: A great product nobody knows about is worthless. Distribution is often harder than building.
Common channels for indie hackers:
- Organic/SEO: Users find you through search (slow, but sustainable)
- Social/Community: X, Reddit, Indie Hackers, Product Hunt (fast, but requires engagement)
- Direct: Email, word-of-mouth, personal network (most effective, but limited scale)
- Paid: Ads (usually not viable for indie hackers early on due to CAC)
Related concept: Viral coefficient – how many new users each existing user brings (>1 = exponential growth).
How to choose distribution channels:
- Start with channels where your target users already hang out
- Prioritize channels with low CAC (customer acquisition cost)
- Focus on organic growth initially (word-of-mouth, community)
- Only invest in paid ads once you have PMF
Resources:
Validation
Definition: Testing your assumptions with real users before building the full product.
Why it matters: Validation prevents you from building products nobody wants. It’s the cheapest way to learn.
Validation methods:
- Social proof test: Post about the problem, gauge interest
- Landing page test: Create a simple page, measure signups
- Manual service test: Solve the problem manually for users, ask if they’d pay
- Concierge MVP: Build a minimal version, get feedback
- Pre-sales: Ask users to pay before you build
Related concept: Hypothesis – a testable assumption about your product (e.g., “Solo founders will pay $50/month to automate email management”).
How to validate effectively:
- Define your hypothesis clearly
- Choose a validation method
- Set a pass/fail criteria upfront
- Talk to at least 10 potential users
- Make a go/no-go decision based on results
Resources:
Phase 1: Disqualify Bad Ideas Early (10 minutes)
Before excitement takes over, run every idea through these 5 kill questions. These are designed to eliminate ideas that look good on paper but won’t generate revenue or engagement.
Why Phase 1 matters: Most indie hackers fail because they build the wrong product, not because they build it poorly. This phase prevents that waste.
Time investment: 10 minutes per idea. If you can’t answer these questions in 10 minutes, the idea isn’t clear enough.
1. Is the Primary User in Pain This Week?
The Question:
Ask yourself:
- Does the user already do this manually?
- Is it annoying or time-consuming?
- Would they feel relief immediately?
- Are they actively searching for a solution?
Why this matters: If users aren’t in pain this week, they won’t prioritize your solution. They’ll keep doing what they’re doing.
Kill signal:
“It would be nice if…”
This phrase indicates a nice-to-have, not urgent pain. Directories fail here because they’re conveniences, not solutions to urgent problems.
How to validate: Ask 5 potential users: “How much time do you spend on this weekly?” If the answer is less than 30 minutes, it’s not urgent enough.
Real-world example:
- ❌ “It would be nice if there was a better way to organize bookmarks”
- ✅ “I spend 45 minutes daily searching through my bookmarks and can’t find what I need”
Related metrics:
- Time spent on problem: >30 min/week = urgent
- Cost of problem: >$100/month = urgent
- Frequency: >3x per week = urgent
2. Will the User Come Back Without SEO?
The Question:
Ask yourself:
- Would someone open this again next week?
- Or only when Googling once?
- Is there a reason to return?
Why this matters: One-time products require constant customer acquisition. Repeat-use products create sustainable revenue with lower acquisition costs.
Kill signal:
“People will search for it when they need it.”
This is the classic one-time product trap. You’re betting on SEO traffic, which is unpredictable and expensive to acquire.
How to validate: Ask users: “Would you use this again next month?” If the answer is “only if I need it,” it’s one-time value.
Related metric: Monthly Active Users (MAU) – the percentage of users who return monthly. Aim for >40% for sustainable products.
Real-world example:
- ❌ Logo generator (one-time use, then users leave)
- ✅ Email management tool (users return daily)
Why this matters for indie hackers:
- One-time products need 100+ new users monthly to sustain
- Repeat-use products need only 50 paying users to sustain
- Repeat-use products have 5-10x better unit economics
3. Can I Charge $5 Without Feeling Guilty?
The Question:
Ask yourself:
- Does this save time, stress, or money?
- Would you pay $5 for it?
- Is the value clear and immediate?
Why this matters: If you can’t justify $5, you can’t justify building it. The product isn’t valuable enough.
Kill signal:
“We’ll monetize later.”
Later = never. If you can’t articulate value now, you won’t be able to later.
How to validate: Show the product to 5 users and ask: “Would you pay $5/month for this?” If fewer than 3 say yes, the value isn’t clear enough.
Related concept: Willingness to pay (WTP) – the maximum price a user will pay for your product. If WTP < $5, the market is too small.
Real-world example:
- ❌ “It’s a nice tool but I wouldn’t pay for it”
- ✅ “I’d pay $10/month to save the 2 hours this takes me weekly”
How to calculate if $5 is viable:
- Time saved per week × hourly rate = monthly value
- Example: 2 hours/week × $50/hour = $400/month value
- $5/month is 1.25% of value = easy sell
4. Can This Be Explained in One Sentence to One Person?
The Question:
Ask yourself:
- Can I explain it to one specific user type?
- Not “everyone”, not “creators”, not “teams”
- Is the target user crystal clear?
Why this matters: If you can’t explain it simply, you don’t understand the problem. Vague positioning means vague marketing.
Kill signal:
“It’s for anyone who…”
This is the directory mindset. You’re trying to serve everyone, which means serving no one well.
How to validate: Write one sentence: “This is for [specific user] who [specific problem].” If you can’t fill in the blanks, the idea isn’t clear enough.
Example of clarity:
- ❌ “It’s for creators who want to manage their content”
- ✅ “It’s for solo YouTubers who spend 3 hours weekly organizing video metadata”
Why specificity matters:
- Specific positioning = easier marketing
- Specific positioning = easier product decisions
- Specific positioning = easier to find early users
5. Does This Rely on Traffic Volume to Win?
The Question:
Ask yourself:
- Does success require massive traffic?
- Or can 50 paying users sustain it?
- Is the unit economics viable at small scale?
Why this matters: As an indie hacker, you don’t have the resources for massive traffic acquisition. You need a product that works at small scale.
Kill signal:
“Once we get traffic…”
Traffic is not a strategy. It’s a hope. If your product doesn’t work with 50 users, it won’t work with 5,000.
How to validate: Calculate: “If I had 50 paying users at $10/month, would that cover my costs?” If no, the unit economics don’t work.
Related concept: Unit economics – revenue per user minus cost to serve. For indie hackers, this must be positive at small scale.
Real-world example:
- ❌ “We’ll make money through ads once we get 1M monthly visitors”
- ✅ “50 paying users at $20/month covers our $1,000 monthly costs”
Unit economics calculation:
- Revenue per user: $20/month
- Cost to serve: $5/month (hosting, payment processing, support)
- Gross margin: $15/month per user
- 50 users × $15 = $750/month profit
Decision Rule for Phase 1
If an idea fails 2 or more of these → kill it immediately.
No debate. No “but what if we…” No pivoting later.
Why this is important: Every hour spent on a bad idea is an hour not spent on a good one. Killing ideas fast is a feature, not a bug.
The math: If you evaluate 10 ideas and kill 7 bad ones early, you save 700+ hours of wasted development time.
Phase 1 Checklist:
- Pain is urgent (weekly or more)
- Users will return (repeat usage)
- Value is clear ($5+ willingness to pay)
- Target user is specific (one sentence)
- Unit economics work at small scale (50 users)
Phase 2: Score Viable Ideas (15 minutes)
For ideas that survive Phase 1, score them honestly. This phase helps you prioritize between multiple good ideas.
Why Phase 2 matters: Not all viable ideas are equally viable. Scoring helps you pick the best one to work on first.
Scoring Table (0–2 per item)
| Criterion | 0 Points | 1 Point | 2 Points |
|---|---|---|---|
| Urgency | Nice to have | Mild pain | Ongoing pain |
| Repeat Use | One-off | Occasional | Weekly/daily |
| Willingness to Pay | Free only | Maybe | Obvious |
| Build Speed | >1 month | 2–3 weeks | <2 weeks |
| Distribution | SEO only | Mixed | Social/direct |
Max score: 10
Scoring Guidance
Urgency (0-2):
- 0: “It would be nice if…”
- 1: Users mention it occasionally, but it’s not critical
- 2: Users complain unprompted, spend >30 min/week on it
Repeat Use (0-2):
- 0: One-time use, then users leave
- 1: Users return occasionally (monthly)
- 2: Users return regularly (weekly or daily)
Willingness to Pay (0-2):
- 0: Users say “I’d never pay for this”
- 1: Users say “Maybe, if it was cheap”
- 2: Users say “I’d pay $X for this” (specific amount)
Build Speed (0-2):
- 0: Requires complex infrastructure, integrations, or design
- 1: Requires 2-3 weeks of focused work
- 2: Can be built in <2 weeks with existing tools
Distribution (0-2):
- 0: Relies entirely on SEO or paid ads
- 1: Mix of channels (some organic, some paid)
- 2: Direct access to users (community, network, social)
Decision Rule
- 8–10 → Build now (high confidence)
- 6–7 → Validate only (no code yet)
- ≤5 → Archive idea (revisit later)
Why these thresholds:
- 8-10: Strong signal across all dimensions
- 6-7: Good idea but needs validation before committing
- ≤5: Too many weak signals, likely to fail
Example Scoring
Idea: Email template library for SaaS founders
| Criterion | Score | Reasoning |
|---|---|---|
| Urgency | 2 | Founders spend 2+ hours weekly on email templates |
| Repeat Use | 2 | Founders return weekly to find/create templates |
| Willingness to Pay | 2 | Founders say they’d pay $10-20/month |
| Build Speed | 2 | Can build with Next.js + Stripe in 1 week |
| Distribution | 1 | Can reach via Twitter, but limited direct access |
| Total | 9 | → Build now |
Phase 3: Mandatory Pre-Build Validation (No Exceptions)
Before you write backend code, you must do at least one of these validation tests. This is non-negotiable.
Why Phase 3 matters: Validation is the cheapest way to learn. A failed validation test costs hours, not weeks.
Time investment: 3-7 days per validation test.
Option A: Social Proof Test (Best for You)
What to do:
- Post on X describing the pain (not the solution)
- Show sample output or mockup
- Ask for feedback and interest
Example post:
“Spending 2 hours weekly organizing email templates is killing my productivity. Anyone else struggle with this? What’s your current solution?”
Pass condition:
- Replies, DMs, or “How did you do this?”
- At least 5 people express interest
- At least 1 person asks about pricing
Why this works: Real people voting with their attention is the best signal.
Resources:
Option B: Landing Page Test
What to do:
- Create one simple page describing the problem and solution
- Add an email waitlist
- Share the link (no paid ads)
Example landing page:
- Headline: “Save 2 hours weekly on email templates”
- Subheading: “Pre-built templates for every SaaS email”
- CTA: “Join the waitlist”
- Email input field
Pass condition:
- At least 5 signups without ads
- At least 1 person asks about pricing
-
20% click-through rate from your traffic source
Why this works: Signups are a stronger signal than likes or comments.
Tools:
Option C: Manual Service Test
What to do:
- Manually solve the problem for 3 people
- Ask if they would pay
- Ask how much they’d pay
Example:
- Find 3 SaaS founders on Twitter
- Offer to create 5 custom email templates for them
- Ask: “Would you pay $20/month for a library of these?”
Pass condition:
- Someone offers money or asks pricing
- At least 2 of 3 say they’d pay
- They describe it as “valuable” or “time-saving”
Why this works: Real money or serious interest is the strongest signal.
If None Pass → Do Not Build
If your validation test fails, do not build. This is the hardest rule to follow, but it’s the most important.
What to do instead:
- Revisit the idea – is the problem real?
- Try a different validation method
- Pivot to a different user segment
- Archive the idea and move to the next one
Why this matters: Building a product nobody wants is the #1 cause of indie hacker burnout.
Phase 4: MVP Scope Guardrails (Very Important)
To avoid overbuilding, lock your MVP scope before you start coding.
Why Phase 4 matters: Scope creep is the #1 reason indie hackers fail. You’ll be tempted to add features. Don’t.
MVP Must:
- Solve one job (not multiple)
- Have one user type (not multiple)
- Have one core action (not many)
MVP Must NOT:
- Be a platform (multiple features)
- Be a marketplace (buyers and sellers)
- Have profiles, feeds, rankings, or discovery
- Have admin panels or complex settings
- Have mobile apps (web is fine)
- Have integrations (except payment)
Scope Creep Warning Signs
If you see these words, you’re drifting:
“Later we can add…” “We should also build…” “What if we included…” “We need this for launch…”
Stop. You don’t.
Example MVP Scope
Bad MVP (too much):
- Full-featured project management tool
- Teams and permissions
- Integrations with Slack, GitHub, etc.
- Mobile app
- Admin dashboard
- Custom workflows
Good MVP (focused):
- Single-user task list
- Basic filtering (by date, priority)
- Email reminders
- Export to CSV
Why the good MVP works:
- Can be built in 1 week
- Solves the core problem
- Easy to test with users
- Easy to iterate on
MVP Scope Template
Fill this out before you start coding:
Core Job: [One sentence describing what the product does]
User Type: [One specific user type]
Core Action: [One main thing users do]
Must Have:
- Feature 1
- Feature 2
- Feature 3
Must NOT Have:
- Feature X (save for v2)
- Feature Y (save for v2)
- Feature Z (save for v2)
Phase 5: Monetization Rule (Day 1 Thinking)
You do not need to charge on Day 1, but you must know your monetization strategy before you build.
Why Phase 5 matters: Monetization shapes product decisions. A subscription product is built differently than a one-time purchase.
Three Questions to Answer
1. Who Pays?
Be specific:
- ❌ “Creators”
- ✅ “Solo YouTubers with 10K+ subscribers”
2. What Do They Pay For?
Be specific about value:
- ❌ “The tool”
- ✅ “Saving 2 hours weekly on email templates”
3. How Do They Pay?
Choose one model:
- Subscription: $10-50/month (recurring revenue)
- One-time: $50-500 (lifetime access)
- Credits: $0.01-0.10 per action (variable usage)
- Freemium: Free tier + $10-50/month premium
- Affiliate: Commission on referred products
Monetization Decision Tree
Does the user need it regularly?
- Yes → Subscription
- No → One-time purchase
Does usage vary significantly?
- Yes → Credits/pay-as-you-go
- No → Subscription
Do you need to acquire users quickly?
- Yes → Freemium
- No → Paid from day 1
Example Monetization Plans
Email Template Library:
- Who pays: SaaS founders
- What they pay for: Time saved on email templates
- How they pay: $15/month subscription
Logo Generator:
- Who pays: Small business owners
- What they pay for: Professional logo without hiring designer
- How they pay: $50 one-time purchase
API Service:
- Who pays: Developers
- What they pay for: API calls
- How they pay: $0.01 per 1,000 calls (pay-as-you-go)
If You Cannot Answer These → Stop
If you can’t answer all three questions clearly, the idea isn’t ready. Go back to Phase 1.
Phase 6: Post-Launch Decision Rule (30 Days)
After launch, measure only these three metrics:
- Repeat users – How many users return?
- Conversion to email or account – How many sign up?
- Willingness to pay – How many would pay?
Decision at Day 30
- Evidence of pull → Invest more (add features, marketing)
- No pull → Freeze or kill (move to next idea)
No “just one more feature”.
Metrics to Track
Repeat Users:
- Goal: >40% of users return within 7 days
- How to measure: Track daily active users (DAU) / monthly active users (MAU)
- If <40%: Product doesn’t have repeat value
Conversion to Email:
- Goal: >10% of visitors sign up
- How to measure: Signups / visitors
- If <10%: Value proposition isn’t clear
Willingness to Pay:
- Goal: >20% of users would pay
- How to measure: Ask users directly
- If <20%: Value isn’t high enough
Decision Framework
| Metric | Result | Decision |
|---|---|---|
| Repeat users | >40% | ✅ Continue |
| Repeat users | <40% | ❌ Pivot or kill |
| Conversion | >10% | ✅ Continue |
| Conversion | <10% | ❌ Improve messaging |
| Willingness to pay | >20% | ✅ Charge |
| Willingness to pay | <20% | ❌ Increase value |
What “Invest More” Means
If you have pull:
- Add 1-2 features users request
- Spend time on marketing
- Optimize onboarding
- Start charging
What “Freeze or Kill” Means
If you don’t have pull:
- Stop adding features
- Stop marketing
- Move to next idea
- Archive this one
Why this is important: Continuing to invest in a product without pull is the fastest way to burnout.
Apply This to Your Current Ideas
Example 1: cooltools.top
Phase 1 Analysis:
- Fails urgency (nice-to-have directory)
- Fails repeat use (one-time lookup)
- Fails monetization (unclear payer)
Decision: Freeze and repurpose
Example 2: Blog → X Content Tool
Phase 1 Analysis:
- Passes urgency (bloggers spend 1+ hour weekly on X)
- Passes repeat use (bloggers post weekly)
- Clear payer (bloggers who want more reach)
Phase 2 Score: 8/10 (build now)
Decision: Valid candidate for Phase 3 validation
Final Rule (Most Important)
You are not allowed to build “interesting” products anymore. Only painful ones.
This framework exists to protect:
- Your time
- Your motivation
- Your financial goal
Resources & Further Reading
Books
- The Lean Startup by Eric Ries – Foundational framework for validation
- The Mom Test by Rob Fitzpatrick – How to talk to customers
- Traction by Gabriel Weinberg – 19 channels to grow your product
- The Indie Hacker’s Handbook – Community and resources
Articles & Guides
- How to Know if You Have Product-Market Fit – Andreessen Horowitz
- Measuring Product-Market Fit – Reforge
- Jobs to Be Done Framework – Understanding customer needs
- 19 Traction Channels for Startups – Y Combinator
Communities
- Indie Hackers – Community of indie hackers
- Product Hunt – Launch and get feedback
- Hacker News – Tech community
- Twitter/X Indie Hacker Community – Real-time discussions
Tools
- Carrd – Simple landing pages
- Typeform – Customer surveys
- Notion – Documentation and planning
- Stripe – Payment processing
Next Steps
If you want to apply this framework:
- List 5 ideas you’re considering
- Run Phase 1 on each (10 minutes each)
- Score survivors with Phase 2 (15 minutes each)
- Validate top idea with Phase 3 (3-7 days)
- Lock scope with Phase 4 (1 hour)
- Define monetization with Phase 5 (30 minutes)
- Build and launch (1-2 weeks)
- Measure at Day 30 with Phase 6
This is how indie hackers stop wandering and start compounding.
Comments