
## Why Solo Founders Need a Systematic Process

### The Three Most Common Failure Modes

Independent developers don't fail because they lack skill. They fail because they lack process.

After observing 60+ projects, here are the three most common ways it goes wrong.

**Failure Mode A: Code First, Think Later**

Get an idea → Can't sleep from excitement → Open the editor and work for 3 months → Launch → 0 users → Burnout.

A GitHub full of private repos, but not a single product anyone has used. This isn't unique to you — an engineer's instinct is to solve problems by writing code. But product problems can't be solved with code.

**Failure Mode B: Endless Analysis, Never Action**

Want to build something → Spend 3 months researching the market → Analyze competitors → Draw 50 pages of wireframes → Write zero lines of code → Enthusiasm runs out.

A Notion full of product research documents, but nothing ever launched. Analysis is a form of hidden procrastination — you're using "research" to avoid "starting."

**Failure Mode C: Built and Launched, But Nobody Came**

Finish the code → Feature complete → Beautiful UI components → Launched on Product Hunt / Show HN → 0 signups → No idea what went wrong.

The product is 80% there, but distribution channels are nonexistent. "Build it and they will come" stopped working on today's internet.

> 💡 All three failure modes share one thing: **you're using what you're good at to hide what you're not.** Engineers are good at coding, so Failure Mode A is most common. Content creators are good at distribution, so they rarely suffer Mode C — but they often die from Mode B.

### Why This Framework Matters

Big companies have product managers, marketing teams, and data analysts to spread the risk. A solo founder has only themselves. Every wrong decision costs months of your life.

This five-phase framework exists to:

- **Let you focus on one thing at a time** — know what you should and shouldn't be doing right now
- **Give you clear exit criteria** — know when you're ready to move to the next phase
- **Help you diagnose problems** — when stuck, know exactly which phase is the bottleneck

It's not another product methodology article. It's a map you can actually follow.

---

## The Five Phases

Each phase has its own dedicated guide with detailed instructions. This section gives you the overview so you understand the full picture.

### Discovery

**Core task:** Find 2-3 product directions worth investing time to validate.

**Input:** Market signals, user pain points, technology trends
**Output:** A shortlist of directions, each with a clear user profile and problem description
**Exit criteria:** 2-3 directions where you can answer "who benefits and how they solve it today"
**Typical time:** 1-4 weeks
**Common mistake:** Stopping to search as soon as you find one direction. Collect 5-10 signals first, then filter down to 2-3. Don't go all-in on the first idea you find.

**Real example:**

An engineer wanting to go indie didn't brainstorm ideas at home. He spent 30 minutes daily browsing Hacker News and Indie Hackers. After two weeks, he noticed something: for 5 consecutive days, people were complaining about "unclear copyright issues with AI-generated code." It wasn't that he "felt" this was a pain point — real people kept saying it. This signal led him to 3 potential directions.

> 💡 Discovery isn't about "creating ideas." It's about "detecting signals." You don't need to come up with great ideas from scratch — you need to learn to recognize what the market is already telling you.

The most time-consuming part of discovery is manually browsing platforms every day collecting signals. If you'd rather not do this by hand, [Opportunity Scanner](/reports) automatically scans 65+ data sources each week and delivers the signals in one report.

---

### Validation

**Core task:** Before writing a single line of code, confirm that someone will pay for your solution.

**Input:** Product direction + user profile
**Output:** Evidence of willingness to pay (waitlist signups, pre-orders, recorded interviews)
**Exit criteria:** At least 10 people you don't know have expressed willingness to pay
**Typical time:** 2-6 weeks
**Common mistake:** Using "my friends say it's a good idea" as validation. Your friends say it's good because they don't want to discourage you.

**Real example:**

A developer wanting to build an AI resume tool didn't start coding. He set up a landing page (3 hours), wrote 200 words of product copy, and added a "Request early access" button. He shared the link on r/resumes and a few WeChat groups.

In the first 3 days, 7 people signed up. He called each one for a 20-minute chat.

The 7th person made him change direction: "I don't actually need resume optimization. I need to know how to follow up after submitting applications."

> 💡 Validation isn't about "how many people signed up." It's about the 20-minute conversations you have AFTER they sign up. Don't just collect numbers — understand their real context.

Validation involves building landing pages, writing copy, and interviewing users. See the [Validation guide](/guides/02-validation) for a complete step-by-step walkthrough.

---

### Build

**Core task:** Build something functional in the least amount of time, then put it in front of real users.

**Input:** Validated requirements + feature priorities
**Output:** A minimum product that can run its core flow
**Exit criteria:** Core functionality works and can be delivered to real users
**Typical time:** 4-12 weeks
**Common mistake:** Chasing perfection. Installing a Tailwind component library, setting up CI/CD, writing unit tests, adding i18n — two months go by and the core feature isn't done yet.

The first version doesn't need to look good, doesn't need i18n, doesn't need automated deployment. It just needs to solve that one core problem. Users don't care about your tech stack — they care about whether you can solve their problem.

**Real example:**

After validating the need for "AI-powered weekly reports," a developer didn't build a full SaaS product. He wrote a Telegram bot: users send their chat logs, the bot returns a draft weekly report. It took 4 days.

The first 12 users started using it. Only after 3 weeks of feedback did he decide whether to turn it into a web application.

If you're unsure which tech stack to use, which AI model to pick, or what your monthly costs will be, see the [Build guide](/guides/03-build) for a complete AI-era tech stack breakdown.

---

### Launch

**Core task:** Get at least 10 target users onto your product within 30 days.

**Input:** Working product
**Output:** First batch of real users
**Exit criteria:** A reliable acquisition channel exists, daily new users > 0
**Typical time:** 2-8 weeks
**Common mistake:** The "hope" strategy — hoping Show HN will bring traffic, hoping your tweet will go viral, hoping Product Hunt will rank you. Hope is not a strategy. A strategy is knowing exactly where your users are and doing the same few things every day to reach them.

**Real example:**

A developer built a productivity tool for heavy Notion users. Instead of launching on Product Hunt (too broad), he went to the Notion community, r/Notion on Reddit, and Twitter hashtag #NotionTips.

Every day he replied to 5 questions about Notion productivity, naturally mentioning his tool when relevant. On day 7, three people asked "what tool is that?" On day 14, 12 people had signed up.

Launch involves copywriting and channel research. See the [Launch guide](/guides/04-launch) for a complete playbook covering Product Hunt, Show HN, Reddit, and Twitter.

---

### Operations

**Core task:** Shift from "acquiring users" to "keeping users and getting them to bring more users."

**Input:** Real users + usage data
**Output:** A sustainable operations system
**Exit criteria:** Monthly churn < 10%, monthly user growth > 10%
**Typical time:** Ongoing
**Common mistake:** Continuing to build new features at the same pace as the Build phase. The features you need should already be in the MVP. What you actually need is to make existing users happier and keep them longer.

**Real example:**

A SaaS founder had 47 paying users by month 3. Instead of building new features, he sent a personal email to each paying user asking one question: "What does this product need most?"

He got 31 replies. He grouped them into three categories, picked the most requested one, and spent 2 weeks building it. That month, churn dropped from 8% to 3%.

Operations requires continuously monitoring user behavior and competitor activity. See the [Operations guide](/guides/05-operate) for metrics tracking and retention strategies.

---

## Phase Dependencies and Decisions

### Dependency Chain

The five phases have a strict order:

```
Discovery → Validation → Build → Launch → Operations
```

Each phase depends on the previous phase's output. You can accelerate, but you cannot skip.

Why you cannot skip:

- Skip Discovery → you might build something nobody wants
- Skip Validation → you find out after launch that nobody will pay
- Skip Build → you're always waiting for "the right time"
- Skip Launch → your product sits in a corner unseen
- Skip Operations → users come and go, and the product slowly dies

### Self-Diagnosis: Which Phase Are You In?

Answer these questions honestly:

```
Q1. Do you have 2-3 clear product directions, each with a known target user and problem?
  ├─ Yes → go to Q2
  └─ No → You're in 【Discovery】

Q2. For at least one direction, have ≥10 strangers explicitly said "I'd pay for this"?
  ├─ Yes → go to Q3
  └─ No → You're in 【Validation】

Q3. Do you have a working product (even a prototype) in users' hands?
  ├─ Yes → go to Q4
  └─ No → You're in 【Build】

Q4. Besides you and your friends, are ≥10 strangers actively using your product?
  ├─ Yes → go to Q5
  └─ No → You're in 【Launch】

Q5. Is your monthly churn < 10% and monthly user growth > 10%?
  ├─ Yes → You're in 【Operations】
  └─ No → You're in Operations, but something is wrong with your ops
```

### Common Cross-Phase Traps

**Trap 1: Setting up infrastructure before deciding the direction**
Symptoms: Setting up project scaffolding, CI/CD, and choosing databases before you even have a clear direction.
Consequence: Switched directions multiple times, built scaffolding for each one, none launched.
Fix: In the Discovery phase, your keyboard should only be used for recording signals and ideas.

**Trap 2: Trying to skip two phases at once**
Symptoms: Think of an idea in the morning, ask "how do I promote this?" in the afternoon.
Consequence: Skip validation, write code directly, launch to zero users.
Fix: Focus on only one phase's problems at a time.

**Trap 3: Faking positive feedback**
Symptoms: Posted on social media, got 10 likes, consider demand validated.
Consequence: Launch to $0 MRR.
Fix: Real feedback = active user behavior (signup, filling a form, paying a deposit). Likes don't count.

### Phase Switch Quick Reference

| Current Phase | Condition to advance | Signal to retreat |
|---|---|---|
| Discovery | ≥3 directions with user profiles | Collecting signals for 4+ weeks with no convergence |
| Validation | ≥10 target users willing to pay | Failed validation on 3 consecutive directions |
| Build | MVP runs core flow | Development exceeds 3 months without launch (needs scope reduction) |
| Launch | Reliable acquisition channel, daily new > 0 | Zero signups after 2 weeks (return to Validation) |
| Operations | Monthly churn < 10%, growth > 10% | Monthly churn > 15% (return to Product or Validation) |

---

## Conclusion

1. **Focus on one phase at a time.** The only thing that matters right now is completing your current phase's core objective. The next phase's problems are for later.

2. **Phases cannot be skipped, but can be accelerated.** An experienced founder can run through validation in 2 days (set up a landing page + make 10 calls). But skipping validation costs 3 months of wasted development.

3. **Two steps forward, one step back is normal.** You might be in the Launch phase and discover you need to go back to Validation. That's fine. The framework's job is to make you aware of where you are and why.

4. **Start from where you are.** Don't aim for a perfect end-to-end execution. Find your current phase and do what that phase requires.

---

## Further Reading

*The Mom Test* — Rob Fitzpatrick
> The best introduction to user interviews. Learn how not to be fooled by "sounds good" in conversation.

*Lean Startup* — Eric Ries
> The Lean Startup methodology. Understand the Build-Measure-Learn cycle.

*YC Startup School*
> Free online course from Y Combinator. Suitable for first-time product builders.


A systematic framework covering the 5 phases every solo founder must navigate: Discovery → Validation → Build → Launch → Operate. With diagnostic tools, real failure patterns, and actionable phase-transition criteria.

The Solo Founder's Product Lifecycle Framework

Why Solo Founders Need a Systematic Process


## Why Most Solo Founders Pick the Wrong Idea

### The Three Discovery Traps

Your first idea is rarely your best idea. But most solo founders never give themselves a chance to discover that — they pick the first idea that excites them and start building.

Here are the three most common discovery traps:

**Trap 1: Scratching Your Own Itch — Without Checking If Anyone Else Has It**

You hit a problem, think "I could build a tool for this," and open your editor. It feels like a validated idea because *you* experienced the pain. But you haven't checked whether enough other people share that pain to build a business around it.

A developer frustrated with Jira builds a "simpler Jira." A designer annoyed by Figma's pricing builds a "cheaper Figma." These ideas feel right because they come from personal experience — but personal experience is a sample size of one.

**Trap 2: Chasing Shiny Tech**

A new model drops. A new framework goes viral. Suddenly every tweet in your timeline is about "building with X." The excitement is real — but the problem you're solving with it might not be.

GPT wrappers in 2023, crypto projects in 2021, VR apps in 2016. The common thread: founders started with the technology and went looking for a problem to attach it to. Technology should serve a problem, not the other way around.

**Trap 3: Building for a Market You Don't Know**

You read that "the HR tech market is $30B" or "edtech is growing 16% YoY." You've never worked in HR or education, but the numbers are compelling. So you build something for a user whose daily reality you don't understand.

You won't know what to build. You won't know where to find users. You won't know who to talk to. Every step from discovery to launch will be uphill.

> 💡 The common thread across all three traps: **the idea comes from inside your head, not from signals in the world.** Good discovery means inverting that — start with what the market is telling you, then match it against what you can build.

### What Good Discovery Looks Like

Good discovery isn't about generating brilliant ideas. It's about building a system for collecting and filtering signals.

A signal is evidence that a specific group of people has a specific problem they're actively trying to solve. The goal of discovery is to collect enough signals that patterns emerge, then select the 2-3 directions most worth validating.

The process takes 1-4 weeks and requires no code. Your tools during discovery: a browser, a note-taking app, and curiosity.

---

## Where to Find Signals

### The Signal-Rich Platforms

Not all platforms are equally useful for discovery. Here are the ones that consistently produce actionable signals:

| Platform | Best For | Signal Type | Frequency |
|---|---|---|---|
| Hacker News | Developer tools, infrastructure, dev workflows | "Ask HN" threads, "Show HN" comments complaining about gaps | Daily |
| Reddit | Niche communities, hobbyists, professional subreddits | r/SomeTool "I wish it could..." posts, complaint threads | Daily |
| Twitter/X | Emerging trends, founder conversations, tech zeitgeist | "I would pay for..." tweets, build-in-public replies | Hourly |
| Indie Hackers | Solo founder products, micro-SaaS opportunities | "What are you working on?" threads, revenue stories | Daily |
| App Store Reviews | Existing product gaps, feature requests | 3-star reviews (too specific to ignore, not angry enough to dismiss) | Weekly |
| Niche Forums | Specialized professional communities (e.g., Teacher subreddits, legal forums) | Workflow complaints, "there's no good tool for..." | Weekly |

### How to Read Each Platform

**Hacker News**

Don't just browse the front page. Search for patterns:
- `Ask HN: What pains you about...` — people listing their frustrations
- `Ask HN: Is there a tool that...` — people looking for something that doesn't exist
- Comments on product launches where users say "this is close to what I need but..."

The gold isn't in the posts — it's in the comments. A post with 3 upvotes and 40 comments often has more signal than a post with 300 upvotes and 5 comments.

**Reddit**

Go to subreddits where your target users complain about their tools. Examples:
- r/Notion, r/ObsidianMD, r/Figma for productivity/tool users
- r/Teachers, r/nursing, r/accounting for professional communities
- r/SaaS, r/startups for founder-focused products

Sort by "New" instead of "Hot." The signal-to-noise ratio is lower, but the signals you find won't already be picked over by everyone else.

**Twitter/X**

Use search operators:
- `"I would pay for"` + your domain keyword
- `"I wish there was a"` + tool category
- `"someone should build"` + problem area

Follow builders-in-public in adjacent spaces. Their replies section is a goldmine — their audience tells them exactly what they want.

**App Store / Chrome Web Store Reviews**

The most underrated discovery channel. Find the top 3 products in a space you're interested in, then read their reviews sorted by "Most Critical."

Look for 3-star reviews specifically. 1-star reviews are usually angry and unhelpful. 5-star reviews are too vague. 3-star reviews are people who use the product enough to care but are frustrated enough to write a detailed critique. Every 3-star review is a feature gap someone would pay to fill.

> 💡 Spend 30 minutes a day on signal collection, not 4 hours once a week. Consistency matters more than volume. The goal is to train your pattern recognition — after two weeks of daily scanning, you'll start noticing themes that one-off research would miss.

---

## How to Filter and Score Directions

### The Five-Question Filter

Once you've collected 10-15 signals, group them into candidate directions. For each direction, answer these five questions:

1. **Who exactly has this problem?** Can you describe a specific person? "Developers" is too broad. "Backend engineers at 20-50 person startups who write internal CLIs" is specific enough.

2. **How do they solve it today?** If the answer is "they don't," be suspicious. Every real problem has a current solution — even if it's "manually in Excel" or "paying a VA $15/hour." A problem with no current solution is usually a problem nobody actually cares about.

3. **How often do they hit this problem?** Daily > weekly > monthly > once per quarter. A painful problem that happens once a year is not a business. A mild annoyance that happens three times a day might be.

4. **Are they already spending money on adjacent problems?** Someone who pays $30/month for Notion is more likely to pay for a Notion-related tool than someone who uses free alternatives. Follow the money.

5. **Why you?** What do you know about this user or problem that someone random doesn't? If the answer is "nothing special," either learn more before building or pick a different direction.

### Scoring Template

Score each direction 1-5 on these dimensions:

| Dimension | 1 (Weak) | 3 (Moderate) | 5 (Strong) |
|---|---|---|---|
| Problem frequency | Once a quarter | Weekly | Multiple times daily |
| User clarity | "People" | "Frontend devs" | "Frontend devs at agencies using Webflow" |
| Existing spend | No adjacent spending | Free tools with paid tiers | Active monthly subscriptions in adjacent tools |
| Founder fit | You've never been this user | You were this user 3 years ago | You are this user right now |
| Signal volume | 1-2 mentions | 5-10 mentions across 2 platforms | 15+ mentions across 4+ platforms |

Add up the scores. Directions scoring 18+ are worth validating. Directions scoring 12-17 need more signal collection. Directions below 12 should be set aside.

> ⚠️ Don't skip the scoring step just because one direction "feels right." The scoring isn't about being mathematically precise — it's about forcing yourself to articulate *why* you're choosing one direction over another. If you can't explain it on paper, you haven't thought about it hard enough.

---

## Building Your Direction Shortlist

### The One-Page Direction Document

For each direction that passes the filter, write a one-page document. Keep it short — if it takes more than 15 minutes to write, you're overthinking it.

Use this template:

```
Direction: [One-line description]

Who: [Specific user profile — role, company size, context]
Problem: [What they can't do today, or what takes too long]
Current solution: [How they solve it now — even if it's manual]
Why now: [What changed that makes this solvable today? New API? Behavior shift?]
Signal sources: [Links to 3-5 specific posts/comments/reviews]
Revenue model guess: [Subscription? One-time? Usage-based? Rough price range]
Competitive landscape: [2-3 existing products and how they fall short]
My unfair advantage: [Why I'm better positioned than a random developer]
```

**Real example of a completed direction document:**

```
Direction: AI-powered weekly report generator for team leads

Who: Engineering managers at 20-200 person companies who write
     weekly status reports for leadership
Problem: Spending 2-3 hours every Friday compiling updates from
         Slack, Jira, and GitHub into a coherent report
Current solution: Manual copy-paste from multiple tools into a
                  Google Doc template
Why now: LLMs are good enough at summarization to produce useful
         drafts, and managers are already using ChatGPT for this
         (just not in an automated way)
Signal sources:
  - r/EngineeringManagers: "How do you handle weekly reporting?" (34 comments)
  - HN: "Ask HN: Tools for automated status reports?" (18 comments)
  - Twitter: 4 separate "I spend my Fridays writing reports" tweets
    with high engagement
Revenue model guess: $15-30/manager/month subscription
Competitive landscape:
  - Standuply: async standups, not weekly reports
  - Geekbot: focused on standups, weak on cross-tool aggregation
  - Manual ChatGPT: works but requires copy-paste every time
My unfair advantage: I was an EM for 4 years and wrote ~200 weekly
                     reports. I know the format leaders actually want.
```

### Selecting Your Top 2-3

You should end discovery with 2-3 direction documents, not 1. Here's why:

- If validation fails on your first direction (and it often does), you have backups ready
- Having alternatives reduces the emotional attachment to any single idea
- Comparing directions side-by-side reveals which one you're actually excited about

If you can't find 2-3 viable directions after 4 weeks of signal collection, the problem isn't the market — it's your signal sources. Broaden your inputs before concluding there's "nothing to build."

---

## Common Discovery Mistakes

### Mistake 1: Stopping at One Idea

You find a direction that seems promising and immediately want to start building. This is the most common discovery failure.

The fix: set a rule before you start. "I will document at least 3 directions before I pick one to validate." The rule protects you from your own enthusiasm.

### Mistake 2: Confusing "Interesting" with "Viable"

A problem can be intellectually fascinating without being commercially viable. "Decentralized identity verification for Web3 gaming" is interesting. "A tool that helps small restaurant owners schedule staff" is boring — and probably makes more money.

The fix: for each direction, ask "would someone pay for this?" If you hesitate for more than 3 seconds, it's interesting, not viable.

### Mistake 3: Researching Forever

Discovery should take 1-4 weeks, not 3 months. At some point you have enough information and need to move to validation. More research won't make the decision easier — it'll just delay the real test.

The fix: set a hard deadline. "By [date 4 weeks from now], I will pick 2-3 directions and move to validation." Put it on your calendar.

### Mistake 4: Ignoring Your Own Constraints

A direction that requires $50K in upfront infrastructure isn't a solo founder opportunity. A direction that requires FDA approval isn't a 4-week validation. Be honest about what you can actually execute with your resources.

The fix: add a "feasibility" check to your direction document. Can you build an MVP in under 3 months? Can you reach the target users without a marketing budget? If either answer is no, the direction is for a different kind of company.

### Mistake 5: Asking Friends for Direction Feedback

Your friends want you to succeed. They'll say your idea sounds great because they like you, not because they'd pay for it. Their encouragement feels like validation but is actually noise.

The fix: don't ask "what do you think of this idea?" Ask "have you ever had this problem?" If they say yes, ask "how do you solve it today?" If they don't have a current solution, they don't actually have the problem.

---

## Exit Checklist

You're ready to move from Discovery to Validation when:

- [ ] You have 2-3 completed direction documents, each with a specific user profile
- [ ] Each direction is backed by at least 5 independent signals (not 5 signals from the same thread)
- [ ] You can articulate why *you* are well-positioned to solve each problem
- [ ] You've eliminated directions that are "interesting but not viable"
- [ ] You've set a deadline and haven't exceeded 4 weeks of discovery
- [ ] You're equally willing to pursue any of your 2-3 directions into validation

> ✅ The output of discovery is not a "great idea." It's a shortlist of directions with enough evidence behind them to justify spending 2-6 weeks on validation. You're not betting your life on any of them — you're betting a few weeks of conversations and landing pages.

---

## Next Step

Once you have your 2-3 directions documented, move to Validation. Pick the highest-scoring direction and test whether real strangers will pay for it — before you write a single line of code.

If you'd rather not spend hours every day manually scanning platforms for signals, [Opportunity Scanner](/reports) monitors 65+ data sources weekly and delivers the patterns in one report.


Learn systematic approaches to discover market gaps, validate demand signals, and pick the right idea before writing code. Stop building what nobody wants.

How to Find Product Opportunities Worth Building

Why Most Solo Founders Pick the Wrong Idea

Mistake 2: Confusing "Interesting" with "Viable"

Mistake 5: Asking Friends for Direction Feedback


## Why Most Solo Founders Skip the Wrong Step

### The Build-First Trap

You've spent 3 weeks collecting signals. You have a direction document. The problem is real, the user profile is clear, and you can already see the architecture in your head.

The temptation to open your editor is overwhelming. Every founder feels it.

Here's what happens when you give in:

You build for 2 months. You launch. You post on Reddit and Twitter. And then — silence. The signups don't come. The people who do sign up don't come back. You have a working product and zero evidence that anyone wants it.

The build-first trap is the most expensive mistake in solo development. It turns 2 months of work into a very expensive way to learn something you could have learned in 2 weeks with no code at all.

> The purpose of validation is not to prove your idea is good. It's to find out if it's bad — as cheaply and quickly as possible.

### What Validation Actually Is

Validation is the process of confirming that strangers — not friends, not colleagues, not people being polite — will take a concrete action that signals willingness to pay.

A concrete action is one of:

- **Giving you an email address** on a landing page that clearly describes the product and price
- **Scheduling a 20-minute call** to discuss their problem in detail
- **Paying a deposit** or pre-ordering before the product exists
- **Sending you a screenshot** of their current painful workflow

A concrete action is NOT:

- A like, retweet, or upvote
- "This sounds cool!"
- "Let me know when it's ready" (without giving contact info)
- Your mom saying she'd use it

Validation takes 2-6 weeks and requires zero code. The tools you need: a landing page builder, a calendar link, and the willingness to have awkward conversations with strangers.

---

## The Three Validation Methods

There are three primary ways to validate a product direction. Use at least two before moving to Build.

### Method 1: The Landing Page Test

**What it is:** A single page that describes your product, shows a price, and has one call to action — typically "Join the waitlist" or "Get early access."

**How to run it:**

1. Write a headline that names the user and the outcome: "Weekly reports that write themselves — for engineering managers who hate Fridays."
2. Write 2-3 sentences about what the product does. Focus on the outcome, not the features. "Connect your Slack, Jira, and GitHub. Every Friday morning, get a draft report in your inbox. Edit and send in 10 minutes instead of 3 hours."
3. Show a price. Not "Free" or "TBD" — a real number. Pricing signals seriousness. "$29/month" gets more honest reactions than "Contact us."
4. Add a single CTA: an email input + button. That's it. No "Learn More" link, no feature tour, no pricing page with three tiers. One page, one action.
5. Drive traffic to the page. Post in relevant subreddits, niche forums, Slack/Discord communities where your target users hang out. Do not post on "startup marketing" channels — you want target users, not other founders.

**What to measure:**

The conversion rate from visitor to email signup. But more importantly — the conversations you have with the people who sign up. Every signup is an opportunity for a 20-minute call.

> A landing page with 500 visitors and 50 signups is better than a landing page with 5,000 visitors and 50 signups. The first one found 50 people who really care. The second one wasted traffic on the wrong audience.

**How long:** 3-5 days to build and start collecting emails. 1-2 weeks of driving traffic.

### Method 2: The Problem Interview

**What it is:** A 20-minute conversation with someone who has the problem you want to solve. You are not selling. You are not showing a prototype. You are listening.

**How to run it:**

1. Find 10-15 people who match your target user profile. Reddit DMs, Twitter DMs, Slack communities, LinkedIn. The ask: "I'm researching [problem area] and would love 20 minutes of your time. No pitch, just listening."
2. Prepare 5 questions — but be ready to deviate. The best insights come from follow-ups, not from your script.

The five questions:

1. "Tell me about the last time you faced [problem]. Walk me through what happened."
2. "How did you solve it? What did you actually do?"
3. "What did you try before that? Why didn't it work?"
4. "How much time or money does this problem cost you per month?"
5. "Is there anything else about this problem I should have asked about?"

Notice what's missing: "Would you use a product that does X?" and "How much would you pay for this?" These questions generate polite lies. People say yes to be nice. People say they'd pay $50 and then don't pay $5.

Instead, look for evidence in their behavior:
- Have they paid for tools that address adjacent problems?
- Did they build their own janky solution (a spreadsheet, a script, a Zapier hack)?
- Do they bring up the problem unprompted, or only when you ask?

3. At the end of the call: "This has been really helpful. If I build something that solves this, would it be okay if I reached out to you to try an early version?"

If they say yes and give you their email, that's a weak positive signal. If they ask "when can I try it?", that's a strong one. If they say "please email me when you have something, I need this yesterday", you've found your first user.

**What to measure:**

After 10-15 interviews, categorize each person:

- **Strong signal:** They described the problem vividly, have tried multiple solutions, are actively spending money or time on it, and asked you to follow up.
- **Weak signal:** They acknowledged the problem exists but aren't actively trying to solve it.
- **No signal:** They were polite but the problem clearly isn't a priority.

If fewer than 5 out of 15 are strong signals, the direction is probably not worth building. If 8+ are strong signals, move to Method 3.

**How long:** 1-2 weeks to schedule and conduct 10-15 interviews.

### Method 3: The Pre-Order Test

**What it is:** Asking for money before the product exists. This is the strongest validation signal you can get — someone parting with actual cash.

**How to run it:**

1. After your landing page has collected emails and you've done interviews, email everyone who showed strong interest.
2. The email should say something like:

> "I'm building [product] to solve [problem]. I'm going to build it either way, but I'm offering a founding member deal: 50% off for life ($15/month instead of $30) for the first 20 people who pre-order. If I don't ship within 3 months, full refund."

3. You don't need a payment processor. A Stripe Payment Link takes 2 minutes to set up. Or use Gumroad, Lemon Squeezy, or even a PayPal link.

**What to measure:**

How many people actually pay. This is the only metric that matters.

- **0-2 pre-orders:** The direction is unvalidated. Either the problem isn't painful enough, the solution isn't compelling, or you're talking to the wrong people. Return to Discovery or try another direction.
- **3-9 pre-orders:** Moderate evidence. You have something, but not enough to quit your job. Consider whether you can narrow the audience further.
- **10+ pre-orders:** Strong evidence. Someone is willing to pay for this. Build the MVP.

> 💡 The pre-order test is uncomfortable. Asking strangers for money for something that doesn't exist feels wrong. But it's exactly this discomfort that makes it work — if you can't convince 10 people to risk $15 on a solution to a problem they supposedly have, the problem isn't real enough to build a business around.

**How long:** 1-2 weeks to run the pre-order campaign.

---

## What Good Validation Looks Like

### A Real Validation Story

A developer had a direction: a tool that automatically generates changelogs from git commits for SaaS teams.

**Week 1:** Built a landing page with Carrd (2 hours). Headline: "Changelogs that write themselves. Connect GitHub, publish with one click." Price: $19/month. CTA: "Get early access."

Posted in r/SaaS, r/webdev, and a few Slack communities. 34 signups in 5 days.

**Week 2-3:** Emailed every signup. "I'm researching how teams handle changelogs. 20-minute call?" Booked 12 calls.

Key findings from the calls:
- 8 out of 12 people had already tried to solve this (using git log + manual editing, or paying a VA to do it)
- The main objection: "We already have too many tools. Can this just post to our existing Slack channel?"
- One person said: "I've been asking my team to write a script for this for 6 months. If you build this, I'll be your first customer."

**Week 4:** Emailed the 8 strong-signal interviewees with a pre-order offer: "$49 lifetime (instead of $19/month) for the first 15 people."

**Result:** 11 people pre-ordered within 48 hours. $539 in pre-orders before a single line of code.

He started building the next day.

### A Real Failure Story (More Valuable to Study)

Another developer had a direction: a collaborative debugging tool for remote engineering teams.

Landing page: 200 signups. Seemed promising.

Interviews: 15 calls. Everyone said "this is a real problem." But:
- Only 2 people had tried to solve it themselves (the other 13 just "lived with it")
- No one was spending money on adjacent debugging tools
- When asked "how much time does this cost you?", answers were vague: "I don't know, a few hours maybe?"

Pre-order: 0 sales out of 200 signups and 15 positive conversations.

He killed the direction and moved to his second choice. That second direction became a profitable product.

> The landing page metrics said yes. The interview politeness said yes. The pre-order test said no. Only one of those three was telling the truth.

---

## Common Validation Mistakes

### Mistake 1: Asking "Would You Use This?"

This question produces exactly one answer: "Yes!" — regardless of whether the person would actually use it, pay for it, or even remember it tomorrow.

The fix: Ask about their behavior, not their opinions. "How do you solve this today?" reveals more than "Would you use my solution?"

### Mistake 2: Interpreting "That's Interesting" as Validation

"That's interesting" is the most dangerous phrase in validation. It sounds positive but means nothing. People find lots of things interesting — documentaries about deep-sea creatures, articles about Roman aqueducts, your product idea. They're not going to pay for any of them.

The fix: If someone says "that's interesting," follow up with: "Would you be willing to spend 20 minutes next week trying an early version?" If they hesitate, it was just interesting.

### Mistake 3: Validating With the Wrong People

Your friends say it's a great idea. Your former colleagues say they'd pay for it. People in your Slack community say they have this problem.

These people like you. They want you to succeed. Their feedback is contaminated by social pressure and should be discounted to near zero.

The fix: Validate with strangers who match your target user profile and have no social connection to you. Reddit, cold emails, niche forums. If the validation signal persists when nobody is being nice to you, it's real.

### Mistake 4: Collecting Emails Without Following Up

A waitlist of 200 emails is not validation. It's a list of 200 people who spent 3 seconds typing their email — and who will forget about you within 48 hours if you don't talk to them.

The fix: Email every single signup within 48 hours. Not a newsletter. Not a "thanks for signing up." A personal email from you asking for a 20-minute conversation. A 50-person waitlist with 10 interviews is worth more than a 500-person waitlist with zero conversations.

### Mistake 5: Building a "Validation Prototype" That Takes 3 Weeks

If your "validation" involves writing code for 3 weeks, you're building an MVP, not validating. Validation should take zero code. A landing page (Carrd, Notion, Google Forms), a calendar link (Calendly), and a way to collect payments (Stripe Payment Link) — that's the entire validation toolkit.

The fix: Set a rule: "I will not open my editor until I have 10 pre-orders or 10 strong interview signals." The keyboard is a validation escape hatch — you reach for it because coding is comfortable and talking to strangers is not.

### Mistake 6: The Long Landing Page

Your landing page should be scannable in 10 seconds. Headline. Two sentences. Price. CTA. Done.

A landing page with 8 sections, testimonials (whose? you haven't built anything), feature comparisons, and a FAQ is not validation — it's procrastination dressed as marketing. You're writing copy instead of testing whether anyone cares.

The fix: Set a timer for 90 minutes. Build the page. Publish it. Start sending traffic. You can improve the copy later — after you know whether the direction has any life in it.

---

## Exit Checklist

You're ready to move from Validation to Build when:

- [ ] You've tested at least 2 of the 3 validation methods (landing page, interviews, pre-orders)
- [ ] You've completed at least 10 user interviews with strangers who match your target profile
- [ ] At least 5 interview subjects showed strong signal (vivid problem description, existing workarounds, asked for follow-up)
- [ ] You have 10+ pre-orders OR 10+ interview subjects who explicitly asked to be notified when you launch
- [ ] You can describe the problem in your target users' words, not your own
- [ ] You understand what people currently do to solve this problem and why it's inadequate
- [ ] You have at least one backup direction ready if Build reveals that this direction needs a pivot
- [ ] You've set a hard timebox for the Build phase (maximum 12 weeks)

> ✅ The output of validation is not "proof my idea will succeed." It's sufficient evidence that the problem is real, the audience is reachable, and people will pay — enough evidence to justify spending 4-12 weeks building an MVP.

### If Validation Failed

Validation failure is normal and valuable. It saved you months of building the wrong thing.

What to do next:
1. If you had strong interview signals but zero pre-orders: your solution isn't compelling. Revisit the problem description. Ask interviewees what they'd actually pay for.
2. If you couldn't get interviews: your audience is unreachable with your current channels. Pick a direction where you can reach the users.
3. If everything was lukewarm: move to your second direction and run validation again. You didn't fail — you ruled out a bad direction cheaply.

---

## Validation Reference Card

| Method | Time | Strong Signal | Weak Signal | Red Flag |
|---|---|---|---|---|
| Landing Page | 1-2 weeks | ≥5% conversion + follow-up calls booked | ≥3% conversion, no calls | <1% conversion |
| Problem Interview | 1-2 weeks | ≥8/15 strong signals | 4-7/15 strong signals | <4/15 strong signals |
| Pre-Order | 1-2 weeks | ≥10 pre-orders | 3-9 pre-orders | 0-2 pre-orders |

---

## Next Step

Once validation confirms people will pay for your solution, move to Build. Your goal: ship something functional in the least amount of time and put it in front of the people who already told you they want it.

For more on the validation process, see the full [Validation guide](/guides/02-validation) with step-by-step instructions for landing pages, interviews, and pre-orders.


Learn to test whether strangers will actually pay for your product — using landing pages, user interviews, and pre-orders. Stop building products nobody wants.

How to Validate Your Product Idea Before Writing Code

Why Most Solo Founders Skip the Wrong Step

A Real Failure Story (More Valuable to Study)

Mistake 2: Interpreting "That's Interesting" as Validation

Mistake 3: Validating With the Wrong People

Mistake 4: Collecting Emails Without Following Up

Mistake 5: Building a "Validation Prototype" That Takes 3 Weeks


## Why AI-Era Tech Decisions Are Different

### The Old Rules Don't Apply

Five years ago, building a SaaS product meant choosing a backend framework, a database, and a hosting provider. Those choices were important but reversible — migrating from one database to another was painful but possible.

In the AI era, your tech stack decisions carry different weight:

- **Model choice directly affects your margins.** A $0.15/1K token model vs a $15/1K token model is the difference between 80% margins and losing money on every user.
- **Provider lock-in is real and expensive.** Switching from OpenAI to Anthropic or Google isn't a config change — it's a rewrite of prompts, function calling, and response parsing.
- **Cost compounds with scale.** A feature that costs $0.01 per request at 100 users costs $100/day at 10,000 users. Most solo founders never run this math until it's too late.

This guide covers the decisions that matter and which ones you can defer.

---

## Model Selection: Start with the Cheapest That Works

### The Tiered Model Strategy

Don't pick one model. Pick a tiered strategy:

| Tier | Use Case | What to Look For | Example Models |
|---|---|---|---|
| **Free / Ultra-Cheap** | Prototyping, internal tools, non-critical features | Generous free tier, fast inference | Gemini Flash Lite, Gemini Flash, gpt-4o-mini |
| **Quality (Default)** | Core product features, user-facing outputs | Best quality-to-cost ratio, good at following instructions | Claude Haiku, Gemini Flash, GPT-4o |
| **Premium (Fallback)** | Complex reasoning, edge cases the default model fails on | Highest accuracy, strong reasoning | Claude Sonnet, GPT-4o, Gemini Pro |

**The rule:** Start with the free/cheapest tier. Only move up when you have concrete evidence that the cheap model fails on specific cases your users care about.

### When to Upgrade

Upgrade from free to quality tier when:
- The model consistently misses important context in user inputs
- Output formatting is unreliable (JSON, structured data)
- Users report the same type of error 3+ times

Upgrade from quality to premium when:
- A specific feature requires multi-step reasoning (e.g., "analyze this spreadsheet and suggest budget cuts")
- The quality model hallucinates on domain-specific knowledge your product depends on
- You're generating content that directly generates revenue (e.g., marketing copy your users pay for)

> 💡 Most solo founders overestimate how good their model needs to be. A simple prompt with Gemini Flash Lite often outperforms a complex prompt with GPT-4o. The model is less important than the prompt engineering and the context you give it.

### The Hidden Cost of "Best Model" Thinking

Using GPT-4o or Claude Sonnet for everything is the most common AI cost mistake. Here's the math:

A product that generates weekly reports for users:
- With GPT-4o ($2.50/1M input, $10/1M output): ~$0.08 per report
- With Gemini Flash Lite (free tier): $0.00 per report
- At 1,000 users × 4 reports/month: $320/month vs $0/month

That $320/month doesn't matter if you have 1,000 paying users. It matters a lot when you have 10 users and are validating.

---

## Provider Strategy: Don't Marry One

### The Multi-Provider Pattern

The safest architecture for a solo founder:

```
Your App → Provider Router → [Primary: Free/Cheap Provider]
                            → [Fallback 1: Quality Provider]
                            → [Fallback 2: Premium Provider]
```

Implement a simple router that:
1. Tries the cheapest provider first
2. Falls back to the next tier on failure or timeout
3. Logs every fallback so you know which cases your cheap model can't handle

This pattern gives you:
- **Cost optimization by default** — most requests go through the cheap path
- **Resilience** — one provider's outage doesn't take down your product
- **Data on when models fail** — you learn exactly which cases need better models

### Provider Comparison

| Provider | Free Tier | Cheap Model | Best Model | Best For |
|---|---|---|---|---|
| **Google Gemini** | Gemini Flash Lite (1.5B RPM) | Flash ($0.15/1M) | Pro ($1.25/1M) | Best free tier, good all-rounder |
| **GitHub Models** | gpt-4o-mini (rate limited) | gpt-4o-mini ($0.15/1M) | gpt-4o ($2.50/1M) | Good free fallback, OpenAI ecosystem |
| **Anthropic** | No free tier | Haiku ($0.25/1M) | Sonnet ($3/1M) | Best at following instructions, code generation |
| **OpenAI** | No free tier | gpt-4o-mini ($0.15/1M) | gpt-4o ($2.50/1M) | Best ecosystem, function calling |

> 💡 Start with Gemini Flash Lite (free) + GitHub Models gpt-4o-mini (free) as your dual-provider setup. You get two independent free tiers from different companies. If both are down simultaneously, the internet has bigger problems.

### Provider-Agnostic Code

Never call a provider's SDK directly in your application logic. Always wrap it:

```javascript
// Bad: direct SDK call
const openai = new OpenAI()
const result = await openai.chat.completions.create({...})

// Good: provider-agnostic wrapper
const result = await llm.complete({
  messages: [...],
  strategy: 'cheapest-first',
  fallbacks: ['gemini-flash', 'gpt-4o-mini'],
})
```

This wrapper is 50 lines of code. It saves you from rewriting every AI call when you switch providers.

---

## Cost Control: Know Your Numbers Before They Know You

### The Three Numbers You Must Track

From day one, track these per request:

1. **Token count (input + output)** — most providers charge by token
2. **Model used** — so you know which features drive cost
3. **User ID or feature ID** — so you know which users/features cost the most

You don't need a fancy dashboard. A log line is enough:

```
[LLM] user=abc123 feature=weekly-report model=gemini-flash tokens_in=1200 tokens_out=800 cost=$0.0003
```

### Cost Projection Formula

Before launching a feature, estimate its cost at scale:

```
Monthly Cost = (Tokens per Request) × (Cost per Token) × (Requests per User per Month) × (Number of Users)
```

Example:
- Weekly report generation: 2,000 tokens per request
- Gemini Flash: $0.15/1M tokens = $0.00000015/token
- 4 reports/user/month
- 100 users

Monthly cost = 2,000 × $0.00000015 × 4 × 100 = $0.12

The same feature with GPT-4o: 2,000 × $0.00001 × 4 × 100 = $8.00

That's a 67x difference. For one feature. With 100 users.

> ⚠️ Don't optimize costs before you have users. But DO track costs from day one. The worst outcome is discovering your unit economics are negative after you've grown to 500 users and can't afford to serve them.

### Free Tier Stacking

As a solo founder, you can run a surprising amount on free tiers:

- **LLM:** Gemini Flash Lite (free) + GitHub gpt-4o-mini (free)
- **Hosting:** Vercel (free) + Supabase (free tier)
- **Auth:** Supabase Auth (free up to 50K MAU)
- **Database:** Supabase (free, 500MB)
- **Monitoring:** Sentry (free for solo devs)

Your only unavoidable cost for an AI product in 2026 is the domain name ($12/year). Everything else can run on free tiers until you have paying users.

---

## Architecture Decisions You Can Defer

### Decisions to Make Now

**1. Monolith over microservices.** You are one person. A single Next.js app with API routes is the right architecture until you have 10,000+ users. Microservices are for teams, not solo founders.

**2. Server-side AI calls only.** Never call an LLM from the browser. Your API key is exposed, users can modify prompts, and you lose cost control. All AI calls go through your API routes.

**3. Streaming for UX, not for cost.** Streaming tokens to the UI makes your app feel faster. But it doesn't save money — you pay for output tokens whether you stream or not. Implement streaming when users complain about waiting, not before.

**4. SQL over vector databases.** If you're building RAG, start with PostgreSQL + pgvector (Supabase includes this). Don't add Pinecone, Weaviate, or another vector DB until you've maxed out what pgvector can do. You probably never will.

### Decisions to Defer

**1. Fine-tuning.** Don't fine-tune a model until you have at least 1,000 examples of where prompt engineering fails. Fine-tuning is for optimization, not exploration.

**2. Multi-model ensembles.** Don't route the same request to 3 models and pick the best output. It triples your cost for marginal quality improvements. Only do this when you have revenue and users are complaining about quality.

**3. On-premise / self-hosted models.** Don't rent a GPU server to run Llama or Mistral yourself. The cost of a GPU instance ($1-3/hour) exceeds API costs until you're doing millions of requests per month. Revisit this when your API bill exceeds $500/month.

**4. Custom model training.** You don't need it. You'll likely never need it. If you think you need it, you're probably avoiding talking to users.

---

## The Solo Founder's Tech Stack (2026 Edition)

### Recommended Starting Stack

| Layer | Choice | Why |
|---|---|---|
| **Frontend** | Next.js (Pages Router) + Tailwind | Static export, SEO, fast to build |
| **Backend** | Next.js API Routes | No separate server needed |
| **Database** | Supabase (PostgreSQL) | Free tier, auth included, pgvector |
| **Auth** | Supabase Auth | Built-in, free, email + OAuth |
| **LLM Primary** | Gemini Flash Lite | Free, generous limits, good quality |
| **LLM Fallback** | GitHub Models gpt-4o-mini | Free, good as backup |
| **Hosting** | Vercel | Free tier, auto-deploy from git |
| **Payments** | Stripe / Lemon Squeezy | Pay-as-you-go, no monthly fees |
| **Email** | Resend (free tier) or SendGrid | Free up to 100/day |

### Principles

1. **Free tier first, paid only when you have revenue.** Every service above has a free tier that covers your first 1,000 users.
2. **Boring technology wins.** Your users don't care about your tech stack. Pick what you know best and ship faster.
3. **One person, one codebase.** Monorepo, single deploy, minimal moving parts. Complexity kills solo projects.
4. **Track costs from day one.** A single `console.log` with token counts. You'll thank yourself when you're optimizing.

---

## Common Build Mistakes

### Mistake 1: Over-Engineering for Scale That Never Comes

Building a message queue, worker system, and Redis cache before you have users. You're optimizing for problems you don't have.

The fix: Build for 100 users. If you reach 1,000, you'll have the revenue to fix scaling issues.

### Mistake 2: Chasing the Newest Model

A new model drops every month. Switching to the latest model every time is a distraction, not a strategy.

The fix: Re-evaluate models quarterly, not weekly. Unless a new model is 10x better or 10x cheaper, it doesn't matter for your product.

### Mistake 3: Complex Prompt Chains

Chaining 5 LLM calls where 1 would work. Each call adds latency, cost, and failure points.

The fix: Start with the simplest possible prompt. Only add complexity (chains, agents, multi-step reasoning) when the simple approach demonstrably fails.

### Mistake 4: Not Caching

Calling the LLM for identical or near-identical inputs. "What is the pricing?" answered the same way 500 times a day.

The fix: Cache LLM responses with a simple hash of the input. Even a 1-hour cache for common queries can cut your API costs by 50%+.

### Mistake 5: Building AI Features Nobody Asked For

Adding an "AI chatbot" to your product because it's trendy. Your users came for a specific problem — solve that well before adding AI for AI's sake.

The fix: Only add AI where it solves a specific, validated user need. "AI-powered" is not a feature — it's an implementation detail.

---

## Exit Checklist

You're ready to move from Build to Launch when:

- [ ] Your product's core flow works end-to-end without manual intervention
- [ ] All AI calls go through a provider-agnostic wrapper with fallback logic
- [ ] You're tracking token usage and cost per request (even if it's just a log line)
- [ ] Your tech stack is boring and stable (no experimental frameworks, no beta APIs)
- [ ] You've stress-tested the core flow with 5-10 real users
- [ ] Your monthly infrastructure cost is under $50 (or you have revenue to cover it)
- [ ] You've set up basic error monitoring (Sentry or equivalent)
- [ ] You've been in Build for less than 12 weeks (if longer, scope down)

> ✅ The output of Build is not a perfect product. It's a working product that solves one problem well enough that strangers will use it. Polish comes after you have users.

---

## Next Step

Once your product works and real users are testing it, move to Launch. Your goal: get at least 10 target users onto your product within 30 days.


How to choose AI models, pick providers, control costs, and avoid vendor lock-in as a solo founder building AI-powered products.

模型选择、供应商策略、成本控制、防锁定——AI 时代独立开发者构建产品的完整技术决策指南。

Building with AI: Tech Stack & Cost Strategy

AI 时代的技术栈与成本策略

Model Selection: Start with the Cheapest That Works

Cost Control: Know Your Numbers Before They Know You

The Solo Founder's Tech Stack (2026 Edition)

Mistake 1: Over-Engineering for Scale That Never Comes

Mistake 5: Building AI Features Nobody Asked For


## Why Most Launches Fail

### The "Post and Pray" Problem

The most common launch strategy among solo founders: finish the product, post it on Product Hunt and a few subreddits, tweet about it, and wait.

This is not a strategy. It's hoping.

Here's what actually happens with "post and pray":
- Product Hunt: buried on page 3, 12 upvotes (8 from friends)
- Reddit: removed by automod for self-promotion, or 3 upvotes and 1 comment saying "cool"
- Twitter: seen by your 87 followers, who are mostly other founders also launching products
- Result: 0 signups, demoralization, product abandoned within 2 weeks

> 💡 The people who succeed at launching aren't better at posting. They're better at preparation. A good launch starts 2-4 weeks before you ever click "publish."

### The Right Mindset

A launch is not an event. It's a process. Your goal is not "go viral" — it's "find 10 people who will actually use your product and tell you what sucks about it."

The goal of your first launch:
1. Get 10-50 real users (not other founders, not your friends)
2. Learn which acquisition channel works for your specific audience
3. Collect enough feedback to make the product better

Everything else — upvotes, traffic spikes, "going viral" — is a bonus.

---

## Channel Strategy: Where to Launch

### The Four Channels That Actually Work

| Channel | Best For | Time Investment | Typical Results | Risk |
|---|---|---|---|---|
| **Show HN** | Developer tools, dev workflow, infrastructure | 2-3 hours writing the post | 0-500 upvotes, lasting traffic for days | Buried with 0 upvotes if timing is bad |
| **Product Hunt** | B2B tools, productivity, design tools, AI products | 2-4 weeks prep + launch day | 20-200 upvotes, 100-1000 visitors | Low conversion to actual users |
| **Reddit** | Niche tools, community-specific products | 1-2 hours per post, ongoing engagement | 5-50 signups per good post | Removed for self-promo if done wrong |
| **Twitter/X** | Anything, but requires existing presence | Ongoing, months of building | 0-10 signups per thread | Zero reach without existing followers |

### Channel Selection Matrix

Which channel you use depends on your product type:

```
Developer tool → Show HN first, then relevant subreddits
B2B / Productivity → Product Hunt first, then LinkedIn/Twitter
Consumer / Community → Reddit first, then Twitter
Niche professional → That specific community first, nothing else matters
AI product → Product Hunt (AI category is hot) + Show HN
```

> ⚠️ Do not launch on all channels simultaneously. Pick one primary channel. Give it your full attention for 1-2 weeks. Learn what works. Only then add a second channel.

---

## Channel Playbooks

### Show HN

**What it is:** Hacker News' "Show" section where makers share what they've built. The audience is developers, founders, and tech-savvy early adopters.

**When to launch:** Tuesday, Wednesday, or Thursday, 7-10 AM ET. Monday people are catching up. Friday afternoon nobody is reading. Weekends are quiet.

**How to prepare:**

1. Your title must describe what the product does, not what it is. "Show HN: I built a tool that generates weekly reports from Slack and Jira" beats "Show HN: OnePerson — an AI-powered reporting platform."

2. The first comment is everything. Before you submit, write a detailed first comment that covers:
   - Why you built this (the problem you experienced)
   - Who it's for
   - What's different from existing solutions
   - What you're looking for (feedback? users? both?)
   - Tech stack (HN loves knowing what you built it with)

3. Have the product ready. HN users will:
   - Try every feature
   - Check your pricing page
   - Read your source code if it's open
   - Point out bugs in the comments

4. Don't ask for upvotes. Don't tell your friends to upvote. HN's voting ring detection is aggressive and accurate. Organic votes only.

**What to expect:**
- If it hits the front page: 5,000-20,000 visitors over 2-3 days
- If it gets 10-30 upvotes: 500-1,500 visitors, still worth it
- If it gets <5 upvotes: delete and try again in 2 weeks with a better title and first comment

The traffic is nice. The comments are better. HN commenters are brutally honest and technically literate. Their feedback is worth more than the traffic.

### Product Hunt

**What it is:** A daily leaderboard for new products. The audience is founders, product people, marketers, and early adopters.

**When to launch:** Tuesday, Wednesday, or Thursday. Never Monday (too many launches) or weekends (dead). Launch at 12:01 AM PT — the earlier you launch, the more time you have to collect votes.

**How to prepare (start 2-4 weeks before):**

1. **Find a hunter or launch yourself.** If you know someone with a large PH following, ask them to hunt your product. Otherwise, launch it yourself — self-launching is fine in 2026.

2. **Prepare your assets:**
   - Tagline (60 chars max): One sentence describing what it does and for whom
   - Description: A few paragraphs about the problem, your solution, and what makes it different
   - First comment: A personal story about why you built this
   - Images/GIFs: 3-5 screenshots or a product demo GIF (the GIF matters most)
   - Maker comment: Introduce yourself and what you're looking for

3. **Line up your supporters (ethically).** Reach out to 10-20 people who already know about your product and ask: "I'm launching on Product Hunt on [date]. If you find the product useful, I'd appreciate your support on launch day." Do NOT ask for upvotes. Do NOT create a "swap upvotes" group. PH detects and penalizes this.

4. **Engage on launch day.** Reply to every comment within minutes. Thank people for feedback. Answer questions. PH rewards engagement.

**What to expect:**
- Top 5 finish: 1,000-5,000 visitors, 50-200 signups
- Top 10 finish: 500-1,000 visitors, 10-50 signups
- Below top 10: 100-500 visitors, minimal signups
- Product Hunt users rarely convert to paying users. They're evaluating products, not buying them.

> 💡 Product Hunt is better for social proof than user acquisition. A "Top 5 Product of the Day" badge is great for your landing page. But don't expect PH to fill your user base.

### Reddit

**What it is:** Topic-specific communities (subreddits) where you can share your product if it genuinely helps the community.

**When to post:** Weekday mornings, US time. Check each subreddit's traffic stats on Reddit's analytics.

**How to prepare:**

1. Find the RIGHT subreddits. Not r/startups or r/SideProject — those are full of other founders, not users. Find the subreddits where your target users complain about their problems.

Examples:
- A tool for Notion users → r/Notion, r/productivity
- A tool for freelancers → r/freelance, r/Upwork
- A tool for teachers → r/Teachers, r/education

2. Be a community member first. Spend 1-2 weeks answering questions, commenting, being helpful. Redditors check your post history. If you only post about your product, you'll be ignored or banned.

3. Frame your post as "I made something that might help" rather than "Check out my product." Share the problem first, then the solution.

**Good Reddit post structure:**
```
Title: I got tired of [pain point], so I built [simple description]

Body:
- The problem I experienced (1-2 sentences)
- What I built to solve it (1-2 sentences)
- Who it might help
- Link
- "Would love feedback if you try it"
```

**What to expect:**
- A good post in a relevant niche subreddit (50K-200K members): 20-100 signups
- A post in r/webdev or r/programming: 0-10 signups (too broad)
- A post removed for self-promotion: if this happens, you didn't engage enough before posting

### Twitter/X

**What it is:** A real-time platform where building in public and sharing your journey can attract users over time.

**When to post:** This is an ongoing strategy, not a launch-day tactic. Start posting 2-3 months before your launch.

**How to prepare:**

1. Build in public. Share your progress, decisions, and mistakes. People follow journeys, not products.

2. Types of content that work:
   - "I asked 20 [target users] about [problem]. Here's what surprised me."
   - "Built [feature] this week. Here's the before/after."
   - "A user told me [unexpected feedback]. Changed my entire roadmap."
   - Screenshots of early versions with commentary

3. Don't just post about your product. Reply to other people's posts about the problem space. Be helpful first, promotional second.

**What to expect:**
- With <500 followers: expect 0-10 signups per launch-related post
- With 1,000-5,000 followers: 10-50 signups
- Twitter is a long game. Don't expect launch-day results.

---

## The Launch Week Playbook

### Day -14 to -7: Preparation

- [ ] Pick your primary launch channel
- [ ] Prepare all assets (screenshots, demo video/GIF, written copy)
- [ ] If Product Hunt: set up your upcoming page and start collecting "notify me" subscribers
- [ ] If Reddit: start engaging in target communities
- [ ] Set up analytics (at minimum, know where signups come from)

### Day -7 to -1: Final Testing

- [ ] Have 5 people test your product end-to-end and report every bug
- [ ] Fix critical bugs (ignore cosmetic issues, fix anything that blocks core flow)
- [ ] Write your launch posts and have someone review them
- [ ] Prepare your "first comment" or "maker story"
- [ ] Set up a simple onboarding flow (users should understand the product in 30 seconds)

### Launch Day

- [ ] Post at the optimal time for your channel
- [ ] Immediately add your detailed first comment
- [ ] Stay online and respond to every comment/feedback for the first 4-6 hours
- [ ] Share the launch link with people who previously expressed interest (NOT "please upvote")
- [ ] Monitor for bugs and critical issues

### Day +1 to +7: Follow Through

- [ ] Personally email every new signup within 48 hours
- [ ] Ask: "What made you sign up? What almost stopped you?"
- [ ] Track which channel brought the most engaged users (not just the most visitors)
- [ ] Fix the top 3 issues users report
- [ ] Write a "launch retrospective" to share on your secondary channel

---

## Common Launch Mistakes

### Mistake 1: Launching Too Early

Your product doesn't need to be perfect. But if the core flow is broken or the landing page doesn't explain what you do, wait.

The fix: Have 5 strangers try your product and watch them without helping. If 3/5 can complete the core flow, you're ready.

### Mistake 2: Launching Too Late

The opposite problem. You keep adding "one more feature" and never launch. Six months go by.

The fix: Set a hard launch date 4 weeks out. Tell people publicly. The social pressure will force you to ship.

### Mistake 3: Targeting Other Founders

Launching on r/startups, r/SideProject, Indie Hackers, and founder Twitter. You get upvotes and encouragement from people who will never be your customers.

The fix: Launch where your users are. If you're building for accountants, find the accountant communities. If you don't know where they hang out, return to Discovery.

### Mistake 4: No Call to Action

A beautiful launch post with no clear next step. "Check it out" is not a CTA. "Sign up and generate your first report in 2 minutes" is.

The fix: Every launch post should have exactly one clear action you want people to take. Sign up. Try a demo. Join the waitlist. One action. One link.

### Mistake 5: Defending Instead of Listening

HN commenter: "This is just a wrapper around GPT." You: "No it's not, we also have..." — don't do this.

The fix: When someone criticizes your product, say "Thanks for the feedback. What would make it not feel like a wrapper to you?" Feedback is a gift. Defensiveness is a waste.

### Mistake 6: Launching and Leaving

You post, you get some traffic, and then you go back to building. The signups trickle to zero because nobody is actively pulling them in anymore.

The fix: Launch is the start of distribution, not the end. After launch week, dedicate 30-60 minutes daily to distribution: engage in communities, reply to relevant posts, share updates.

---

## What Success Looks Like

A successful first launch is NOT:
- #1 Product of the Day
- 10,000 signups
- Going viral on Twitter

A successful first launch IS:
- 10-50 real users actively using your product
- You know which channel brought your best users
- You have a list of the top 5 things to fix or improve
- At least one user has told you "I need this" without prompting
- You have the energy and feedback to keep building

> ✅ The launch is not the finish line. It's the starting line. Everything before launch was practice. The real work — building something people want and pay for — starts the day after you launch.

---

## Launch Channel Quick Reference

| Channel | Prep Time | Best Day/Time | Success Metric | Red Flag |
|---|---|---|---|---|
| Show HN | 1 week | Tue-Thu 7-10 AM ET | Front page (>30 upvotes) or 500+ visitors | <5 upvotes, zero comments |
| Product Hunt | 2-4 weeks | Tue-Thu, 12:01 AM PT | Top 10 finish or 50+ signups | <20 upvotes |
| Reddit | 1-2 weeks in community | Weekday mornings US | 20+ signups per post | Post removed, zero engagement |
| Twitter/X | 2-3 months building presence | Weekdays | 10+ signups, quality conversations | Zero replies to launch thread |

---

## Next Step

After launch, shift from "getting users" to "keeping users and learning from them." Move to Operations — track your metrics, reduce churn, and build what your users actually need.


A complete launch playbook for solo founders: Product Hunt, Show HN, Reddit, Twitter — what works, when, and why. Get your first 100 users without a marketing budget.

独立开发者发布产品的完整策略：Product Hunt、Show HN、Reddit、Twitter——什么渠道有效、什么时候做、为什么。不花营销预算获取前 100 个用户。

How to Launch & Get Your First Users

如何发布产品并获取第一批用户

Mistake 5: Defending Instead of Listening


## Why Operations Matter More Than Building

### The Post-Launch Reality

You launched. You have users. You're getting feedback. The temptation is to keep building features at the same pace as before.

This is a mistake.

After launch, building more features has diminishing returns. Your existing users don't need a new dashboard. They need the product to work reliably, to get help when they're stuck, and to feel like it's getting better — not bigger.

The shift from Build mentality to Operations mentality is the difference between a product that grows and one that slowly dies.

> 💡 In the Build phase, your job was to create. In the Operations phase, your job is to listen, measure, and respond. The keyboard is no longer your primary tool. Your primary tools are your analytics, your inbox, and your calendar.

---

## The Only Metrics That Matter

### The Three-Metric Dashboard

Most analytics tools give you 50+ metrics. As a solo founder, you need exactly three:

**1. Active Users (Weekly)**

Definition: Users who performed a core action in the last 7 days. A core action is the one thing your product exists to do — generate a report, send a message, create a document.

Why weekly, not daily: Daily active users (DAU) is too noisy for B2B or productivity tools. Most people don't use productivity tools every day. Weekly smooths out the noise and shows real engagement.

What to watch: Week-over-week growth or decline. A single down week doesn't matter. Three consecutive down weeks is an emergency.

**2. Churn Rate (Monthly)**

Definition: Percentage of users who were active last month but not this month.

Formula: (Users active in month N-1 but not in month N) / (Users active in month N-1) × 100

What to watch:
- <5% monthly churn: Healthy
- 5-10% monthly churn: Pay attention, investigate
- >10% monthly churn: Critical. Stop building features. Talk to users.

**3. Net Revenue (Monthly)**

Definition: New revenue minus lost revenue for the month.

If you're not charging yet: track "active user growth rate" instead.

What to watch: Is it going up or down? That's it. As a solo founder, you don't need MRR growth rate, ARPU, LTV, CAC, or any other acronym. Just "is revenue going up?"

> 💡 These three numbers tell you everything: Are people using it? Are they staying? Are they paying? Everything else is noise until you have 1,000+ users.

### The Metrics You Can Ignore

- **Total signups:** A growing number that tells you nothing about whether people actually use your product.
- **Page views:** You're not selling ads. Page views don't matter.
- **Bounce rate:** Your landing page is for conversion, not browsing. Bounce rate is misleading for single-page products.
- **NPS (Net Promoter Score):** You need at least 100 responses for statistical significance. Your 12 survey responses don't mean anything.
- **LTV / CAC ratio:** This matters when you're spending money on ads. You're not. Skip it.

---

## Detecting Churn Before It Happens

### The Leading Indicators

Users don't disappear overnight. They fade. Here's what fading looks like:

| Leading Indicator | Signal | Action |
|---|---|---|
| **Decreasing frequency** | Used 4x/week → 2x/week → 1x/week | Reach out before it hits 0 |
| **Shallow usage** | Logs in, looks around, doesn't do the core action | The product isn't delivering value fast enough |
| **Support silence** | User who used to ask questions stops engaging entirely | They've given up. Email them. |
| **Feature requests stop** | "Can you add X?" → silence | They're looking for alternatives |
| **Downgrade browsing** | Visited pricing page or settings multiple times | They're considering leaving |

### The "Red Flag" Email

When you spot a leading indicator, send this email within 24 hours:

```
Subject: Quick check-in

Hey [name],

I noticed [specific observation — "you haven't generated a report in 2 weeks"
or "you visited the pricing page a few times"].

Just wanted to check in — is there something missing? Something broken?
Something you expected but didn't find?

No need for a long reply. Even "busy right now" is helpful.

[Your name]
```

Key principles:
- Be specific about what you noticed (proves you're paying attention)
- Ask open-ended but directed questions
- Make it easy to reply (even a one-word answer is fine)
- Do NOT offer a discount or free month. You're trying to understand the problem, not bribe them to stay.

> 💡 This email has saved more solo founder businesses than any feature ever built. Most users who are about to churn will tell you exactly why if you just ask.

### The Churn Interview

When a user does churn, ask for a 10-minute exit call. Most will say no. Some will say yes. Those conversations are gold.

Questions for the exit call:
1. "What made you sign up originally?"
2. "What changed between then and now?"
3. "What are you using instead?"
4. "If we had done one thing differently, what would have kept you?"

The answer to question 3 is the most important. You'll learn who your real competitors are — not the companies you listed in your competitive analysis, but the actual alternatives people switch to.

---

## Growth Without a Marketing Budget

### The Three Growth Levers for Solo Founders

**Lever 1: Word of Mouth (Free)**

The best growth channel. It costs nothing and brings your highest-quality users.

How to generate it:
- Make one specific thing exceptionally good. Not "the product is good overall." One specific thing that makes users say "you have to try this."
- Make sharing easy. Add a "Share" button that generates a pre-written message.
- Ask at the right moment. Not during onboarding. Right after the user achieves something — generates their first report, completes their first project. That's when they're most likely to tell others.

**Lever 2: Content (Time Investment)**

Write about the problem space, not your product.

- Blog posts answering the exact questions your users Google: "how to write a weekly status report," "best tools for engineering managers"
- Share data and learnings from building your product: "I interviewed 50 engineering managers about weekly reporting. Here's what I learned."
- Post in communities where your users already are. Not "check out my product" but "here's something useful about [problem]."

Content compounds. A post you write today will bring traffic for years.

**Lever 3: Product-Led Growth (Built Into the Product)**

Make your product bring in new users by design:

- **Collaboration features:** If your product works better with teammates, users will invite them.
- **Shared outputs:** If users generate something they can share (a report, a dashboard, a page), every share is a distribution channel.
- **Free tier that's actually useful:** Not a crippled demo. Something people use regularly, which means they talk about it.

> 💡 As a solo founder, you can realistically do one growth activity per day. Make it count. 30 minutes of genuine engagement in a community where your users hang out is worth more than 3 hours of tweeting into the void.

### The 30-Minute Daily Growth Routine

Every day, do ONE of these:

- **Monday:** Write and publish a short blog post or Twitter thread about the problem space
- **Tuesday:** Answer 5 questions in communities where your users hang out (Reddit, Slack, Discord)
- **Wednesday:** Reach out to 3 users personally — check in, ask for feedback, see how they're doing
- **Thursday:** Work on one product improvement that increases sharing or collaboration
- **Friday:** Review your metrics. Write down one thing you learned this week about your users.

Consistency over volume. Do this for 3 months and you'll have a growth engine.

---

## Pricing That Works for Solo Founders

### The Simple Pricing Rule

If you're a solo founder, your pricing should be simple enough to explain in one sentence:

- "Free for 1 project, $19/month unlimited." ✓
- "Starts at $12/month per seat, with volume discounts for teams of 5+ and an enterprise tier with SSO." ✗

Simple pricing means:
- Fewer support questions
- Faster purchasing decisions
- Less cognitive load on your landing page
- Easier for users to tell others about

### When to Raise Prices

Signs it's time to raise prices:
1. Your conversion rate is above 5% (visitor → paid) — your product is undervalued
2. Nobody complains about the price — you're leaving money on the table
3. Your churn is below 5% — users are getting more value than they're paying for
4. You have more demand than you can handle — raise prices to match supply

How to raise prices:
- Grandfather existing users at their current price. Always.
- Announce the change 30 days in advance.
- Tie the increase to new value you've shipped: "Since launching, we've added X, Y, and Z. Starting next month, the price will be..."

> ⚠️ Most solo founders undercharge by 50-100%. Your product solves a real problem. Charge what it's worth.

---

## Your Support System

### Support as a Growth Channel

As a solo founder, support is not a cost center. It's your best growth channel.

Why:
- Every support interaction is a chance to learn what's confusing or broken
- Fast, personal support is the one thing you can do better than big companies
- Users who get great support tell others

Rules for solo founder support:
1. Respond within 24 hours. Faster is better, but 24 hours is the maximum.
2. Be personal. Sign your name. Reference their specific situation.
3. If you fix a bug they reported, tell them personally. They'll remember.
4. If they request a feature, don't promise it. Say "noted, and here's why it may or may not happen soon."

### When to Automate Support

Never automate support until you've manually answered the same question 20+ times. Then:
1. Add it to a FAQ or docs page (not a chatbot)
2. Improve the product so the question doesn't need to be asked

Chatbots and automated replies signal "I don't have time for you." As a solo founder, your time for users is your competitive advantage.

---

## Keeping Yourself Operational

### Founder Burnout Is a Business Risk

The biggest threat to your product's operations is not a competitor or a server outage. It's you quitting.

Warning signs:
- You dread opening your analytics
- You avoid user emails for days
- Building feels like a chore, not an excitement
- You're checking competitor products obsessively

### The Sustainable Solo Founder Schedule

- **Deep work (building):** 3-4 hours in the morning. This is when you build and fix things.
- **Shallow work (support, community, admin):** 1-2 hours in the afternoon. Reply to users, engage in communities, check metrics.
- **Rest:** Evenings and at least one full weekend day off. The product will survive without you for a day.

If your product requires you to be available 24/7, you don't have a business — you have a job with extra steps. Fix the product so it can run without you, or set clear expectations with users about response times.

---

## The Monthly Operations Review

Once a month, spend 2 hours reviewing your product's health:

**1. Metrics Review (30 min)**
- Active users: Up or down? By how much?
- Churn: Above or below 5%?
- Revenue: Up or down?

**2. User Feedback Review (45 min)**
- Read through the month's support conversations
- Group feedback into themes: bugs, feature requests, confusion points
- Pick the top 2 themes to address next month

**3. Competitive Review (30 min)**
- Check what competitors shipped this month
- Has anyone new entered the space?
- Are there signals you should be paying attention to?

**4. Personal Review (15 min)**
- How's your energy level?
- Are you spending time on the right things?
- What's one thing you'll do differently next month?

---

## Operations Quick Reference

| What | How Often | Time | Tool |
|---|---|---|---|
| Check 3 key metrics | Weekly (Friday) | 10 min | Supabase dashboard or custom analytics |
| User outreach (check-ins) | Weekly (3 users) | 30 min | Email |
| Community engagement | Daily (30 min) | 2.5 hrs/week | Reddit, Slack, Discord, Twitter |
| Bug fixes | As needed | Variable | Your editor |
| Monthly review | Monthly | 2 hrs | Notes app + analytics |
| Churn follow-up | Within 24 hrs of detecting signal | 15 min each | Email |
| Price evaluation | Quarterly | 1 hr | Spreadsheet |

---

## Conclusion

Operations is not glamorous. There are no launch-day highs, no "I built this in a weekend" thrills. It's the daily discipline of listening, measuring, and improving.

But operations is where products become businesses. A well-operated solo product with 50 users is more sustainable than a poorly-operated one with 5,000.

The framework comes full circle: Discovery → Validation → Build → Launch → Operations. And if something breaks in Operations? You know exactly where to go — back to Discovery to find new signals, back to Validation to test new ideas, back to Build to fix what's broken.

The cycle never ends. But now you have a map.


Which metrics actually matter for a solo founder, how to detect churn before it happens, and how to grow with minimal effort. Sustainable operations for one-person businesses.

独立开发者真正该关注哪些指标、如何在流失前发现预警、如何用最少精力增长。一个人的可持续运营指南。

SaaS Operations: Metrics, Retention & Growth

SaaS 运营：指标、留存与增长