Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Bei zwölf Produktions-SaaS-Anwendungen – Billing-Plattformen, Dev-Tools, zwei B2B-Marktplätze und ein Community-Analytics-Produkt – bin ich dieselbe Meilenstein-Leiter achtmal komplett und viermal teilweise durchlaufen. Dieser Leitfaden ist die Konsolidierung: die acht Stufen, die Wochenpläne, die Entscheidungstore, die Anti-Patterns, die mich jeweils ein Quartal gekostet haben, und die Planungs-Artefakte, die den Kontakt mit der Realität überstehen. Jeder der folgenden Meilensteine ist einer, den ich persönlich erreicht habe. TanStack Ship ist mein kostenpflichtiges Produkt; ich benenne diese Verzerrung offen.
Verifizierte Quellen: 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: Ein Meilenstein ist kein Datum – er ist ein evidenzbasiertes Tor, das beweist, dass die vorherige Stufe funktioniert hat. Für ein Solo-SaaS im Jahr 2026 führen acht Meilensteine von der leeren Seite zum nachhaltigen Umsatz: Pre-Build, Ideenvalidierung, MVP, Private Beta, Public Launch, Erste $1k MRR, Erste $10k MRR, Nachhaltiger Betrieb. Jeder Meilenstein hat ein Entscheidungstor mit einem numerischen Schwellenwert (drei zahlende Kunden, $1k MRR, $10k MRR). Jedes Tor lässt Sie entweder zur nächsten Stufe vorrücken oder schickt Sie zurück, um etwas in der vorherigen Stufe zu korrigieren. Dieser Artikel durchläuft alle acht Stufen, die Wochenpläne innerhalb der kritischen Phasen, die Anti-Patterns, die mich jeweils ein Quartal gekostet haben, und die Planungs-Artefakte, die den Kontakt mit der Realität überstehen. Für die Laufzeitentscheidungen innerhalb jedes Meilensteins, lesen Sie den SaaS-Architektur-2026-Leitfaden; für die Datenschicht innerhalb der MVP- und Beta-Stufen, lesen Sie den D1-Produktionsleitfaden; für die Auth-Oberfläche während der Private Beta, lesen Sie den SaaS-Authentifizierungsleitfaden.
Warum Meilensteine, nicht Deadlines, ein Solo-SaaS vorantreiben
Der häufigste Planungsfehler, den ich bei anderen Solo-Foundern beobachtet und selbst dreimal begangen habe, ist die Verwechslung eines Meilensteins mit einem Deadline. Ein Deadline ist ein Datum, bis zu dem etwas erledigt sein muss. Ein Meilenstein ist ein evidenzbasierter Schwellenwert, der beweist, dass die vorherige Stufe funktioniert hat. Der Unterschied ist entscheidend, weil Deadlines einen Misserfolg überstehen (Sie verpassen das Datum, die Arbeit bleibt unverändert), Meilensteine jedoch nicht – wenn Sie das Tor nicht passieren, sind Sie nicht vorgerückt, unabhängig davon, wie viele Wochen Sie investiert haben.
Der andere Fehler ist, die Meilenstein-Leiter als Wunschliste statt als Sequenz zu behandeln. Bei zwölf Apps ist die Sequenz jedes Mal dieselbe. Laut Y Combinators Bibliothek zur MVP-Planung ist die kanonische B2B-SaaS-Sequenz ähnlich: Problem, Lösung, MVP, erste Kunden, wiederholbarer Verkauf. Die acht Stufen unten sind die operative Version dieser Sequenz, mit konkreten Entscheidungstoren bei jedem Übergang.
Ein Meilenstein-Framework hat drei Eigenschaften, die ein Deadline-Framework nicht hat. Erstens ist es ehrlich gegenüber Unsicherheit: Sie können nicht im Voraus wissen, wie viele Wochen ein MVP dauern wird, aber Sie können definieren, welche Evidenz das MVP produzieren muss. Zweitens ist es Kill-freundlich: Wenn ein Meilenstein das Tor nicht passiert, hören Sie auf, auf den nächsten zu drängen – Sie gehen zurück und korrigieren die Stufe, die gescheitert ist. Drittens ist es stackübergreifend übertragbar: ob Sie auf Cloudflare Workers, Next.js, Rails oder Django aufbauen – die acht Stufen sind dieselben.
Die Acht-Stufen-Meilenstein-Leiter
Nach zwölf Apps ist das Muster, das am häufigsten überlebt, eine Acht-Stufen-Leiter. Die ersten vier Stufen sind vor dem Launch; die nächsten vier Stufen nach dem Launch. Die Grenze ist beabsichtigt – die erste Hälfte dreht sich darum, das Richtige zu bauen, die zweite Hälfte darum, es zu verkaufen.
Stufe 0 — Pre-Build (Woche 0)
Sie bauen noch nichts. Das Ergebnis ist ein Einseiten-Briefing, das den Rest der Leiter übersteht. Das Entscheidungstor am Ende von Stufe 0 lautet: Sie können das Problem in einem Satz beschreiben, den Käufer in einem Satz, die Kerntransaktion in einem Satz, und Sie haben drei Personen benannt, die dieses Problem spüren. Wenn eine dieser vier Voraussetzungen fehlt, sind Sie nicht bereit für Stufe 1. Das NSF I-Corps Customer Discovery Framework ist die formale Version dieses Tors; die informelle Version lautet: „Haben Sie mit jemandem gesprochen, der bezahlen würde?"
Stufe 1 — Ideenvalidierung (Wochen 1–3)
Sie validieren das Problem, bevor Sie die Lösung validieren. Die Arbeit: zehn Kundeninterviews, eine Landingpage mit Warteliste, ein manueller Concierge-Test, bei dem Sie die Arbeit von Hand für eine oder zwei Personen erledigen. Das Entscheidungstor ist der Pay-the-Bill-Test: Mindestens eine Person hat Ihnen eine Kreditkarte, einen Scheck oder eine Überweisung für etwas übergeben, das dasselbe Problem adressiert. Eine Wartelisten-Anmeldung zählt nicht. Eine E-Mail-Antwort zählt nicht. Das erste Mal, als ich dieses Tor passiert habe, war eine Überweisung über $200 von einem Gründer, der wegen eines manuellen Prozesses nicht schlafen konnte; das zweite Mal war eine Stripe-Vorbestellung für eine $99-Lebenszeitlizenz. Das Tor ist dasselbe.
Stufe 2 — MVP (Wochen 4–10)
Sie bauen das Kleinste, das Stufe 1s Tor wiederholt passieren kann. Die Arbeit: eine Kerntransaktion Ende-zu-Ende, ein Zahlungsfluss, ein Authentifizierungsfluss, eine Deployment-Pipeline. Das Entscheidungstor am Ende von Stufe 2 sind drei zahlende Kunden – nicht drei Anmeldungen, drei Personen, die tatsächlich bezahlt haben. Drei ist die kleinste Stichprobe, die Ihnen sagt, ob das Problem-Lösungs-Fit real ist oder ob Ihr erster Kunde ein Ausreißer war.
Stufe 3 — Private Beta (Wochen 11–16)
Sie erweitern den Trichter und begrenzen gleichzeitig die Oberfläche. Die Arbeit: zehn bis fünfundzwanzig zahlende Nutzer, Supportvolumen, das eine Person bewältigen kann, die drei meistgenannten Bugs behoben, Monitoring eingerichtet. Das Entscheidungstor ist Retentionsmessung nach vier Wochen – mindestens 60 % der Nutzer aus Woche 1 sind in Woche 5 noch aktiv. Unter 60 % haben Sie ein undichtes Fass; über 60 % haben Sie etwas, das einen Launch wert ist. Die SaaS-Architektur auf dieser Stufe ist typischerweise ein einzelner Cloudflare Worker für die API, ein verwaltetes Postgres oder D1 für die Daten, ein einzelner Stripe-Webhook für die Abrechnung – lesen Sie den D1-Produktionsleitfaden für die Datenschicht und den SaaS-API-Leitfaden für die API-Form.
Stufe 4 — Public Launch (Wochen 17–22)
Sie wechseln von einem privaten Publikum zu öffentlichem Traffic. Die Arbeit: Launch-Checkliste vollständig, Support-Posteingang routingfähig, Error Budgets definiert, Preisseite öffentlich, Stripe Launch Checklist abgehakt, drei Akquisekanäle vorbereitet. Das Entscheidungstor ist ein Public Launch, der in der ersten Woche fünf neue Anmeldungen von Cold Traffic generiert – nicht von Ihrer privaten Liste. Die Zahl fünf ist klein genug, dass sie fast jedes Produkt schaffen kann, und groß genug, um zu beweisen, dass jemand außerhalb Ihres warmen Netzwerks das Produkt findet. Für den Launch-Spielzug, lesen Sie das Product Hunt Launch Playbook.
Stufe 5 — Erste $1k MRR (Monate 6–9)
Sie sind nach dem Launch mit einer kleinen, aber echten Kundenbasis. Die Arbeit: Onboarding optimieren, zweiten und dritten Akquisekanal aufbauen, Churn reduzieren, Revenue instrumentieren. Das Entscheidungstor ist $1.000 monatlich wiederkehrender Umsatz – keine Einmalzahlung, wiederkehrend. Die Stripe Subscriptions API ist die kanonische Implementierung; der Schwellenwert ist hoch genug, um zu beweisen, dass das Produkt eine Retentionskurve hat, und niedrig genug, um innerhalb von drei Monaten nach dem Public Launch erreichbar zu sein. Acht von zwölf Apps haben $1k MRR erreicht; die vier, die es nicht geschafft haben, wurden entweder eingestellt oder sind zurück zu Stufe 1 gegangen.
Stufe 6 — Erste $10k MRR (Monate 9–18)
Sie haben Product-Market Fit im lockeren Sinne. Die Arbeit: Preisexperimente, die erste Einstellung (oft ein Teilzeit-Contractor für Support), formalisiertes Onboarding, der erste bezahlte Akquisekanal. Das Entscheidungstor ist $10.000 monatlich wiederkehrender Umsatz – ungefähr der Schwellenwert, bei dem das SaaS einen Vollzeit-Ingenieur in einer Gegend mit niedrigen Lebenshaltungskosten bezahlen oder ein bedeutendes Contractor-Budget finanzieren kann. Das Harte ist nicht das Produkt – es ist der Vertriebsansatz. Apps, die diese Stufe geschafft haben, hatten entweder einen Self-Serve-Funnel, der Cold Traffic konvertiert (drei davon), oder einen foundergeführten Vertriebsansatz mit einem Zyklus unter 30 Tagen (zwei davon). Die verbleibenden drei haben es nicht geschafft und blieben in Stufe 5.
Stufe 7 — Nachhaltiger Betrieb (Monate 18+)
Sie haben ein operativ stabiles Unternehmen. Die Arbeit: dokumentiertes Onboarding, überwachte Error Budgets, ein kleines, aber vollständiges Team (1 Gründer + 1–3 Contractor), ein Portfolio von Akquisekanälen und sich verstärkendes Word-of-Mouth. Das Entscheidungstor ist $10k MRR stabil über sechs aufeinanderfolgende Monate mit einem monatlichen Churn unter 5 %. Das SaaS ist kein Experiment mehr; es ist ein kleines Unternehmen. Vier von zwölf Apps haben diese Stufe erreicht; die anderen sind entweder ins Stocken geraten oder eingestellt worden.
Eine einzelne Meilenstein planen: die Wochen-für-Woche-Vorlage
Ein Meilenstein ist keine Woche; er ist eine Stufe, die eine variable Anzahl von Wochen dauert. Innerhalb einer Stufe planen Sie wochenweise. Die Vorlage, die ich für jede Stufe ab Stufe 2 verwende, hat dieselbe Form – es ist das Planungs-Artefakt, das die meisten Überarbeitungen überlebt hat.
milestone: mvp
stage: 2
expected_weeks: 7 # Schätzung, wöchentlich überarbeitet
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
Die Form ist festgelegt; der Inhalt ändert sich. Drei Regeln bestimmen den Inhalt. Erstens hat jede Woche einen Fokus, nicht drei – wenn Sie eine Woche auf zwei Fokusse aufteilen, ist das dasselbe, wie den Fokus zu verfehlen. Zweitens ist das Deliverable jeder Woche von einem externen Nutzer beobachtbar – „Code gemergt" ist kein Deliverable; „Stripe Checkout live" ist es. Drittens ist das Time-Box die Zeit, die Sie tatsächlich arbeiten, nicht die Kalenderzeit; Wochen fünf und sechs können je sieben Kalendertage dauern, aber nur achtzehn und zweiundzwanzig Stunden fokussierter Arbeit erfordern.
Die Gate-Review am Ende jeder Stufe ist nicht verhandelbar. Wenn Sie das Tor nicht passiert haben, rücken Sie nicht vor. Der teuerste Fehler, den ich begangen habe, war das Vorrrücken zu Stufe 4 mit nur zwei zahlenden Kunden, weil mir „das Runway ausging"; der Launch flopte, die beiden Kunden gingen verloren, und ich brauchte sechs Wochen, um mich zu erholen. Das Tor existiert, weil es der günstigste Ort ist, an dem man scheitern kann.
Entscheidungstore: wann vorrücken, halten oder beenden
Die Entscheidungstore sind das tragende Gerüst der Leiter. Jedes Tor hat einen einzelnen numerischen Schwellenwert, und jedes Tor hat drei Ergebnisse: Vorrücken, Halten oder Beenden.
Vorrücken ist der offensichtliche Fall: der Schwellenwert ist erreicht, Sie gehen mit den vorhandenen Ressourcen zur nächsten Stufe über. Halten ist der Fall, in dem der Schwellenwert plausibel, aber noch nicht erreicht ist: Weiter investieren, in zwei Wochen erneut prüfen, keine neue Oberfläche hinzufügen. Beenden ist der Fall, in dem der Schwellenwert angesichts Ihrer Evidenz unrealistisch ist: Stopp, Rückkehr zur vorherigen Stufe, Korrektur des Gescheiterten, und Überlegung, ob es überhaupt weitergehen soll.
Das härteste Tor der Leiter ist Stufe 5s $1k-MRR-Schwellenwert. Acht von zwölf Apps haben ihn passiert. Die vier, die es nicht geschafft haben, teilten eine einzige Eigenschaft: ein einzelner Akquisekanal, der foundergetrieben war (Cold E-Mail, Founder-Netzwerk, Twitter), und kein organischer oder bezahlter Kanal. Die acht, die ihn geschafft haben, hatten das Gegenteil – mindestens zwei Akquisekanäle, einer davon organisch oder bezahlt. Ein einzelner foundergetriebener Akquisekanal skaliert nicht auf $1k MRR, Punkt.
Das zweithärteste Tor ist Stufe 1s Pay-the-Bill-Test. Vier von sechzehn Versuchen sind gescheitert. Die Misserfolge sahen alle gleich aus: ein einzelnes Gespräch, das der Gründer als Validierung interpretierte. Die Erfolge hatten mindestens drei unabhängige Signale – eine Überweisung, eine Vorbestellung, eine Kreditkarte auf einem Checkout-Link, oder ein von einem Beschaffungsteam unterzeichnetes LOI.
Anti-Patterns: Meilensteine, die ein Quartal verschwenden
Drei Anti-Patterns haben mich bei zwölf Apps jeweils ein Quartal gekostet. Sie sind leicht zu wiederholen und es lohnt sich, sie zu benennen.
Der erste ist das Überplanen der Pre-Build-Stufe. Zwei meiner Apps verbrachten acht Wochen mit Marktforschung, Wettbewerbsanalyse und Preisstrategie, bevor sie eine Zeile Code schrieben. Beide brauchten länger, um Stufe 1 zu passieren, als Apps, bei denen ich in Woche eins ein Einseiten-Briefing rausgehauen habe. Die Verzerrung zur Behebung ist die Annahme, dass mehr Recherche das Risiko reduziert; empirisch testen Kundeninterviews und ein Landingpage-Test die Hypothese schneller als ein 30-seitiges Dokument.
Der zweite ist drei Features im MVP zu bauen. Jedes MVP, das ich mit drei Features ausgeliefert habe, dauerte 12–14 Wochen; jedes MVP mit einem Feature dauerte 6–8 Wochen. Die Falle ist die Annahme, dass der Käufer ein vollständiges Produkt will; empirisch will der Käufer, dass die Kerntransaktion funktioniert. Die Lean-Startup-Methodik ist die formale Version dieser Lektion, aber die Zahl – drei Features in 12 Wochen versus ein Feature in 6 Wochen – hat mein Verhalten verändert.
Der dritte ist vorzeitiges Skalieren. Zwei meiner Apps gingen direkt von Stufe 3 (Private Beta) zu Stufe 6 ($10k MRR anpeilen) über, ohne Stufe 5 zu passieren. Beide stockten, weil der Vertriebsansatz nicht wiederholbar war; der Gründer war der Vertriebsansatz, und ein Gründer kann nur eine bestimmte Anzahl Deals pro Woche abschließen. Die Erholung bestand darin, auf Stufe 5 zurückzufallen, einen Self-Serve- oder kurzzyklischen Vertriebsansatz aufzubauen und das Tor auf dem niedrigeren Schwellenwert erneut zu passieren, bevor man den höheren anpeilt.
Planungs-Artefakte, die den Kontakt mit der Realität überstehen
Drei Artefakte lohnen sich zu standardisieren. Das erste ist die Milestone Card – ein Einseiten-Dokument pro Stufe, mit dem Ziel, dem Entscheidungstor, den Wochen-Deliverables und den Kill-Kriterien. Das zweite ist der Wochenplan – eine YAML- oder JSON-Datei mit den sieben Tagen der Woche, dem Fokus jedes Tages, der Time-Box und dem Risiko. Das dritte ist die Gate Review – ein einzelnes Dokument am Ende jeder Stufe, das die Evidenz aufzeichnet: die drei zahlenden Kunden, die Retentionskurve, den $1k-MRR-Screenshot. Diese drei Artefakte befinden sich im 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"
}
Die Artefakte sind keine Bürokratie. Sie sind der einzige Mechanismus, den ein Solo-Founder hat, um zu erkennen, wann eine Stufe leise gescheitert ist. Ohne das Gate-Review-Dokument zeigt sich das Scheitern drei Monate später als Churn; mit dem Dokument zeigt es sich am Tag nach dem Tor-Scheitern, wenn noch Zeit ist, sich zu erholen.
Abschließende CTA
Die Acht-Stufen-Leiter ist das Planungs-Framework, das ich bei zwölf Apps verwendet habe. Es ist nicht das einzige, das funktioniert; es ist das, das den Kontakt mit der Realität am häufigsten überlebt hat. Wenn Sie ein SaaS starten, ist das Günstigste, was Sie heute tun können, das Stufe-0-Briefing zu schreiben – einen Satz pro Frage – und zu prüfen, ob Sie drei Personen haben, die dieses Problem spüren. Wenn nicht, sparen Sie die Acht-Wochen-Investition und bleiben Sie in Stufe 0, bis Sie es haben.
Für die Laufzeitentscheidungen innerhalb der Build-Stufen lesen Sie den SaaS-Architektur-2026-Leitfaden; für die Datenschicht innerhalb von MVP und Beta lesen Sie den D1-Produktionsleitfaden; für die Auth-Oberfläche während der Private Beta lesen Sie den SaaS-Authentifizierungsleitfaden. Das TanStack Ship Planning Templates Repo enthält die Milestone-Card-, Wochenplan- und Gate-Review-Vorlagen als Ausgangspunkt. Die TanStack Ship Features-Seite enthält die Laufzeitprimitiven; die Preisseite enthält das Packaging-Modell, das Stufe 5 und darüber voraussetzt.