Geschrieben von Huifer
TL;DR: Ein SaaS-MVP in 4 Wochen zu bauen ist nicht nur möglich – es ist der neue Standard. Mit modernen Tools wie TanStack Start, Drizzle ORM und Stripe kann eine einzelne Entwicklerin schneller von der Idee zu zahlenden Kund:innen kommen als je zuvor. Dieser Guide bietet einen Wochen-für-Wochen-Fahrplan, ein Framework zur Feature-Priorisierung und praktische Code-Beispiele, damit Sie ohne Burnout liefern.
Einleitung: Warum 4 Wochen?
Das alte Playbook sagte: Sie brauchen eine Mitgründerin, eine Finanzierungsrunde und sechs Monate stiller Entwicklung, bevor Sie irgendetwas der Welt zeigen. Dieses Playbook ist überholt.
Modernes SaaS-Tooling hat die Lücke zwischen Idee und ausgeliefertem Produkt dramatisch verkleinert. Server-gerenderte React-Frameworks eliminieren die Frontend-Backend-Trennung. Verwaltete Datenbanken und serverlose Deployments nehmen den Infrastruktur-Aufwand heraus. Zahlungsplattformen wie Stripe kümmern sich um die compliance-lastigen Teile des Geldverkehrs.
Der eigentliche Flaschenhals für Solo-Founder:innen ist nicht mehr die Technologie – es ist Scope-Management. Der Unterschied zwischen einem 4-Wochen-MVP und einem 4-Monats-Prototyp liegt in der Fähigkeit, „Nein" zu sagen zu Features, die nicht direkt Ihre Kernhypothese validieren.
Klären wir, was ein MVP ist: Das Kleinste, das Sie bauen können, wofür jemand bezahlt. Es ist keine Demo. Es ist kein Prototyp. Es ist ein Produkt, das genug Wert liefert, dass eine fremde Person ihre Kreditkartennummer herausrückt.
Woche 0: Vorbereitung (Tage 1–3)
Bevor Sie eine einzige Zeile Code schreiben, brauchen Sie Klarheit über drei Dinge: Ideenvalidierung, Tech-Stack und Scope.
Ideenvalidierung
Nehmen Sie sich einen Tag, um diese Fragen zu beantworten:
- Ist das ein Schmerzstiller oder ein Vitamin? Schmerzstiller lösen dringende Probleme, für die Menschen aktiv nach Lösungen suchen. Schmerzstiller gewinnen immer.
- Wer genau sind Ihre ersten 10 Kund:innen? Wenn Sie nicht 10 Personen in Ihrer Zielgruppe benennen können, die dieses Problem spüren, sind Sie noch nicht bereit zu bauen.
- Was ist die einzelne Kerntransaktion? Die eine Aktion, die eine Nutzerin ausführt und die Ihren Kernnutzen liefert.
Tech-Stack-Entscheidung
Ihr Tech-Stack für einen 4-Wochen-Sprint braucht drei Eigenschaften: Vertrautheit, Batterien inklusive und geringen Ops-Overhead.
Hier ist ein bewährter Stack für Solo-Founder:innen:
| Schicht | Empfohlene Wahl | Warum |
|---|---|---|
| Framework | TanStack Start (React) | Full-Stack React mit SSR, dateibasierter Routing, Server Functions |
| Datenbank | SQLite via Drizzle ORM (dev), PostgreSQL (prod) | Typsichere Abfragen, einfache Migrationen |
| Auth | Better Auth | Vorgefertigte Auth-UI, Session-Management, Social Login |
| Payments | Stripe + Webhooks | Industriestandard, gut dokumentiert |
| Deployment | Cloudflare Workers | Globales Edge-Deployment, kostenloser Plan |
| Resend | Einfache API, gute Zustellbarkeit |
Der zentrale Insight: Halten Sie Ihren Stack flach. Jeder zusätzliche Service erhöht die kognitive Last. Wenn Sie Ihre gesamte Anwendung in einer Codebasis mit einem Framework halten können, tun Sie es.
Scope-Definition
Der 4-Wochen-Scope-Filter: Für jedes potenzielle Feature fragen Sie: „Würde die Nutzerin trotzdem bezahlen, wenn dieses Feature fehlt?" Wenn ja – streichen Sie es.
Ihr Woche-0-Liefergegenstand sollte ein einziger Satz sein:
„[Zielgruppe] kann [Kernaktion] ausführen, um [Kernnutzen] zu erzielen, und dafür mit Kreditkarte bezahlen."
Beispiel: „Freelance-Entwickler:innen können professionelle Rechnungen aus ihren Zeiterfassungsdaten generieren, damit sie schneller bezahlt werden, und zahlen 19 $/Monat für unbegrenzte Rechnungen."
Woche 1: Fundament (Tage 4–10)
Woche 1 dient dem Aufbau des Rückgrats Ihres Projekts. Am Ende dieser Woche sollten Sie eine deployte Anwendung mit Authentifizierung und Datenbank haben.
Tag 4–5: Project Scaffolding
Beginnen Sie damit, ein neues TanStack Start-Projekt zu erstellen und die wichtigsten Abhängigkeiten zu installieren:
# Neues TanStack Start-Projekt erstellen
npm create tanstack-app@latest my-saas
cd my-saas
npm install drizzle-orm @libsql/client
npm install -D drizzle-kit
npm install better-auth
Erstellen Sie Ihre Schema-Datei mit dem Wesentlichen – Users, Teams und Ihr Kern-Domain-Modell:
// src/db/schema.ts
import { sqliteTable, text, integer } from "drizzle-orm/sqlite-core";
export const users = sqliteTable("users", {
id: text("id").primaryKey(),
email: text("email").notNull().unique(),
name: text("name"),
createdAt: integer("created_at", { mode: "timestamp" }).notNull().defaultNow(),
});
Dieses Schema definiert das minimale User-Modell für den Einstieg – nur id, E-Mail, Name und Erstellungszeitstempel. Sie erweitern es, sobald Sie Features wie Teams oder Subscriptions hinzufügen.
Tag 6–7: Authentifizierung integrieren
Richten Sie Better Auth mit E-Mail/Passwort und mindestens einem Social-Login (Google oder GitHub) ein. Ihr Ziel ist ein funktionierender Signup → Login → geschützter Route-Flow.
Tag 8–9: Deployment-Pipeline
Bringen Sie Ihre App so schnell wie möglich in die Produktion. Ein deploytes „Hello World" ist mehr wert als ein lokales Meisterwerk:
npm run deploy
Tag 10: Fundament-Review
Verifizieren Sie, dass neue Nutzer:innen sich registrieren, einloggen und ein leeres Dashboard sehen können. Fügen Sie keine Features hinzu. Das Fundament muss solide stehen.
Woche 2: Kern-Features (Tage 11–17)
Woche 2 ist da, wo Sie die 20 % der Features bauen, die 80 % des Werts liefern.
Die Kern-Interaktion bauen
Mit TanStack Starts Server Functions können Sie Ihr Kern-Feature als eine einzige kohärente Einheit bauen. Hier ist ein Task-Erstellungs-Endpoint, der Input validiert und in der Datenbank speichert:
// Server Function – läuft auf dem Server, wird vom Client aufgerufen
const createTask = createServerFn({ method: 'POST' })
.validator(z.object({ projectId: z.string(), title: z.string() }))
.handler(async ({ data }) => {
const user = await requireAuth()
const task = await db.insert(tasks).values({
projectId: data.projectId,
title: data.title,
createdBy: user.id,
status: "todo",
}).returning()
return task
})
Das Server-Function-Pattern hält Ihre Business-Logik auf dem Server und bietet typsichere Client-Aufrufe. Der Validator stellt sicher, dass nur gültige Daten Ihre Datenbank erreichen.
Was Sie in Woche 2 überspringen sollten
- Team-Kollaboration – vorerst nur Einzelpersonen. Teams können später hinzugefügt werden.
- Benachrichtigungen – Nutzer:innen kommen zurück, wenn sie es brauchen.
- Datei-Uploads – sie fügen überraschend viel Komplexität hinzu.
- Dark Mode – Ihr CSS-Bundle wird es Ihnen danken.
- Onboarding-Assistent – eine einfache Willkommensnachricht genügt.
Woche 3: Payments & Polish (Tage 18–24)
Stripe-Integration
Sie brauchen ein Products/Prices-Setup im Stripe Dashboard, einen Endpoint zur Checkout-Session-Erstellung, einen Webhook-Handler und ein Customer Portal. Hier ist die Checkout-Session-Erstellung mit einer TanStack Start Server Function:
export const createCheckoutSession = createServerFn({ method: 'POST' })
.validator(z.string())
.handler(async ({ data: priceId }) => {
const user = await requireAuth()
const session = await stripe.checkout.sessions.create({
customer_email: user.email,
mode: "subscription",
line_items: [{ price: priceId, quantity: 1 }],
success_url: `${process.env.APP_URL}/dashboard`,
cancel_url: `${process.env.APP_URL}/pricing`,
})
return { url: session.url }
})
Pro-Tipp: Nutzen Sie Stripes Customer Portal für Subscription-Verwaltung, statt ein eigenes zu bauen. Es behandelt Edge Cases besser, als Sie es in 4 Wochen schaffen.
E-Mail & Error Handling
Richten Sie Transaktions-E-Mails für Willkommen, Zahlungsbestätigung und fehlgeschlagene Zahlung ein. Erstellen Sie eine globale Error Boundary, damit Nutzer:innen niemals einen rohen Stack Trace sehen.
Woche 4: Launch-Vorbereitung (Tage 25–30)
Woche 4 dreht sich um Reibungsverlust-Reduzierung zwischen einer fremden Person und ihrer Kreditkarte.
Framework zur Feature-Priorisierung
| Frage | Wenn JA | Wenn NEIN |
|---|---|---|
| Ermöglicht das die Kerntransaktion? | Jetzt bauen | Überspringen |
| Kann die Nutzerin ihr Ziel ohne das erreichen? | Überspringen | Jetzt bauen |
| Reduziert das die Churn? | Bauen | Überspringen |
| Kann das durch einen manuellen Prozess ersetzt werden? | Manuell machen | Überspringen |
Pre-Launch-Checkliste
- Signup → bezahlter Flow funktioniert Ende-zu-Ende
- Stripe-Webhooks verarbeiten Subscription-Events
- E-Mails bei fehlgeschlagener Zahlung werden versendet
- Rechtliche Seiten (Datenschutzerklärung, AGB) sind veröffentlicht
- robots.txt und sitemap.xml sind konfiguriert
- Eigene Domain ist mit SSL eingerichtet
- Datenbank-Backups sind konfiguriert
- Error-Monitoring ist aktiv
- Mindestens ein Social-Login funktioniert
- Sie können Nutzerdaten auf Anfrage löschen (GDPR- readiness)
Fazit: Launchen und Iterieren
Die erfolgreichsten SaaS-Produkte waren bei Launch nicht perfekt. Sie waren tragfähig. Stripe startete mit einem einzigen API-Endpoint. Basecamp startete als einfaches Projektmanagement-Tool.
Die Aufgabe Ihres MVPs ist es, ein Gespräch mit dem Markt zu beginnen. Sie werden in der ersten Woche nach dem Launch mehr lernen als in den vier Wochen des Bauens.
Done is better than perfect. Launched is better than done.
Bis zum Ende von Woche 4 sollten Sie haben:
- Ein deploytes Produkt, das Zahlungen akzeptiert
- 10–50 Nutzer:innen (einige organisch, die meisten durch persönliche Ansprache)
- Eine Liste der 3 meistgefragten Features
- 0–500 $ monatlich wiederkehrenden Umsatz
Diese letzte Zahl wirkt vielleicht unspektakulär, aber sie ist alles. Es ist der Beweis, dass jemand den Wert dessen, was Sie gebaut haben, so sehr schätzt, dass er dafür bezahlt. Von dort aus iterieren Sie, wachsen und profitieren.
Sobald Ihr MVP live ist, verfeinern Sie Ihre Preisgestaltung mit dem SaaS Pricing Strategy Playbook. Wenn Sie wachsen, hilft Ihnen der Guide Designing SaaS Database Architecture beim Skalieren Ihrer Datenebene. Für eine vollständige Durch walkthrough des Bauens mit TanStack Start lesen Sie das End-to-End Tutorial.