SaaS MVP bauen lassen: Von der Idee zum Launch in 8 Wochen

Warum 80% der MVPs scheitern — und was die anderen 20% anders machen

Die meisten MVPs scheitern nicht an der Technik. Sie scheitern, weil zu viel gebaut wird. Nach 40+ SaaS-Produkten, die wir bei SecretStack shipped haben, sehen wir immer dasselbe Muster: Gründer kommen mit einer Feature-Liste von 30 Punkten. Davon sind 4 relevant. Der Rest ist Scope Creep, verkleidet als "muss unbedingt rein".

Ein MVP ist kein kleines Produkt — es ist das kleinste Experiment, das eine Hypothese validiert. Wenn du nach 8 Wochen nicht live bist, hast du kein MVP gebaut, sondern ein Feature-Monster, das nie launcht.

In diesem Artikel zeigen wir dir den exakten Prozess, den wir für jeden SaaS-MVP verwenden — inklusive echtem Code, realer Kostenaufstellung und dem Sprint-Plan, der seit 40+ Projekten funktioniert.

Der Tech-Stack: Warum wir auf Next.js + Prisma + Stripe setzen

Bevor wir in den Fahrplan einsteigen: Die Tech-Stack-Entscheidung ist eine der ersten und wichtigsten. Wir haben über die Jahre verschiedene Kombinationen in Produktion betrieben und uns bewusst für einen Stack entschieden, der für 90% aller SaaS-MVPs optimal funktioniert.

| Kriterium | Next.js + Prisma + Stripe | Rails + ActiveRecord + Stripe | Laravel + Eloquent + Stripe | Supabase + Edge Functions | |---|---|---|---|---| | Time-to-MVP | 6-8 Wochen | 6-8 Wochen | 8-10 Wochen | 4-6 Wochen | | TypeScript End-to-End | Ja (native) | Nein (Ruby) | Nein (PHP) | Teilweise | | SSR + API in einem Repo | Ja (App Router) | Nein (separate SPA nötig) | Nein (Blade oder separate SPA) | Nein | | Edge Deployment | Vercel/Cloudflare | Heroku/Render | Forge/Vapor | Supabase Cloud | | Hiring-Pool (DE) | Sehr groß | Schrumpfend | Groß | Klein | | KI-Integration | Exzellent (Vercel AI SDK) | Okay | Schwach | Okay | | Skalierbarkeit | Horizontal einfach | Vertikal gut | Vertikal gut | Plattform-abhängig | | Vendor Lock-in | Gering | Gering | Gering | Hoch |

Unser Fazit: Next.js mit App Router gibt dir SSR, API Routes und React in einem Monorepo. Prisma liefert Type-Safety vom Datenbankschema bis zum Frontend. Stripe ist der Industriestandard für Billing. Diese Kombination minimiert Kontext-Switching und maximiert Entwicklungsgeschwindigkeit — genau das, was du bei einem MVP brauchst.

Supabase ist schneller für Prototypen, aber du baust dir Vendor Lock-in ein, den du bei der Skalierung bereuen wirst. Rails und Laravel sind solide, aber du brauchst ein separates Frontend — und damit doppelte Deployment-Komplexität.

Projekt-Struktur: So sieht ein Production-SaaS aus

Bevor du anfängst zu coden, brauchst du eine saubere Architektur. Hier ist die Ordnerstruktur, die wir für jeden SaaS-MVP verwenden:

my-saas/
├── prisma/
│   ├── schema.prisma          # Datenmodell
│   ├── migrations/            # Versionierte DB-Migrationen
│   └── seed.ts                # Testdaten für Development
├── src/
│   ├── app/
│   │   ├── (auth)/
│   │   │   ├── login/page.tsx
│   │   │   ├── register/page.tsx
│   │   │   └── layout.tsx     # Auth-Layout ohne Sidebar
│   │   ├── (dashboard)/
│   │   │   ├── layout.tsx     # Dashboard-Layout mit Sidebar + Header
│   │   │   ├── page.tsx       # Dashboard Home
│   │   │   ├── settings/
│   │   │   │   ├── page.tsx
│   │   │   │   └── billing/page.tsx
│   │   │   └── [orgSlug]/
│   │   │       ├── page.tsx   # Org-Dashboard
│   │   │       └── projects/
│   │   │           ├── page.tsx
│   │   │           └── [projectId]/page.tsx
│   │   ├── api/
│   │   │   ├── webhooks/
│   │   │   │   └── stripe/route.ts
│   │   │   └── trpc/[trpc]/route.ts
│   │   ├── layout.tsx         # Root-Layout
│   │   └── page.tsx           # Landing Page
│   ├── components/
│   │   ├── ui/                # shadcn/ui Komponenten
│   │   ├── forms/             # Formulare mit react-hook-form + zod
│   │   └── layouts/           # Sidebar, Header, etc.
│   ├── lib/
│   │   ├── auth.ts            # Auth-Konfiguration
│   │   ├── db.ts              # Prisma Client Singleton
│   │   ├── stripe.ts          # Stripe Client + Helpers
│   │   └── utils.ts
│   ├── server/
│   │   ├── routers/           # tRPC Router
│   │   └── actions/           # Server Actions
│   └── middleware.ts          # Route Protection
├── .env.local
├── docker-compose.yml         # PostgreSQL + Redis für Local Dev
├── tailwind.config.ts
└── package.json

Zwei Dinge fallen auf: Route Groups (auth) und (dashboard) trennen Layouts sauber. Und die api/webhooks/ Route liegt bewusst außerhalb von tRPC — Webhooks brauchen Raw Body Access, das verträgt sich nicht mit tRPC-Middleware.

Das Datenmodell: Prisma Schema für Multi-Tenant SaaS

Das Datenmodell ist das Fundament. Hier ist ein Schema, das wir in ähnlicher Form in dutzenden Projekten verwenden — Multi-Tenant mit Organization-based Access Control:

// prisma/schema.prisma
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id            String    @id @default(cuid())
  email         String    @unique
  name          String?
  avatarUrl     String?
  emailVerified DateTime?
  createdAt     DateTime  @default(now())
  updatedAt     DateTime  @updatedAt

  memberships   Membership[]
  accounts      Account[]    // OAuth Providers

  @@map("users")
}

model Account {
  id                String  @id @default(cuid())
  userId            String
  type              String
  provider          String
  providerAccountId String
  refresh_token     String?
  access_token      String?
  expires_at        Int?

  user User @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@unique([provider, providerAccountId])
  @@map("accounts")
}

model Organization {
  id               String   @id @default(cuid())
  name             String
  slug             String   @unique
  stripeCustomerId String?  @unique
  createdAt        DateTime @default(now())
  updatedAt        DateTime @updatedAt

  memberships  Membership[]
  subscription Subscription?
  projects     Project[]

  @@map("organizations")
}

model Membership {
  id        String         @id @default(cuid())
  role      MembershipRole @default(MEMBER)
  createdAt DateTime       @default(now())

  userId String
  orgId  String

  user         User         @relation(fields: [userId], references: [id], onDelete: Cascade)
  organization Organization @relation(fields: [orgId], references: [id], onDelete: Cascade)

  @@unique([userId, orgId])
  @@map("memberships")
}

enum MembershipRole {
  OWNER
  ADMIN
  MEMBER
}

model Subscription {
  id                   String             @id @default(cuid())
  orgId                String             @unique
  stripeSubscriptionId String             @unique
  stripePriceId        String
  status               SubscriptionStatus
  currentPeriodStart   DateTime
  currentPeriodEnd     DateTime
  cancelAtPeriodEnd    Boolean            @default(false)
  createdAt            DateTime           @default(now())
  updatedAt            DateTime           @updatedAt

  organization Organization @relation(fields: [orgId], references: [id], onDelete: Cascade)

  @@map("subscriptions")
}

enum SubscriptionStatus {
  ACTIVE
  PAST_DUE
  CANCELED
  UNPAID
  TRIALING
}

model Project {
  id        String   @id @default(cuid())
  name      String
  orgId     String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  organization Organization @relation(fields: [orgId], references: [id], onDelete: Cascade)

  @@map("projects")
}

Wichtig: Die Organization ist der Tenant. Alles hängt an der Organization, nicht am User. User sind über Membership mit Rollen an Organizations gebunden. Das ermöglicht Multi-Org-Support von Tag 1 — ein Pattern, das du später nicht mehr nachrüsten kannst, ohne alles umzubauen.

Auth + Route Protection mit Middleware

Authentifizierung ist bei jedem SaaS der erste kritische Pfad. Wir setzen auf NextAuth.js (Auth.js) mit einer Middleware, die geschützte Routen absichert:

// src/middleware.ts
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";
import { getToken } from "next-auth/jwt";

const publicPaths = ["/", "/login", "/register", "/api/webhooks"];

export async function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;

  // Public paths und statische Assets durchlassen
  const isPublicPath = publicPaths.some(
    (path) => pathname === path || pathname.startsWith(path + "/")
  );
  const isStaticAsset = pathname.startsWith("/_next") || pathname.includes(".");

  if (isPublicPath || isStaticAsset) {
    return NextResponse.next();
  }

  // JWT Token prüfen
  const token = await getToken({
    req: request,
    secret: process.env.NEXTAUTH_SECRET,
  });

  if (!token) {
    const loginUrl = new URL("/login", request.url);
    loginUrl.searchParams.set("callbackUrl", pathname);
    return NextResponse.redirect(loginUrl);
  }

  return NextResponse.next();
}

export const config = {
  matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"],
};

Kein Hokuspokus — die Middleware prüft auf JWT, leitet unauthentifizierte User zum Login und merkt sich die ursprüngliche URL als Callback. Die Webhook-Route ist explizit public, weil Stripe sonst nicht an dich zugestellte Events verliert.

Stripe Integration: Checkout + Webhooks

Die Billing-Integration ist der Part, bei dem die meisten Entwickler ins Schwitzen kommen. Hier ist die Checkout-Session-Erstellung als Server Action:

// src/server/actions/billing.ts
"use server";

import { redirect } from "next/navigation";
import { stripe } from "@/lib/stripe";
import { db } from "@/lib/db";
import { getCurrentUser } from "@/lib/auth";

export async function createCheckoutSession(orgId: string, priceId: string) {
  const user = await getCurrentUser();
  if (!user) throw new Error("Unauthorized");

  const org = await db.organization.findUniqueOrThrow({
    where: { id: orgId },
    include: { memberships: { where: { userId: user.id } } },
  });

  if (org.memberships.length === 0) {
    throw new Error("Not a member of this organization");
  }

  // Stripe Customer anlegen oder vorhandenen verwenden
  let stripeCustomerId = org.stripeCustomerId;

  if (!stripeCustomerId) {
    const customer = await stripe.customers.create({
      name: org.name,
      email: user.email,
      metadata: { orgId: org.id },
    });
    stripeCustomerId = customer.id;

    await db.organization.update({
      where: { id: org.id },
      data: { stripeCustomerId },
    });
  }

  const session = await stripe.checkout.sessions.create({
    customer: stripeCustomerId,
    mode: "subscription",
    line_items: [{ price: priceId, quantity: 1 }],
    success_url: `${process.env.NEXT_PUBLIC_APP_URL}/${org.slug}/settings/billing?success=true`,
    cancel_url: `${process.env.NEXT_PUBLIC_APP_URL}/${org.slug}/settings/billing?canceled=true`,
    metadata: { orgId: org.id },
    subscription_data: {
      metadata: { orgId: org.id },
    },
  });

  if (!session.url) throw new Error("Failed to create checkout session");
  redirect(session.url);
}

Und der Webhook-Handler, der Subscription-Events verarbeitet:

// src/app/api/webhooks/stripe/route.ts
import { headers } from "next/headers";
import { NextResponse } from "next/server";
import { stripe } from "@/lib/stripe";
import { db } from "@/lib/db";
import type Stripe from "stripe";

export async function POST(request: Request) {
  const body = await request.text();
  const headersList = await headers();
  const signature = headersList.get("stripe-signature");

  if (!signature) {
    return NextResponse.json({ error: "Missing signature" }, { status: 400 });
  }

  let event: Stripe.Event;

  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );
  } catch (err) {
    console.error("Webhook signature verification failed:", err);
    return NextResponse.json({ error: "Invalid signature" }, { status: 400 });
  }

  switch (event.type) {
    case "checkout.session.completed": {
      const session = event.data.object as Stripe.Checkout.Session;
      const orgId = session.metadata?.orgId;
      if (!orgId || !session.subscription) break;

      const subscription = await stripe.subscriptions.retrieve(
        session.subscription as string
      );

      await db.subscription.upsert({
        where: { orgId },
        create: {
          orgId,
          stripeSubscriptionId: subscription.id,
          stripePriceId: subscription.items.data[0].price.id,
          status: "ACTIVE",
          currentPeriodStart: new Date(subscription.current_period_start * 1000),
          currentPeriodEnd: new Date(subscription.current_period_end * 1000),
        },
        update: {
          stripeSubscriptionId: subscription.id,
          stripePriceId: subscription.items.data[0].price.id,
          status: "ACTIVE",
          currentPeriodStart: new Date(subscription.current_period_start * 1000),
          currentPeriodEnd: new Date(subscription.current_period_end * 1000),
        },
      });
      break;
    }

    case "customer.subscription.updated": {
      const subscription = event.data.object as Stripe.Subscription;
      const orgId = subscription.metadata?.orgId;
      if (!orgId) break;

      await db.subscription.update({
        where: { orgId },
        data: {
          status: subscription.status.toUpperCase() as any,
          stripePriceId: subscription.items.data[0].price.id,
          currentPeriodStart: new Date(subscription.current_period_start * 1000),
          currentPeriodEnd: new Date(subscription.current_period_end * 1000),
          cancelAtPeriodEnd: subscription.cancel_at_period_end,
        },
      });
      break;
    }

    case "customer.subscription.deleted": {
      const subscription = event.data.object as Stripe.Subscription;
      const orgId = subscription.metadata?.orgId;
      if (!orgId) break;

      await db.subscription.update({
        where: { orgId },
        data: { status: "CANCELED" },
      });
      break;
    }
  }

  return NextResponse.json({ received: true });
}

Kritisch: Der Webhook-Handler nutzt request.text() statt request.json() — Stripe braucht den Raw Body für die Signatur-Verifizierung. Das ist der Fehler Nr. 1, den wir bei Code-Reviews sehen. Außerdem: metadata bei Checkout-Session UND subscription_data.metadata setzen, damit die orgId in allen Events verfügbar ist.

Feature-Priorisierung: Was kommt ins MVP, was nicht?

Die härteste Entscheidung bei jedem MVP: Was lässt du weg? Wir nutzen MoSCoW — aber mit einer brutalen Regel: Alles, was nicht "Must" ist, kommt nicht ins MVP.

Konkretes Beispiel — ein Projektmanagement-Tool (wie ein vereinfachtes Linear):

| Feature | Priorität | MVP? | Begründung | |---|---|---|---| | User Registration + Login | Must | Ja | Ohne Auth kein SaaS | | Organization / Team erstellen | Must | Ja | Multi-Tenant ist Kern-Architektur | | Projekte anlegen + verwalten | Must | Ja | Kern-Feature | | Tasks erstellen, zuweisen, Status ändern | Must | Ja | Der eigentliche Wert des Produkts | | Stripe Subscription Billing | Must | Ja | Ohne Billing keine Validierung der Zahlungsbereitschaft | | E-Mail-Benachrichtigungen | Should | Nein | Nice-to-have, aber MVP funktioniert ohne | | Kanban-Board View | Should | Nein | List-View reicht für MVP | | File Attachments an Tasks | Should | Nein | Beschreibungs-Feld reicht | | Activity Log / Audit Trail | Could | Nein | Erst relevant bei Enterprise-Kunden | | Custom Fields | Could | Nein | Power-Feature, nicht MVP | | Gantt-Chart | Won't | Nein | Feature-Creep-Klassiker | | Mobile App | Won't | Nein | Responsive Web reicht für MVP | | SAML/SSO | Won't | Nein | Enterprise-Feature, nicht MVP | | API für Drittanbieter | Won't | Nein | Erst wenn Kunden danach fragen |

Die goldene Regel: Wenn du ein Feature entfernen kannst und der Kern-Nutzen noch funktioniert, gehört es nicht ins MVP. E-Mail-Notifications? User können die App öffnen und nachschauen. Kanban-Board? Eine sortierte Liste tut dasselbe. File Attachments? Link in die Beschreibung packen.

Der 8-Wochen Sprint-Plan

Hier ist der Woche-für-Woche-Plan, den wir in ähnlicher Form für jeden SaaS-MVP verwenden:

| Woche | Fokus | Deliverables | Key Decision | |---|---|---|---| | 1 | Discovery + Architecture | User Story Map, Wireframes (Figma/Excalidraw), Prisma Schema, Projekt-Setup mit CI/CD | Scope-Freeze: welche Features rein, welche raus | | 2 | Auth + Onboarding | Registration, Login (E-Mail + OAuth), E-Mail-Verifikation, Org-Erstellung, Invite-Flow | Auth-Provider: NextAuth vs. Clerk vs. Lucia | | 3 | Kern-Feature (Teil 1) | CRUD für Haupt-Entität, List/Detail Views, Basis-Navigation, Dashboard-Layout mit Sidebar | Datenmodell-Validierung mit echten Testdaten | | 4 | Kern-Feature (Teil 2) | Komplexere Interaktionen, Rollen-basierte Zugriffskontrolle, Such- und Filterfunktion | UI-Review mit Stakeholder — letzter Zeitpunkt für Scope-Änderungen | | 5 | Billing + Pricing Page | Stripe Integration, Checkout, Webhook-Handler, Pricing Page, Abo-Verwaltung (Up/Downgrade, Kündigung) | Pricing-Modell: Flat, per-Seat, oder Usage-based? | | 6 | Polish + Edge Cases | Error Handling, Loading States, Empty States, Toast Notifications, Form Validierung (Zod) | Welche Edge Cases sind launch-kritisch? | | 7 | Testing + Security | E2E Tests (Playwright) für Critical Path, Security Audit (Auth, CSRF, Input Validation), Performance-Check | Penetration Test nötig? (bei Fintech/Health: ja) | | 8 | Launch + Handover | Production Deployment (Vercel/AWS), Monitoring (Sentry), Analytics (PostHog/Plausible), Dokumentation, DNS + SSL | Launch-Strategie: Soft Launch vs. Public Launch |

Wichtig: Woche 4 ist der letzte Zeitpunkt für Scope-Änderungen. Danach ist Feature-Freeze. Alles, was nach Woche 4 als "muss noch rein" kommt, wandert in Sprint 2 nach dem Launch. Keine Ausnahmen.

Was es wirklich kostet: Detaillierte Aufschlüsselung

Transparenz bei Kosten ist uns wichtig. Hier die realistische Aufschlüsselung für ein SaaS MVP:

| Arbeitspaket | Stunden (Bereich) | Kosten (bei 120-150€/h) | |---|---|---| | Discovery + Architecture (User Stories, Wireframes, Schema, Infra-Setup) | 30-50h | 3.600 – 7.500 € | | Frontend (Layouts, Pages, Components, Responsive Design) | 60-100h | 7.200 – 15.000 € | | Backend + API (Datenmodell, Business Logic, tRPC/Server Actions) | 50-80h | 6.000 – 12.000 € | | Auth + Billing (NextAuth, Stripe Integration, Webhook Handler, Pricing Page) | 30-50h | 3.600 – 7.500 € | | Testing + QA (E2E Tests, Edge Cases, Cross-Browser, Security Audit) | 20-40h | 2.400 – 6.000 € | | DevOps + Deployment (CI/CD, Staging/Prod, Monitoring, DNS, SSL) | 15-25h | 1.800 – 3.750 € | | Projekt-Management + Kommunikation | 15-25h | 1.800 – 3.750 € | | Gesamt | 220-370h | 26.400 – 55.500 € |

Die Bandbreite erklärt sich durch die Komplexität des Kern-Features. Ein einfaches CRUD-SaaS (Formulare, Listen, Dashboards) liegt am unteren Ende. Ein SaaS mit komplexer Business Logic (Berechnungen, Workflows, Integrationen mit Drittanbieter-APIs) am oberen.

Nicht enthalten: Laufende Kosten nach dem Launch. Hosting (Vercel Pro: ~20$/Monat), Datenbank (Supabase/Neon: ~25$/Monat), Stripe-Gebühren (2,9% + 30ct pro Transaktion) und Monitoring (Sentry: ~26$/Monat) kommen on top — aber das sind unter 100€/Monat für den Start.

Die 5 Fehler, die wir am häufigsten sehen

Aus 40+ SaaS-Projekten haben sich klare Muster herauskristallisiert:

1. Multi-Tenant wird nachträglich eingebaut. Wenn du von Anfang an userId statt orgId als Tenant-Key verwendest, musst du später alles umbauen. Das Prisma-Schema oben zeigt, wie es richtig geht: Organization ist der Tenant, User sind über Memberships angebunden.

2. Stripe Webhooks werden nicht getestet. Die Checkout-Session funktioniert, aber was passiert bei einem fehlgeschlagenen Payment? Bei einem Downgrade? Bei einer Kündigung? Nutze stripe listen --forward-to localhost:3000/api/webhooks/stripe während der Entwicklung und teste jeden Event-Typ.

3. Der "noch ein Feature"-Reflex nach Woche 4. Jedes Feature, das nach dem Scope-Freeze reinkommt, verschiebt den Launch um mindestens eine Woche. Nicht weil das Feature eine Woche dauert, sondern weil es Seiteneffekte auf bestehenden Code hat.

4. Perfektes Design vor dem Launch. Dein MVP braucht kein Custom Design System. shadcn/ui + Tailwind sieht professionell aus und ist in Stunden statt Wochen implementiert. Das Custom Design kommt, wenn du weißt, dass das Produkt funktioniert.

5. Kein Billing am Launch-Tag. "Wir machen erstmal eine Free Beta" klingt vernünftig, validiert aber nicht die wichtigste Hypothese: Sind Menschen bereit, für dein Produkt zu zahlen? Stripe-Integration ab Tag 1, auch wenn es nur ein Pricing-Tier gibt.

Nach dem Launch: Die ersten 4 Wochen

Ein MVP ist ein Startpunkt, kein Endpunkt. Nach dem Launch beginnt die Phase, die über Erfolg oder Scheitern entscheidet:

• Woche 1-2: Nutzer-Feedback sammeln. Nicht per Survey, sondern per 15-Minuten-Call mit jedem einzelnen Early User. Frag nicht "Was fehlt dir?" sondern "Was hast du zuletzt versucht zu tun und es hat nicht funktioniert?"
• Woche 3-4: Die 3 häufigsten Pain Points fixen. Nicht 30 kleine Verbesserungen, sondern 3 gezielte Änderungen basierend auf echten Daten.

Der größte Fehler nach dem Launch: sofort ein Feature-Backlog mit 50 Items abarbeiten, statt die 3 wichtigsten Erkenntnisse umzusetzen. Disziplin beim Scope ist nach dem Launch genauso wichtig wie davor.

Fazit

Ein SaaS MVP in 8 Wochen ist realistisch — wenn der Scope brutal ehrlich definiert wird. Das bedeutet: MoSCoW ernst nehmen, Feature-Freeze nach Woche 4 einhalten, und den Drang unterdrücken, "nur noch dieses eine Feature" einzubauen.

Der Tech-Stack (Next.js, Prisma, Stripe, Tailwind) ist bewährt und erlaubt schnelle Iteration. Das Multi-Tenant-Datenmodell ist von Tag 1 richtig aufgesetzt. Die Stripe-Integration steht zum Launch. Und du hast ein Produkt, mit dem echte Nutzer echtes Geld bezahlen.

Du hast eine SaaS-Idee und willst in 8 Wochen live sein? Bei SecretStack bauen wir dein MVP im festen 8-Wochen-Sprint — mit dem exakten Prozess aus diesem Artikel. Kein Rätselraten, kein Scope Creep, kein endloses "wir sind fast fertig". Vom Discovery Call bis zum Production Deployment. Jetzt unverbindlich anfragen.