Was ein SaaS-MVP wirklich kostet — und was den Preis treibt

„Ein SaaS-MVP“ lässt sich aus dem Begriff allein so wenig bepreisen wie „ein Haus“. Die Variablen sind aber bekannt — und die meisten davon sind Entscheidungen, die du triffst, keine Tatsachen, die du entdeckst. Sie zu verstehen ist der Unterschied zwischen Angebote vergleichen und raten.

Die fünf Dinge, die den Preis wirklich bewegen

1. Wie viele Kernabläufe es gibt

Das ist der dominierende Faktor und wird fast immer unterschätzt. Ein Ablauf ist eine vollständige Aufgabe, für die Nutzer kommen: „ein Inserat veröffentlichen“, „Lohn abrechnen“, „eine Einreichung prüfen“. Ein sauber gebauter Ablauf ist ein echtes Produkt. Drei Abläufe sind ungefähr die dreifache Arbeit — nicht weil sich die Screens vervielfachen, sondern die Zustände dazwischen.

Gründerinnen und Gründer beschreiben regelmäßig fünf Abläufe und nennen das MVP. Das ist kein MVP, das ist Version zwei.

2. In welchem Verhältnis die Nutzer zueinander stehen

Ein Einzelnutzer-Werkzeug ist die günstigste Struktur überhaupt. Sobald Nutzer zu Organisationen gehören, Kolleginnen einladen, verschiedene Rollen haben und Datensätze teilen, hast du ein Berechtigungsmodell, das jede Abfrage und jeden Screen berührt. Diese eine Entscheidung kann einen Build verdoppeln — und im Wireframe ist sie unsichtbar.

3. Was das Geld tut

Eine Einmalzahlung oder ein einzelnes Pauschal-Abo ist ein ausgetretener Pfad. Nutzungsbasierte Abrechnung, Nutzerlizenzen, deren Anzahl sich mitten im Zyklus ändert, Testphasen mit Übergang in die Zahlung, anteilige Verrechnung, Mahnläufe bei fehlgeschlagenen Verlängerungen, Umsatzsteuer über EU-Länder hinweg oder Auszahlungen an Dritte — jeder dieser Punkte ist ein eigenes Feld von Sonderfällen.

4. Womit es sprechen muss

Eine App, der alle ihre Daten gehören, ist in sich geschlossen. Jedes externe System, mit dem sie sich abgleichen muss, bringt Authentifizierung, Ratenbegrenzung, Teilausfälle und den Release-Plan von jemand anderem mit. Integrationen werden meist zu günstig kalkuliert, weil die Demo schnell geht und die Zuverlässigkeitsarbeit nicht.

5. Was passiert, wenn es falsch ist

Ein Werkzeug für die eigene Leseliste und eines, das die Lohnabrechnung berechnet, können auf dem Bildschirm identisch aussehen. Sie sind nicht dasselbe Bauprojekt, weil die Kosten eines Fehlers nicht dieselben sind. Regulierte Daten, Geldflüsse und alles, wofür eine Kundin klagen würde, ziehen denselben Hebel: mehr Prüfung, mehr Review, mehr Kosten.

Wohin das Geld tatsächlich fließt

Ein verbreiteter Irrtum ist, dass ein Build vor allem aus Tippen besteht. Bei einem gut geführten, fokussierten Projekt sieht die Aufteilung eher so aus:

Das sind Arbeitsproportionen, keine Formel — sie verschieben sich je nach Projekt. Entscheidend ist: In den letzten 15 % wird aus „läuft bei mir“ ein „andere können es benutzen“. Und genau die werden zuerst gestrichen, wenn ein Angebot nur über den Preis konkurriert.

Warum Angebote so extrem auseinanderliegen

Wenn du für dasselbe Briefing 5.000 € und 50.000 € bekommst, sind das die üblichen Erklärungen:

• Unterschiedlich gelesener Umfang. Das eine las „MVP“ als einen Ablauf, das andere deine vollständige Beschreibung.
• Unterschiedliche Definition von fertig. Das eine kalkuliert eine funktionierende Demo, das andere ein gelaunchtes Produkt mit Zugriffsregeln, Zahlungssonderfällen und Dokumentation.
• Unterschiedliche Nachbetreuung. Manche Angebote enthalten eine Stabilisierungsphase und Fixes, andere enden mit der Lieferung.
• Unterschiedliches Eigentum. Manche Builds laufen auf den Konten der Agentur — anfangs günstiger, beim Wechsel teuer.
• Unterschiedlich bepreistes Risiko. Ein Festpreis fängt Unsicherheit ab, und dieses Abfangen zahlt jemand.

Unsere eigenen Zahlen, zur Einordnung

Damit es nicht abstrakt bleibt — das sind unsere Einstiegspreise für Geschäftskunden, das finale Angebot folgt nach Abstimmung des Umfangs:

Ein Einstiegspreis ist die Untergrenze für einen definierten Umfang, kein Durchschnitt. Mehr Abläufe, ein Organisations- und Rollenmodell oder nicht-triviale Abrechnung heben ein Projekt darüber — und das sagen wir im Angebot, nicht danach.

So bekommst du eine Zahl, der du trauen kannst

1. Schreib die eine Aufgabe auf, für die deine ersten Nutzer das Produkt einsetzen. Wenn du dich nicht entscheiden kannst, bist du noch nicht angebotsreif.
2. Beschreibe das Nutzermodell in einem Satz: Einzelpersonen oder Organisationen mit Rollen?
3. Beschreibe das Geld in einem Satz: Wer zahlt, wie oft, was passiert beim Aufhören.
4. Liste die Systeme auf, mit denen es sprechen muss, und markiere, welche zum Launch nötig sind und welche später.
5. Lass jedes Studio auf Basis genau dieser Seite kalkulieren — und sagen, was es ausschließt.

Diese Seite kostet eine Stunde und ist die wirkungsvollste Stunde im ganzen Projekt. Sie macht aus fünf unvergleichbaren Angeboten fünf vergleichbare.

Wenn du vor einer Entscheidung eine zweite Meinung zum Umfang willst: Genau dafür gibt es den Project Check — eine schriftliche Einschätzung und einen priorisierten Plan, unabhängig davon, ob du danach mit uns baust. Ist der erste Kernablauf schon klar, sieh dir den Umfang für ein Lovable-SaaS-MVP an.