Was kostet die Entwicklung eines SaaS-MVP?

Die meisten SaaS-MVPs fallen in eine von drei Stufen. Die Stufe hängt davon ab, wie viele unterschiedliche Aufgaben das Produkt für seine Nutzer erledigt und wie viel eigene Logik dahintersteckt.

Das sind Spannen, keine Angebote. Zwei Produkte derselben Stufe können sich trotzdem um Zehntausende Dollar unterscheiden, weil die Details in jedem Ablauf zählen.

Die Spannen umfassen Design, Entwicklung, Tests und Launch. Was der Betrieb danach kostet, ist nicht enthalten. Dazu weiter unten mehr.

Ein zentraler Ablauf ist eine vollständige Aufgabe, für die ein Nutzer kommt, vom ersten Klick bis zum Ergebnis. „Registrieren und eine Kollegin einladen“ ist ein Ablauf. „Ein Dokument hochladen und einen Bericht erhalten“ ist ein anderer.

Jeder Ablauf braucht Screens, Zustände, Backend-Logik, gespeicherte Daten und Tests. Zehn Screens für einen Ablauf kosten weniger als zehn Screens, die auf fünf Abläufe verteilt sind, denn jeder Ablauf bringt eigene Sonderfälle mit.

In den Sonderfällen steckt das Geld. Was passiert, wenn der Upload scheitert, die Zahlung abgelehnt wird oder der Nutzer den Tab mittendrin schließt? Jede Antwort bedeutet Design, Code und einen Test.

Ein Beispiel: Ein Start-up, das Laborergebnisse in einfacher Sprache erklärt, kann mit einem einzigen Ablauf starten: Datei hochladen, Erklärung lesen. Ein gut gemachter Ablauf trägt das ganze Produkt, und dieser Fokus hält es in den unteren Stufen.

Manche Funktionen wirken im Briefing klein und erweisen sich in der Entwicklung als groß. Auf diese weisen wir am häufigsten hin:

• Integrationen. Zahlungen, Login mit Google, CRMs, E-Mail-Dienste und externe APIs bringen jeweils Einrichtung, Fehlerbehandlung und Tests mit sich.
• Rollen und Berechtigungen. Gibt es Admins, Manager und Kunden, muss sich jeder Screen für jede Rolle korrekt verhalten.
• Datenintensive Oberflächen. Dashboards, Tabellen, Filter und Exporte brauchen mehr Design- und Entwicklungszeit als Inhaltsseiten mit gleich vielen Screens.
• Echtzeitfunktionen. Chat, Live-Updates und gemeinsames Bearbeiten brauchen zusätzliche Infrastruktur und sorgfältige Tests.
• Eine native App neben der Web-App. Sie bedeutet ein zweites Frontend und eine Prüfung im App Store.
• Ein verkürzter Zeitplan. Schneller heißt mehr Leute parallel, und Koordination kostet ebenfalls Geld.

Ein Beispiel: AutoIntel ist ein datenintensives B2B-Werkzeug, das Gebrauchtwagenanzeigen von mehreren deutschen Plattformen zusammenführt. Wir haben zuerst den Arbeitsbereich gestaltet und einen interaktiven Prototyp mit Beispielanzeigen gebaut. So konnte der Kunde festlegen, welche Felder und Filter wirklich zählen, bevor er für die Datenstrecke dahinter bezahlte.

Bei Integrationen liegen Schätzungen am häufigsten daneben. Der Normalfall ist schnell gebaut. Abgelehnte Karten, abgelaufene Sitzungen, doppelt eintreffende Webhooks und Erstattungen sind es nicht.

Am günstigsten binden Sie Zahlungen über einen gehosteten Checkout eines Anbieters wie Stripe an, statt ein eigenes Zahlungsformular zu bauen. Zusätzlich zahlen Sie dem Anbieter pro Transaktion: Der Standardsatz von Stripe für inländische Karten in den USA liegt bei 2,9% + 30 Cent. Das sind Betriebskosten, keine Entwicklungskosten, aber sie gehören in Ihren Plan.

CarPixly, ein KI-Fotostudio für Autoinserate, verkauft Renderings gegen Credits, die über einen gehosteten Checkout aufgeladen werden. Im Admin-Bereich kann das Team den Preis eigener Hintergründe ohne neues Release ändern. Solche Entscheidungen halten die Abrechnung nach dem Launch aus der Warteschlange der Entwickler heraus.

Der Entwicklungspreis ist nur ein Teil der Rechnung. Planen Sie ab dem ersten Monat diese laufenden Kosten ein:

• Hosting, Datenbank und Dateispeicher.
• Abonnements externer Dienste: E-Mail-Versand, Authentifizierung, Analytics, Karten oder KI-APIs.
• Gebühren für die Zahlungsabwicklung bei jeder Transaktion.
• App-Store-Gebühren, wenn Sie in einer mobilen App verkaufen.
• Fehlerbehebungen und kleine Verbesserungen, sobald echte Nutzer kommen.

Bitten Sie jede Agentur, die monatlichen Betriebskosten im Angebot zu schätzen. Bei Sakura gehört zu jedem Projekt ein festgelegtes Gewährleistungsfenster für Fehlerbehebungen. Laufende Arbeit danach erfolgt über einen monatlichen Supportplan, den Sie jederzeit beenden können.

Sie wissen nicht, in welche Stufe Ihre Idee fällt? Schicken Sie uns ein kurzes Briefing, und wir sagen Ihnen, wo sie landet. Die meisten unserer Angebote gehen innerhalb von 2–3 Werktagen nach einem vollständigen Briefing raus.

Kürzen Sie den Umfang, nicht die Qualität. Ein Produkt mit drei sauber gebauten Abläufen schlägt eines mit acht halbherzigen, weil Nutzer es nach den Abläufen beurteilen, die sie tatsächlich nutzen.

• Wählen Sie die ein oder zwei Abläufe, die Ihre Idee beweisen. Alles andere kommt auf eine „Später“-Liste, mit einer Begründung daneben.
• Legen Sie den Kern vor der Kalkulation fest, nicht während der Entwicklung. Mitten im Projekt die Richtung zu wechseln, ist die teuerste Art zu lernen.
• Nutzen Sie bestehende Infrastruktur. Auth-Anbieter, Zahlungsdienstleister und E-Mail-Dienste sind günstiger und sicherer als Eigenbauten.
• Gestalten Sie mit echten Komponenten. Teilen Design und Code ein Komponentensystem, muss zwischen Designdatei und Browser nichts neu gebaut werden.
• Starten Sie zuerst auf einer Plattform. Eine responsive Web-App erreicht Nutzer auf Smartphone und Desktop und braucht keine App-Store-Prüfung, solange Sie noch lernen.

Weniger, als die meisten Gründer erwarten. Der Stack zählt vor allem für die Zeit nach dem Launch: wie leicht Sie Entwickler finden, wie schnell das Produkt lädt und was der Betrieb kostet.

Eine gute Agentur wählt den Stack für Ihr Produkt, Ihr Budget und Ihre künftigen Mitarbeitenden, nicht den, den sie zufällig am besten kennt. Für viele Webprodukte ist das ein verbreitetes, gut unterstütztes Framework wie Next.js. Für mobile Apps ist es oft React Native, das iOS und Android aus einer Codebasis bedient.

Vorsicht bei zwei Extremen:

• Ein exotischer Stack startet vielleicht schnell, aber später ist es schwer, Leute dafür zu finden, und jede Änderung wird teurer.
• Ein No-Code-Werkzeug für ein komplexes Produkt ist für die erste Version günstig und teuer zu ersetzen, sobald Sie herausgewachsen sind.

Auch Geschwindigkeit gehört zur Stack-Entscheidung. Bei Sakura zielen wir vor dem Launch auf 95+ Punkte in Google PageSpeed Insights, weil ein langsames Produkt vom ersten Tag an Nutzer kostet.

Die meisten Start-ups enden, weil ihnen das Geld ausgeht. In der Analyse von CB Insights aus dem Jahr 2026 zu 431 wagniskapitalfinanzierten Unternehmen, die seit 2023 aufgegeben haben, war bei 70% das Kapital aufgebraucht, und 43% hatten einen schwachen Product-Market-Fit.

Ein MVP soll Ihnen Erkenntnisse verschaffen, bevor das Geld ausgeht. Budgetüberschreitungen fressen genau diesen Spielraum auf. Die üblichen Ursachen sind vorhersehbar:

• Neue Funktionen kommen mitten im Projekt dazu, ohne schriftlichen Änderungsprozess.
• Stundenabrechnung für Arbeit, die vorher niemand beschrieben hat.
• Nacharbeit, wenn sich Designs als teuer in der Umsetzung erweisen.
• Integrationen, die als eine Zeile geschätzt wurden statt mit ihren echten Sonderfällen.

Das sind Prozessprobleme, kein Pech. Ein Angebot mit klarem Umfang, einer schriftlichen Liste der Ausschlüsse und einem Änderungsprozess räumt die meisten davon aus.

Bei einem MVP mit definierten zentralen Abläufen schützen fester Umfang und fester Preis Ihr Budget. Die Agentur trägt das Risiko ihrer eigenen Schätzung, und Sie kennen die Kosten vor Arbeitsbeginn.

Stundenabrechnung ist sinnvoll, wenn sich die Arbeit wirklich noch nicht beschreiben lässt, etwa bei früher Recherche oder einer technischen Unbekannten. Beide Modelle vergleichen wir ausführlich in Festpreis oder Stundenabrechnung.

Egal, welches Modell Sie wählen: Koppeln Sie Zahlungen an Meilensteine, die Sie prüfen können, etwa freigegebene Designs, einen funktionierenden Build unter einem Testlink und den Launch. Bei Sakura nehmen wir nie 100% vor Arbeitsbeginn.

Für ein genaues Angebot braucht es Verständnis dafür, was Sie bauen, keine Funktionsliste. Für den Anfang genügt ein kurzes Briefing mit diesen fünf Punkten:

• Wer die Nutzer sind und welches Problem sie heute haben.
• Die ein bis drei Aufgaben, die das Produkt zum Launch erledigen muss.
• Integrationen, von denen Sie schon wissen, dass Sie sie brauchen.
• Ihre Deadline und was dahintersteht.
• Eine grobe Budgetspanne, damit sich der Umfang daran ausrichten lässt.

Das Ziel eines MVP ist nach den Worten von Lean Startup, „so schnell wie möglich mit dem Lernen zu beginnen“. Ein gutes Angebot richtet sich nach diesem Ziel. Wenn Ihnen der Zeitplan ebenso wichtig ist wie das Geld, lesen Sie unseren Leitfaden dazu, wie lange die Entwicklung eines MVP dauert.

Wenn Sie so weit sind, erzählen Sie uns von Ihrem Produkt. Wir antworten zuerst mit Fragen und danach mit einem Festpreisangebot.