Was kostet es, ein SaaS-MVP zu entwickeln?

„Was wird das kosten?" ist die erste Frage, die jeder Gründer stellt – und die ehrliche Antwort lautet: Das hängt von Umfang, Team und Ihrer Disziplin ab. Aber „kommt drauf an" nützt Ihnen nichts, wenn Sie ein Budget planen oder eine Finanzierungsrunde vorbereiten. Deshalb folgen hier echte Größenordnungen, die Faktoren, die sie verschieben, und die Disziplin, die verhindert, dass die Zahl aus dem Ruder läuft. Das Ziel eines MVP ist nicht, Ihr Produkt zu bauen – sondern herauszufinden, ob das Produkt es wert ist, gebaut zu werden. Kalkulieren Sie entsprechend.

Was die Kosten wirklich treibt

Der Preis eines MVP ist fast ausschließlich eine Funktion der Anzahl eigenständiger Abläufe, die er enthält. Jeder Ablauf – Registrierung, Abrechnung, ein Dashboard, ein Admin-Bereich – bedeutet Design, Frontend, Backend und Testing, multipliziert und miteinander integriert, dann QA'd. Die entscheidende Zahl sind nicht „Features", sondern Screens mal Integrationen mal Zustände. Ein einziger Screen hat einen Ladezustand, einen Leerzustand, einen Fehlerzustand, einen Erfolgszustand und ein mobiles Layout. Das sind fünf Dinge, die designed und gebaut werden müssen – nicht eines –, und genau hier verdoppeln sich Schätzungen, die sich „ungefähr richtig" anfühlten, still und leise.

Die drei größten Kostentreiber, die wir erleben, in dieser Reihenfolge:

• Auth und Abrechnung. Zahlungen, Abonnements, Anteilige Abrechnung, Dunning, Steuern und die Grenzfälle rund um fehlgeschlagene Kartenzahlungen wirken einfach – und sind es nie. Planen Sie hier echte Zeit ein: Es ist die Infrastruktur, die Geld berührt, Bugs sind teuer, und Vertrauen ist fragil. Unser Leitfaden zur Payment-Gateway-Integration zeigt die typischen Fallstricke.
• Tiefe der Custom UI. Eine CRUD-Tabelle ist günstig. Ein Drag-and-Drop-Editor, ein Live-Dashboard, ein Kalender oder ein Rich-Text-Editor nicht. Interaktivität ist der Ort, an dem Stunden verschwinden.
• Drittanbieter-Integrationen. Jede externe API, die Sie anbinden, bringt Authentication, Rate Limits, Retries, Webhook-Handling und Fehlerzustände mit sich. Zwei Integrationen sind nicht doppelt so viel Arbeit wie eine – die Wechselwirkungen zwischen ihnen erzeugen ihren eigenen Aufwand.

Realistische Budgetrahmen

Die Preise variieren stark nach Region und Team-Seniorität, denken Sie daher in Bandbreiten, nicht in konkreten Zahlen. Die folgenden Angaben setzen ein kompetentes Senior-Team und einen Gründer voraus, der schnell Entscheidungen treffen kann:

1. Lean MVP (ein Kernablauf): Ein fokussiertes Produkt mit Auth, einem Hauptfeature und Stripe-Abrechnung. Grob \$15k–\$40k, in 4–6 Wochen mit einem kleinen Team erreichbar. Das ist die ideale Form, um eine einzelne Hypothese zu testen.
2. Standard-MVP (mehrere Abläufe): Mehrere verknüpfte Abläufe, ein Admin-Bereich, Benachrichtigungen und ein paar Integrationen. Grob \$40k–\$90k, typischerweise 8–12 Wochen. Die meisten finanzierten Pre-Seed-Produkte landen hier.
3. Komplexer MVP (Echtzeit, AI oder datenintensiv): Live-Kollaboration, LLM-Features, Multi-Tenant-Architektur oder anspruchsvolles Datenmodell. \$90k und mehr, 12+ Wochen. Wenn Sie AI integrieren möchten, lesen Sie zunächst how to build an AI MVP in 30 days – die Kostentreiber sind dort andere.

Das sind Agenturen- und Senior-Contractor-Preise. Ein Senior-Team in Osteuropa oder Nordafrika kostet für vergleichbare Ergebnisse einen Bruchteil eines US-amerikanischen In-House-Teams – ein Grund, warum viele Gründer v1 mit einer Agentur bauen, statt einzustellen. Unser Vergleich Agentur vs. In-House wägt diesen Trade-off ehrlich ab.

Das Team bestimmt den Preis

Der gleiche Umfang hat je nach Teammodell völlig unterschiedliche Preisschilder – und jedes Modell hat seine spezifischen Risiken:

• Solo-Freelancer: Am günstigsten pro Stunde, aber ein Single Point of Failure ohne Design, ohne QA und ohne Vertretung bei Krankheit oder Verschwinden. Vertretbar für sehr kleine Builds; riskant für alles, worauf Sie das Unternehmen setzen.
• In-House-Mitarbeiter: Die richtige langfristige Antwort, sobald das Produkt validiert ist – aber langsam und teuer aufzubauen. Allein das Recruiting kann die Monate kosten, die Sie sparen wollten, und Sie zahlen Gehälter, bevor Sie wissen, ob das Produkt funktioniert.
• Agentur: Ein fertiges Team aus Design, Frontend, Backend, PM und QA, das v1 schnell liefert und Ihnen eine wartbare Codebase übergibt. Kostet mehr pro Woche als ein Freelancer, aber weniger insgesamt als ein verpfuschter Build, den Sie neu entwickeln müssen. Das Risiko ist eine schlechte Agentur, die überbaut oder verschwindet – prüfen Sie das anhand von Software-Projektwarnzeichen.

Das günstigste Angebot ist fast nie das günstigste Projekt. Ein Build, der grundlegend neu geschrieben werden muss, kostet Sie das Doppelte plus die verlorene Marktzeit – was häufig der größte Kostenfaktor von allen ist.

Wie der Zeitplan wirklich aussieht

Geld und Zeit tauschen sich gegeneinander aus – aber nicht linear. Mehr Leute auf ein verspätetes MVP zu werfen, erzeugt vor allem Koordinationsaufwand. Ein realistischer Standard-MVP verteilt sich ungefähr so:

1. Woche 1–2: Discovery und Design. Abläufe, Datenmodell und Screens festlegen. Diesen Schritt zu überspringen, um „mit dem Coden anzufangen", ist die teuerste Abkürzung in der Softwareentwicklung – siehe Scoping von Software-Projekten. Umfang auf dem Papier zu kürzen ist kostenlos; ihn nach der Implementierung zu kürzen, nicht.
2. Wochen 3–9: Build. Zuerst die Kernschleife, dann die unterstützenden Abläufe – kontinuierlich integriert und reviewed, statt in einem großen Merge am Ende.
3. Wochen 10–12: Härten und Launch. QA mit echten Nutzern, Grenzfälle, Performance und die Launch-Checkliste. Das ist die Phase, für die Gründer kein Budget einplanen – und die sie immer brauchen.

Die versteckten Kosten, die Gründer vergessen

Das Build-Angebot ist nicht die Gesamtrechnung. Planen Sie ein:

• Design. Wenn Sie keinen Designer haben, braucht ein nutzbares Produkt einen. Budgetieren Sie es ein – oder akzeptieren Sie eine rauere erste Version.
• Infrastruktur und SaaS. Hosting, Datenbank, E-Mail, Monitoring, Error Tracking – früh günstig (oft unter \$100/Monat bei Managed Services), aber real.
• Die 20 % nach „fertig". Die Lücke zwischen feature-complete und launch-ready – Bugfixes, Politur, Grenzfälle von echten Nutzern – ist immer größer als gedacht. Halten Sie Reserven bereit.
• Iteration. Der Sinn eines MVP ist es, zu lernen – und Lernen bedeutet Dinge zu verändern. Die Build-Kosten sind der Eintrittspreis, nicht die Gesamtsumme.

Wo Budgets verschwendet werden

Die meisten Kostenüberschreitungen sind selbst verursacht. Die üblichen Verdächtigen:

• Einstellungsseiten, granulare Berechtigungen und Admin-Tooling bauen, bevor die Kernschleife bewiesen ist.
• Pixelgenaue Politur auf Abläufen anstreben, die noch niemand nutzt.
• Microservices oder Kubernetes für eine App mit null Nutzern einsetzen – eine klassische Premature-Optimization-Falle, beschrieben in Microservices vs. Monolith.
• Scope, der sich still ausweitet, weil niemand das „Nein" besitzt. Das ist der größte Faktor: unkontrolliertes Scope Creep ist der häufigste Killer von MVP-Budgets.
• MVP mit MLP verwechseln – einem Minimum Lovable Product – und zu viel in Begeisterung investieren, bevor die Nachfrage bestätigt ist. Der Unterschied ist wichtig; siehe MVP vs. MLP.

Ein modularer Monolith auf Supabase oder eine schlanke NestJS-API mit PostgreSQL und einem Next.js-Frontend trägt einen MVP zu seinen ersten tausend Nutzern, ohne einen teuren Infrastrukturumweg. Das vollständige Playbook finden Sie in how to build a SaaS MVP.

Festpreis oder Zeit und Material?

Für einen klar definierten MVP mit eindeutigen Grenzen gibt Ihnen ein Festpreis Budgetsicherheit und überträgt das Schätzrisiko auf den Auftragnehmer – allerdings setzt er auch Anreize, Ecken abzuschneiden und über Change Requests zu streiten. Für einen explorativen Build, bei dem Sie davon ausgehen, zu lernen und zu pivotieren, hält Zeit und Material mit einem gedeckelten Budget und wöchentlichen Check-ins Sie flexibel. Die meisten gesunden MVP-Engagements sind ein Hybrid: ein fester Umfang für den bekannten Kern, T&M für die Discovery drumherum. Wir beleuchten die Trade-offs in Festpreis vs. Zeit und Material.

Wie Sie das Budget strecken

Investieren Sie in den kritischen Pfad – von der Registrierung bis zum ersten Mehrwert – und kürzen Sie überall sonst. Konkret:

1. Scope radikal kürzen. Schreiben Sie jedes Feature auf, dann fragen Sie sich: Scheitert die Kernhypothese ohne es? Wenn nicht, gehört es in v2.
2. Managed Services nutzen, damit Sie für Ergebnisse zahlen, nicht für undifferenzierte Infrastruktur, die Sie ewig warten müssten.
3. Bewährte UI-Komponenten wiederverwenden, statt jeden Screen neu zu gestalten. Eine gute Komponentenbibliothek spart Ihnen Wochen.
4. Manuell tun, was Sie später automatisieren würden. Frühe Kunden manuell onboarden, Reports manuell erstellen. Automatisieren Sie erst, wenn die Nachfrage bewiesen ist.
5. Einen harten Termin setzen. Ein fixer Zeitplan ist die wirksamste Kostenkontrolle überhaupt – weil er die Scope-Gespräche erzwingt, die einen MVP zum MVP machen.

Kosten sind nicht die eigentliche Frage

Hier ist die Neuperspektive, die Gründern am meisten Geld spart: Ein MVP soll Informationen kaufen – den Beweis, dass Menschen das wollen – so günstig wie möglich. Die Frage lautet also nicht: „Was ist das Wenigste, das ich ausgeben kann, um mein Produkt zu bauen?" Sondern: „Was ist das Wenigste, das ich ausgeben kann, um herauszufinden, ob mein Produkt es wert ist, gebaut zu werden?" Die Antworten unterscheiden sich oft erheblich. Manchmal ist der günstigste valide MVP eine Landing Page und ein manueller Concierge-Prozess – und die eigentliche Software kommt erst, wenn die Nachfrage unübersehbar ist.

Messen Sie jeden Budgetposten an diesem Maßstab. Ein Feature, das Ihnen nicht hilft, schneller zu lernen, gehört nach dem Launch – egal wie offensichtlich es „dazugehören" scheint. Die Disziplin, zu entscheiden, was nicht gebaut wird, ist mehr wert als jede Stundensatz-Arbitrage – sie ist der Unterschied zwischen einem \$30k-Experiment, das Sie etwas lehrt, und einem \$120k-Produkt, das niemand bestellt hat. Das vollständige Build-Playbook finden Sie in how to build a SaaS MVP; die obige Budget-Denkweise ist das, was es ehrlich hält.

Wenn Sie eine offene, detaillierte Schätzung für Ihre spezifische Idee möchten – ohne aufgeblähte Posten, ohne Overengineering – sprechen Sie mit uns. Wir sagen Ihnen, was es wert ist, jetzt zu bauen, und was auf die Liste nach dem Launch gehört.