Written by Huifer, solo developer and maintainer of TanStack Ship. Across twelve production SaaS apps — billing platforms, dev-tools, two B2B marketplaces, and a community analytics product — I have moved through the same milestone ladder eight times end-to-end and partially four more. This guide is the consolidation: the eight stages, the week-by-week plans, the decision gates, the anti-patterns that cost me a quarter each, and the planning artifacts that survive contact with reality. Every milestone below is one I have personally cleared. TanStack Ship is my paid product; I name that bias up front.
Verified sources: Cloudflare Workers Documentation · Stripe Subscriptions API · Y Combinator — How to Plan an MVP · NSF I-Corps — Customer Discovery Framework · TanStack Start Documentation · Stripe Launch Checklist · Lean Startup — Eric Ries · TanStack Ship GitHub Organization · TanStack Ship planning templates repo
Last updated: 2026-07-31 · Changelog
TL;DR: A milestone is not a date — it is an evidence-driven threshold that proves the previous stage worked. For a solo SaaS in 2026, eight milestones carry you from blank page to sustainable revenue: Pre-build, Idea validation, MVP, Private beta, Public launch, First $1k MRR, First $10k MRR, Sustainable. Each milestone has one decision gate with a numeric threshold (three paying customers, $1k MRR, $10k MRR). Each gate either advances you to the next stage or sends you back to fix something in the previous one. This article walks through all eight stages, the week-by-week plans inside the critical ones, the anti-patterns that cost me a quarter each, and the planning artifacts that survive contact with reality. For the runtime choices inside each milestone, see the SaaS architecture 2026 guide; for the data layer inside the MVP and beta stages, see the D1 production guide; for the auth surface during private beta, see the SaaS authentication guide.
Why milestones, not deadlines, drive a solo SaaS
The single most common planning mistake I have watched other solo founders make — and made myself three times — is confusing a milestone with a deadline. A deadline is a date by which something must be done. A milestone is an evidence threshold that proves the previous stage worked. The distinction matters because deadlines survive failure (you miss the date, the work is unchanged), while milestones do not — if you do not clear the gate, you have not advanced, regardless of how many weeks you spent.
The other mistake is treating the milestone ladder as a wish list rather than a sequence. Twelve apps in, the sequence is the same every time. According to Y Combinator's library on MVP planning, the canonical B2B SaaS sequence is similar: problem, solution, MVP, first customers, repeatable sales. The eight stages below are the operational version of that sequence, with concrete decision gates at every transition.
A milestone framework has three properties a deadline framework does not. First, it is honest about uncertainty: you cannot know in advance how many weeks an MVP will take, but you can define what evidence the MVP must produce. Second, it is kill-friendly: when a milestone does not clear, you stop pushing to the next one — you go back and fix the stage that failed. Third, it is portable across stacks: whether you build on Cloudflare Workers, Next.js, Rails, or Django, the eight stages are the same.
The eight-stage milestone ladder
After twelve apps the pattern that keeps surviving is an eight-stage ladder. The first four stages pre-launch; the next four stages post-launch. The boundary is intentional — the first half is about building the right thing, the second half is about selling it.
Stage 0 — Pre-build (week 0)
You are not building anything yet. The output is a one-page brief that survives the rest of the ladder. The decision gate at the end of Stage 0 is: you can describe the problem in one sentence, the buyer in one sentence, the core transaction in one sentence, and you have named three people who feel this pain. If any of those four are missing, you are not ready for Stage 1. The NSF I-Corps customer discovery framework is the formal version of this gate; the informal version is "have you talked to anyone who would pay?"
Stage 1 — Idea validation (weeks 1–3)
You validate the problem before validating the solution. The work: ten customer interviews, a landing page with a waitlist, a manual concierge test where you do the work by hand for one or two people. The decision gate is the pay-the-bill test: at least one person has handed you a credit card, a check, or a wire for something that addresses the same problem. A waitlist signup does not count. An email reply does not count. The first time I cleared this gate was a $200 wire from a founder who had been losing sleep over a manual process; the second was a Stripe pre-order for a $99 lifetime license. The gate is the same.
Stage 2 — MVP (weeks 4–10)
You build the smallest thing that can clear Stage 1's gate repeatedly. The work: one core transaction end-to-end, one payment flow, one auth flow, one deploy pipeline. The decision gate at the end of Stage 2 is three paying customers — not three signups, three people who have actually paid. Three is the smallest sample that tells you whether the problem-solution fit is real or whether your first customer was an outlier.
Stage 3 — Private beta (weeks 11–16)
You widen the funnel while narrowing the surface. The work: ten to twenty-five paying users, support volume tolerable to one person, the top three reported bugs fixed, monitoring in place. The decision gate is retention at four weeks — at least 60% of week-1 users are still active in week 5. Below 60% and you have a leaky bucket; above 60% and you have something worth launching. The SaaS architecture at this stage is usually a single Cloudflare Worker for the API, a managed Postgres or D1 for the data, a single Stripe webhook for billing — see the D1 production guide for the data layer and the SaaS API guide for the API shape.
Stage 4 — Public launch (weeks 17–22)
You go from a private audience to public traffic. The work: launch checklist complete, support inbox routable, error budgets defined, pricing page public, Stripe launch checklist signed off, three channels of acquisition primed. The decision gate is a public launch that produces five new signups in the first week from cold traffic — not from your private list. The number five is small enough that almost any product can clear it and large enough to be evidence that someone outside your warm network finds the product. For the launch play, see the Product Hunt launch playbook.
Stage 5 — First $1k MRR (months 6–9)
You are post-launch with a small but real customer base. The work: tightening onboarding, adding the second and third acquisition channels, narrowing churn, instrumenting revenue. The decision gate is $1,000 in monthly recurring revenue — not a one-time payment, recurring. Stripe Subscriptions API is the canonical implementation; the threshold is high enough to prove the product has a retention curve and low enough to be reachable inside three months of public launch. Eight of twelve apps cleared $1k MRR; the four that did not were either killed or pivoted back to Stage 1.
Stage 6 — First $10k MRR (months 9–18)
You have product-market fit in the loose sense. The work: pricing experiments, the first hire (often a part-time contractor for support), formalized onboarding, the first paid acquisition channel. The decision gate is $10,000 in monthly recurring revenue — roughly the threshold where the SaaS can pay for one full-time engineer in a low-cost-of-living geography or fund a meaningful contractor budget. The hard part is not the product — it is the sales motion. Apps that cleared this stage had either a self-serve funnel that converted cold traffic (three of them) or a founder-led sales motion with a cycle under 30 days (two of them). The remaining three did not clear and stayed in Stage 5.
Stage 7 — Sustainable (months 18+)
You have an operationally stable business. The work: documented onboarding, monitored error budgets, a small but complete team (1 founder + 1–3 contractors), a portfolio of acquisition channels, and word-of-mouth compounding. The decision gate is $10k MRR stable over six consecutive months with churn under 5% monthly. The SaaS is no longer an experiment; it is a small business. Four of twelve apps reached this stage; the others either stalled or were wound down.
Planning a single milestone: the week-by-week template
A milestone is not a week; it is a stage that takes a variable number of weeks. Inside a stage, you plan by week. The template I use for every stage from Stage 2 onward is the same shape — it is the planning artifact that has survived the most rewrites.
milestone: mvp
stage: 2
expected_weeks: 7 # estimate, revised weekly
decision_gate: three_paying_customers
gate_threshold: 3
weeks:
- week: 4
focus: core_transaction
deliverable: one_user_can_complete_the_core_action
risk: highest_risk_assumption_about_problem_solution_fit
time_box: 30_hours
- week: 5
focus: payment
deliverable: stripe_checkout_live_with_test_and_live_keys
risk: billing_integration_can_break_in_three_known_ways
time_box: 18_hours
- week: 6
focus: auth
deliverable: email_password_oauth_for_one_provider_live
risk: better_auth_oauth_state_mismatch_known_postmortem
time_box: 22_hours
- week: 7
focus: deploy
deliverable: production_url_live_with_observability
risk: cold_start_first_request_can_exceed_3s_on_workers
time_box: 14_hours
- week: 8
focus: bug_bash
deliverable: top_five_user_reported_bugs_resolved
risk: support_volume_unknown_until_users_present
time_box: 16_hours
- week: 9
focus: convert_first_three
deliverable: three_paying_customers_charged_via_stripe
risk: first_three_are_slower_than_subsequent_three
time_box: 12_hours
- week: 10
focus: gate_review
deliverable: gate_cleared_or_back_to_stage_1
risk: gate_failure_means_revisiting_problem_not_solution
time_box: 8_hours
The shape is fixed; the contents change. Three rules govern the contents. First, each week has one focus, not three — splitting a week across two focuses is the same as missing the focus. Second, every week's deliverable is observable by an external user — "code merged" is not a deliverable; "stripe checkout live" is. Third, the time box is the time you actually spend, not the calendar time; weeks five and six may take seven days each in calendar but only eighteen and twenty-two hours of focused work.
The gate review at the end of every stage is non-negotiable. If you have not cleared the gate, you do not advance. The most expensive mistake I have made is advancing to Stage 4 with only two paying customers because I was "running out of runway"; the launch flopped, the two customers churned, and I spent six weeks recovering. The gate is there because it is the cheapest place to fail.
Decision gates: when to advance, hold, or kill
The decision gates are the load-bearing structure of the ladder. Every gate is a single numeric threshold, and every gate has three outcomes: advance, hold, or kill.
Advance is the obvious case: the threshold is cleared, you move to the next stage with the resources you have. Hold is the case where the threshold is plausible but not yet cleared: keep spending, recheck in two weeks, do not add new surface area. Kill is the case where the threshold is unrealistic given your evidence: stop, return to the previous stage, fix what failed, and consider whether to keep going at all.
The hardest gate in the ladder is Stage 5's $1k MRR threshold. Eight of twelve apps cleared it. The four that did not shared a single characteristic: a single acquisition channel that was founder-driven (cold email, founder network, Twitter) and no organic or paid channel. The eight that cleared it had the opposite — at least two acquisition channels, one of which was organic or paid. A single founder-driven acquisition channel does not scale to $1k MRR, period.
The second hardest gate is Stage 1's pay-the-bill test. Four of sixteen attempts failed. The failures all looked the same: a single conversation the founder interpreted as validation. The successes had at least three independent signals — a wire, a pre-order, a credit card on a checkout link, or an LOI signed by a procurement team.
Anti-patterns: milestones that waste a quarter
Three anti-patterns have cost me a quarter each across twelve apps. They are easy to repeat and worth naming.
The first is over-planning the pre-build stage. Two of my apps spent eight weeks on market research, competitive analysis, and pricing strategy before writing a line of code. Both took longer to clear Stage 1 than apps where I shipped a one-page brief in week one. The bias to fix is the assumption that more research reduces risk; empirically, customer interviews and a landing page test the hypothesis faster than a 30-page doc.
The second is building three features in the MVP. Every MVP I shipped with three features took 12–14 weeks; every MVP with one feature took 6–8 weeks. The trap is the assumption that the buyer wants a complete product; empirically, the buyer wants the core transaction to work. The Lean Startup methodology is the formal version of this lesson, but the number — three features at 12 weeks versus one feature at 6 weeks — is what changed my behavior.
The third is premature scaling. Two of my apps went straight from Stage 3 (private beta) to Stage 6 (targeting $10k MRR) without passing through Stage 5. Both stalled because the sales motion was not repeatable; the founder was the sales motion, and a founder can only close so many deals per week. The recovery was to drop back to Stage 5, build a self-serve or short-cycle sales motion, and re-clear the gate at the lower threshold before attempting the higher one.
Planning artifacts that survive contact with reality
Three artifacts are worth standardizing. The first is the milestone card — a one-page document per stage, with the goal, the decision gate, the week's deliverables, and the kill criteria. The second is the weekly plan — a YAML or JSON file with the seven days of the week, each day's focus, time box, and risk. The third is the gate review — a single document at the end of each stage that records the evidence: the three paying customers, the retention curve, the $1k MRR screenshot. These three artifacts live in the TanStack Ship planning templates repo.
{
"stage": 2,
"name": "MVP",
"expected_weeks": 7,
"decision_gate": "three_paying_customers",
"gate_threshold": 3,
"evidence_at_clear": [
{ "customer_id": "cus_001", "amount_usd": 99, "date": "2026-05-14" },
{ "customer_id": "cus_002", "amount_usd": 49, "date": "2026-05-19" },
{ "customer_id": "cus_003", "amount_usd": 149, "date": "2026-05-22" }
],
"kill_criteria": [
"no paying customer after week 8",
"two consecutive weeks with < 5 signups from waitlist",
"first customer requests a refund before week 4"
],
"advance_to": "stage-3-private-beta",
"reviewed_by": "founder",
"reviewed_on": "2026-05-23"
}
The artifacts are not bureaucracy. They are the only mechanism a solo founder has to detect when a stage has quietly failed. Without the gate review document, the failure shows up three months later as churn; with the document, it shows up the day after the gate fails, when there is still time to recover.
Closing CTA
The eight-stage ladder is the planning framework I have used across twelve apps. It is not the only one that works; it is the one that has survived contact with reality the most often. If you are starting a SaaS, the cheapest thing you can do today is write the Stage 0 brief — one sentence per question — and check whether you have three people who feel the pain. If you do not, save the eight-week investment and stay in Stage 0 until you do.
For the runtime choices inside the build stages, see the SaaS architecture 2026 guide; for the data layer inside MVP and beta, see the D1 production guide; for the auth surface during private beta, see the SaaS authentication guide. The TanStack Ship planning templates repo has the milestone card, weekly plan, and gate review templates as a starting point. The TanStack Ship features page has the runtime primitives; the pricing page has the packaging model that Stage 5 onward assumes.