Was kostet es, ein MVP bauen zu lassen?

Was ein MVP wirklich ist, und was nicht

Fangen wir dort an, wo das Missverständnis entsteht: beim Wort selbst. Wer versteht, was ein MVP ist, kann jedes Angebot, das er später bekommt, selbst einordnen. Hier gehen die Preise auseinander, und hier lässt sich am meisten sparen oder verbrennen.

MVP steht für Minimum Viable Product, auf Deutsch sinngemäss die kleinste brauchbare Produktversion. Zwei Wörter tragen die ganze Bedeutung. Minimum heisst so wenig wie möglich. Viable heisst, dass ein echter Nutzer trotzdem einen echten Wert davon hat. Ein MVP ist also weder die billige Vorstufe deines Produkts noch die halbfertige Vollversion. Es ist die kleinste Sache, mit der du eine offene Frage beantworten kannst: Will überhaupt jemand das, was du dir ausgedacht hast?

Daraus folgt der wichtigste Satz dieses Artikels. Der Preis eines MVP hängt nicht davon ab, was dein Produkt am Ende alles können soll, sondern davon, wie diszipliniert du beim Weglassen bist. Wer den MVP als Version 1 mit allem Nötigen versteht, baut kein MVP, sondern ein teures erstes Produkt. Beides kann der richtige Weg sein. Nur kosten sie ein Vielfaches voneinander.

Ein Beispiel macht das greifbar. Du willst eine Plattform, auf der Handwerksbetriebe ihre Termine planen. Die grosse Version hat einen Team-Kalender, Kundenbenachrichtigungen, Rechnungen, eine mobile App und eine Anbindung an die Buchhaltung. Der MVP stellt nur eine einzige Frage: Tragen Handwerker ihre Termine überhaupt digital ein, wenn es schnell genug geht? Dafür reicht ein gut gemachter Ablauf auf dem Handy. Der Rest kommt später, falls die Antwort ja lautet. Auf dem Papier dieselbe Idee, im Preis Welten dazwischen.

Eine Formel, die du im Kopf behalten kannst

Damit du eine Zahl selbst herleiten kannst, hilft eine bewusst einfache Formel:

Kosten = Aufwand × Stundensatz + laufender Betrieb

Der Aufwand ist die Menge an Arbeit, gemessen in Personenstunden oder Personenwochen. Der Stundensatz hängt davon ab, wer baut. Der Betrieb ist das, was nach dem Launch Monat für Monat anfällt. Fast jedes Gespräch dreht sich nur um den ersten Teil. Über die Gesamtkosten entscheidet am Ende oft der dritte. Gehen wir die drei der Reihe nach durch.

Der Aufwand: warum das Unsichtbare teuer ist

Der Aufwand ist selten dort am grössten, wo Laien ihn vermuten. Die sichtbare Funktion, das, was der Nutzer anklickt, ist oft erstaunlich schnell gebaut. Teuer wird das Unsichtbare drumherum.

Der Scope ist der grösste Hebel. Jede zusätzliche Funktion kostet zweimal: einmal beim Bauen und einmal, weil sie den Moment verschiebt, an dem du lernst, ob die Idee trägt. Eine brauchbare Faustregel: Tut dir das Streichen einer Funktion nicht ein bisschen weh, hast du noch zu wenig gestrichen.

Integrationen sind oft der teuerste Einzelposten. Sobald dein MVP mit fremder Software reden muss, etwa einem ERP, einer Zahlungsabwicklung oder einer externen Schnittstelle, steigt der Aufwand sprunghaft. Fremde Systeme verhalten sich selten so sauber, wie ihre Dokumentation verspricht. Eine einzige, tief integrierte Anbindung kann mehr kosten als die halbe restliche Anwendung. Wie sich solche Schnittstellen kalkulieren lassen, haben wir in Schnittstellen und ERP-Anbindung: was kostet das auseinandergenommen.

Drei stille Brocken werden fast immer unterschätzt: Auth, Billing und Compliance. Ein einfaches Login ist schnell gebaut. Sobald Rollen, Teams, Einladungen, Single Sign-on und die Frage wer darf was sehen dazukommen, wird daraus ein eigenes Teilprojekt. Die Abrechnung ist ein kleines Produkt für sich: Abos, Probephasen, Rabatte, Mehrwertsteuer, Rechnungen und fehlgeschlagene Zahlungen wollen alle behandelt sein. Und Compliance, also Datenschutz, Datenhaltung in der Schweiz und branchenspezifische Regeln, lässt sich nicht nachträglich draufkleben. Für einen MVP darfst du vieles davon bewusst klein halten oder mit fertigen Bausteinen abdecken. Wo die Grenze sinnvoll verläuft, zeigt der Artikel zu Auth, Billing und Compliance im SaaS.

Qualität gehört an die eine richtige Stelle. Ein MVP muss nicht schön sein. Der eine Kernablauf aber muss sich gut anfühlen, sonst lernst du aus der Nutzung nichts Verwertbares. Sparen ist richtig, nur nicht an der Stelle, auf die es ankommt.

Der Stundensatz: wer baut, und was am Ende übrig bleibt

Derselbe MVP kostet bei einem Junior-Team, einem erfahrenen Entwickler, einer grossen Agentur oder einem Offshore-Anbieter sehr unterschiedlich. Der Unterschied steckt nicht nur im Satz, sondern im Ergebnis pro Stunde. Ein günstiger Satz, der dreimal so lange braucht oder Code hinterlässt, den später niemand mehr anfassen mag, ist am Ende der teurere.

Die nüchterne Rechnung lautet darum nicht Franken pro Stunde, sondern Franken pro Ergebnis. Erfahrung kostet im Satz mehr und spart an drei Stellen: weniger Sackgassen, weniger Nacharbeit und ein Produkt, das du danach weiterentwickeln oder übergeben kannst, ohne dass es auseinanderfällt. Schau also weniger auf den Tagessatz und mehr darauf, ob du den Code am Ende besitzt und verstehst.

Der Betrieb: der Posten, den fast alle vergessen

Ein MVP ist nicht fertig, wenn er auf dem Laptop des Entwicklers läuft. Er ist fertig, wenn echte Nutzer ihn zuverlässig benutzen. Dazwischen liegt der Betrieb, und der kostet jeden Monat Geld, ganz gleich wie viele Leute das Produkt gerade nutzen.

Zum Betrieb gehören Dinge, die im Angebot oft fehlen. Hosting, der Server, auf dem alles läuft. Monitoring, damit du einen Ausfall bemerkst, bevor deine Nutzer ihn bemerken. Backups, damit verlorene Daten zurückkommen. Updates, um Sicherheitslücken zu schliessen. Und Support, die Zeit, in der jemand auf Störungen reagiert. Was diese Posten ungefähr ausmachen, rechnet Was kostet der SaaS-Betrieb pro Monat im Detail vor.

Wer all das erst nach dem Launch dazudenkt, zahlt doppelt: einmal fürs nachträgliche Einbauen und einmal für jede Störung, die niemand kommen sieht, weil kein Monitoring da ist. Als Operator-Entwickler rechnen wir den Betrieb von Tag eins mit ein, weil wir unsere eigenen Produkte selbst betreiben. Was ein vergessenes Backup oder eine ungeprüfte Skalierung wirklich kostet, kennen wir aus erster Hand und planen entsprechend.

Das Budget in Phasen aufteilen

Du musst nicht das ganze Budget auf einmal aufs Spiel setzen. Teile es in Phasen mit festem Preis. Die erste Phase, also Konzept, Datenmodell und ein lauffähiger Prototyp des Kernablaufs, lässt sich sauber abgrenzen und vorher kalkulieren. Du kennst den Betrag, bevor es losgeht. Danach entscheidest du mit echten Nutzerdaten in der Hand, ob und wie es weitergeht, statt auf gut Glück eine grosse Summe zu binden. Wann Festpreis gegenüber laufender Abrechnung sinnvoll ist, vergleicht Festpreis oder Time-and-Material.

Geht es danach in den dauerhaften Aufbau und Betrieb, ist ein Monatsmodell meist klarer als immer neue Einzelofferten. Bauen, kleine Verbesserungen, Betrieb und Support liegen dann planbar in einem Budget, und du siehst Monat für Monat, was du dafür bekommst.

Selbst bauen oder bauen lassen

Hast du bereits ein eingespieltes Entwicklungsteam, baue selbst. Niemand kennt dein Produkt besser als die Leute, die ohnehin da sind. Lohnt sich der Aufbau eines Teams für eine noch unbewiesene Idee dagegen nicht, ist Bauen-Lassen der schnellere und am Ende oft günstigere Weg. Du zahlst für ein Ergebnis statt für fremde Lernkurven und bindest kein Kapital in Festanstellungen, bevor du weisst, ob das Produkt trägt. Wichtig ist nur eines: Am Ende gehören dir Code, Dokumentation und eine saubere Übergabe, damit du frei bleibst. Genau dafür ist unsere SaaS-Produktentwicklung gemacht.

Wann sich ein MVP gar nicht lohnt

Nicht jede Idee braucht einen MVP, und manchmal ist Geld dafür schlecht angelegt. Wenn deine Nutzer ihr Problem heute schon mit einer Tabelle oder einem fertigen Standardtool lösen und nur leise murren, baust du womöglich gegen eine Lösung an, die gut genug ist. Wenn die offene Frage keine technische ist, sondern eine Vertriebsfrage, dann beantwortet sie kein Code, sondern ein Telefonat mit zehn Wunschkunden. Und wenn du den Markt schon kennst und nur ausführen willst, sparst du dir die MVP-Bühne und baust gleich auf Bestand. Ein MVP lohnt sich dort, wo eine echte Unsicherheit im Raum steht, die du nur am lebenden Nutzer auflösen kannst. Steht keine solche Frage im Raum, gib das Geld woanders aus.

Eine Grössenordnung, und warum es keine exakte Zahl gibt

Eine belastbare Zahl entsteht erst, wenn der Scope steht, weil genau der Scope den Aufwand bestimmt. Was sich trotzdem sagen lässt, hilft beim Einordnen: Ein wirklich fokussierter MVP mit einem einzigen Kernablauf bewegt sich in der Grössenordnung von Wochen, nicht von Monaten. Kommen mehrere Integrationen, echte Nutzerverwaltung oder eine vollständige Abrechnung dazu, reden wir schnell über mehrere Monate Arbeit.

So rechnest du selbst grob durch: Schätze die nötigen Personenwochen, multipliziere sie mit einem realistischen Satz, addiere den monatlichen Betrieb. Das Ergebnis ist keine Punktlandung, sondern eine Bandbreite, und mehr ist seriös auch nicht drin. Wer dir vor dem ersten echten Gespräch eine exakte Zahl nennt, rät entweder oder hat die Hälfte vergessen.

Der teuerste MVP ist der, den niemand braucht

Der grösste Kostenfaktor taucht in keiner Offerte auf. Der teuerste MVP ist der, der technisch sauber gebaut ist und am Markt vorbeigeht. Sechs Monate Arbeit für ein Produkt, das niemand nutzt, sind teurer als jede überschätzte Integration.

Definiere darum vorab die eine Annahme, die stimmen muss, damit sich alles Weitere lohnt. Baue genau so viel, dass du diese Annahme mit echten Nutzern prüfen kannst, und keinen Klick mehr. Lieber in vier Wochen eine belastbare Antwort als in sechs Monaten ein poliertes Produkt ohne Markt.

Die bessere Frage

Was kostet ein MVP ist die falsche Frage, solange unklar ist, was du unter MVP verstehst. Die bessere lautet: Wie klein darf der erste Schritt sein, damit ich lerne, ob die Idee trägt? Sobald das steht, ergibt sich der Preis aus den drei Faktoren, die du jetzt kennst: Aufwand, Stundensatz und Betrieb.

Halte den Kern klein, plane den Betrieb von Tag eins mit und kauf dir mit dem ersten Budget vor allem eines: eine belastbare Antwort auf die Frage, ob jemand dein Produkt wirklich will. Wie wir das von der ersten Idee bis zum laufenden Betrieb umsetzen, liest du auf unserer Seite zur SaaS-Produktentwicklung.