Web-App-MVP (Minimum Viable Product): Kosten im 212-Stunden-Referenzmodell

Kurzantwort: Ein Web-App-MVP mit Registrierung, einem Kernobjekt und Bezahlfunktion liegt nach meinem Kalkulationsmodell bei etwa 210 bis 250 Stunden Bauaufwand. Was daraus in Euro wird, ergibt sich erst aus dem Stundensatz im konkreten Angebot — entscheidend für den Preis ist vor allem der Scope-Schnitt.

Ein Web-App-MVP (Minimum Viable Product) ist die kleinste funktionsfähige Version einer Web-App, mit der echte Nutzer eine echte Aufgabe erledigen und Sie dabei eine Geschäftsannahme prüfen — und die Kosten dafür entstehen nicht im Stundensatz, sondern im Scope-Schnitt. Ein Referenz-MVP mit Registrierung, einem Kernobjekt, Bezahlfunktion und einer schlanken Betreiber-Sicht liegt in meiner Kalkulation bei 212 Stunden Bauaufwand, mit Unschärfezuschlag bei rund 244. Was daraus in Euro wird, rechnen Sie mit dem Satz aus, den Sie im konkreten Angebot verhandeln — das Modell unten zeigt Ihnen, wofür Sie zahlen und welche Positionen Sie streichen können, ohne das Lernziel zu verlieren.

Das ist ein Rechenmodell aus eigenen Projekten, kein Marktpreis. Angebote streuen je nach Anbieter, Risikoverteilung und Vorarbeit erheblich. Übertragbar ist die Struktur: Wer ein Angebot in diese 14 Positionen zerlegen kann, sieht innerhalb einer halben Stunde, ob der Anbieter dasselbe MVP meint wie er selbst.

Warum zwei Angebote für dasselbe MVP um Faktor drei auseinanderliegen

Nehmen Sie die Zeile „Bezahlfunktion". Beispiel: In einem schlanken Zuschnitt bedeutet sie vielleicht etwa 20 Stunden — gehosteter Checkout, ein Webhook, Abo-Status im Nutzerprofil, fertig. In einem umfassenden Zuschnitt kann dieselbe Zeile eher 80 bis 90 Stunden bedeuten — drei Preisstaffeln, Gutscheincodes, anteilige Upgrades mitten im Abrechnungszeitraum, Rechnungs-PDF mit fortlaufender Nummer, Mahnlauf bei fehlgeschlagener Abbuchung. Die tatsächliche Stundenzahl hängt vom gewählten Zahlungsanbieter, vom Abrechnungsmodell und vom Rechnungsformat ab, das Sie brauchen.

Beide Anbieter schreiben „Bezahlfunktion" ins Angebot. Beide können ehrlich kalkuliert haben. Der Preisunterschied stammt in solchen Fällen typischerweise weniger aus dem Stundensatz als aus dem Scope-Schnitt: Der eine hat den Posten in 14 Unterpositionen zerlegt, der andere in 40.

Die Gegenmaßnahme kostet Sie eine E-Mail: Verlangen Sie zu jeder Angebotszeile nicht nur, was enthalten ist, sondern eine kurze Liste dessen, was ausdrücklich *nicht* enthalten ist. Anbieter, die darauf nicht antworten können, haben den Scope selbst nicht durchdacht. Wie Sie Anfragen so stellen, dass Angebote überhaupt vergleichbar werden, habe ich in der Web-App-Angebot einholen: Checkliste für Anfrage und Vergleich im Detail aufgeschrieben.

Das 212-Stunden-Referenzmodell

Angenommen wird eine SaaS-artige Web-App: Ein Nutzertyp plus Betreiber, ein fachliches Kernobjekt, Bezahlung, keine Altdaten-Migration, Rechtstexte werden vom Auftraggeber geliefert.

Auf 212 Stunden kommt ein Unschärfezuschlag von 15 Prozent, also rund 244 Stunden für die Kalkulation. Bei einer Person mit 25 wirklich produktiven Stunden pro Woche sind das etwa neun bis zehn Wochen Laufzeit, inklusive Abstimmungsrunden eher elf.

Zwei Positionen streicht fast jeder zuerst, und beide sind die falsche Wahl: Nummer 12 und Nummer 13. Ohne Tests der kritischen Pfade merken Sie einen kaputten Checkout erst, wenn ein Nutzer sich beschwert. Ohne Fehler-Alerting merken Sie ihn gar nicht.

Die sieben Anforderungen, die das Budget kippen

Diese Punkte klingen im Kickoff nach Kleinigkeiten. Sie sind es nicht.

Rechnen Sie nach: Offline plus Mandantenfähigkeit plus Rollenmodell sind 180 Stunden — fast noch einmal das komplette Kern-MVP, für Funktionen, die keine einzige Produktannahme testen.

Der Datenimport verdient eine Sonderwarnung. Der Beispielwert von 35 Stunden in der Tabelle gilt nur für vergleichsweise saubere Ausgangsdaten. Bei gewachsenen Excel-Beständen mit Freitextspalten, Dubletten und mehreren Schreibweisen desselben Kunden lässt sich der Aufwand seriös erst schätzen, nachdem jemand eine Stichprobe gesichtet hat — als Richtwert etwa 200 Zeilen. Holen Sie diese Stichprobe vor der Angebotserstellung ein, nicht danach.

Die 40-Stunden-Regel

Jede Einzelfunktion, die in der Schätzung über 40 Stunden liegt, gehört nicht ins MVP. Sie wird entweder auf unter 40 Stunden zurückgeschnitten oder in Release 2 verschoben.

Der Grund ist reine Portfolio-Logik: 40 Stunden sind fast ein Fünftel des Kern-Budgets, gesetzt auf eine einzige, noch ungeprüfte Annahme. Wenn diese Annahme fällt, ist ein Fünftel des Budgets weg — und Sie haben es ausgerechnet für die Funktion ausgegeben, über die Sie am wenigsten wussten.

Die Ausnahme ist der Fall, in dem genau diese Funktion das Produkt *ist*: Der Algorithmus, die Auswertung, die Berechnung, wegen der jemand zahlt. Dann darf sie 60 Stunden kosten, und drei andere Positionen fliegen dafür raus.

Kosten pro geprüfter Annahme statt Kosten pro Feature

Ein MVP kauft keine Software, es kauft Wissen. Rechnen Sie deshalb nicht in Kosten pro Feature, sondern in Kosten pro Annahme, die Sie danach nicht mehr raten müssen.

Ein typisches MVP prüft drei Annahmen: Dass ein bestimmtes Problem existiert, dass Ihre Lösung es adressiert, und dass Leute dafür zahlen. Setzt man das 212-Stunden-Referenzmodell von oben an, ergibt die reine Division rund 71 Stunden pro geprüfter Annahme. Das ist keine Marktkennzahl, sondern eine Rechengröße innerhalb dieses Modells — sie taugt als Vergleichsmaßstab zwischen Varianten desselben Projekts, nicht als absoluter Wert.

Denn manche Annahmen sind viel billiger zu prüfen. „Leute zahlen dafür" testet eine Landingpage mit echtem Checkout in etwa 20 Stunden. „Der Ablauf ist im Alltag praktikabel" testet ein manueller Concierge-Betrieb mit Tabelle und E-Mail für rund 30 Stunden, bevor eine Zeile Produktcode entsteht. Bauen müssen Sie dann, wenn die offene Frage technischer Natur ist oder wenn die Nutzung selbst die Daten erzeugt, die Sie auswerten wollen.

Die Entscheidungsregel: Kostet der Code mehr als das Dreifache eines nicht-technischen Tests derselben Annahme, testen Sie erst ohne Code.

MVP, Prototyp, Proof of Concept: Drei Zwecke, drei Preisschilder

Der teure Irrtum liegt in der Zeile „Daten". Ein Prototyp mit erfundenen Inhalten beantwortet die Zahlungsbereitschaft nicht, egal wie schön er aussieht. Umgekehrt ist ein MVP der falsche Weg, um eine rein technische Frage zu klären — dafür genügt ein PoC für einen Bruchteil.

Baukasten oder eigener Code

Die Plattform-Route (No-Code, App-Baukasten, Workflow-Tools) senkt den Anfangsaufwand real, verschiebt ihn aber, sobald Sie an die Grenzen des Baukastens stoßen. Eine brauchbare Regel: Solange sich Ihre Kernlogik aus Formular, Liste, Filter, Zahlung und E-Mail zusammensetzen lässt, ist die Plattform-Route sinnvoll. Sobald ein eigenes Datenmodell, eine eigene Berechnung oder eine Integration in ein Fachsystem der Kern des Produkts ist, zahlen Sie den Aufwand später doppelt — einmal für den Bau im Baukasten, einmal für die Migration heraus.

Prüfen Sie vor der Entscheidung drei Dinge auf der Anbieterseite und in den Vertragsbedingungen: Kommen Sie an Ihre Daten als vollständigen Export? Läuft die Abrechnung nach Nutzerzahl oder nach Aufrufen? Wo werden die Daten verarbeitet? Alle drei Antworten ändern sich über die Zeit, prüfen Sie sie am Tag der Entscheidung selbst nach.

Was nach dem Launch monatlich weiterläuft

Der Bauaufwand ist die Einmalzahlung. Diese zehn Zeilen laufen weiter und gehören in dieselbe Tabelle wie die 212 Stunden:

1. Hosting und Compute
2. Datenbank inklusive Backups und deren Aufbewahrung
3. Objektspeicher für Uploads
4. Versand von Transaktions-E-Mails
5. Domain und Zertifikate
6. Fehler-Monitoring und Alerting
7. Gebühren des Zahlungsanbieters, transaktionsabhängig
8. Externe APIs nach Verbrauch, etwa für KI-Funktionen
9. Wartung, Abhängigkeits- und Sicherheitsupdates (in Stunden)
10. Support und Nutzeranfragen (in Stunden)

Für Position 9 kalkuliere ich im ersten Betriebsjahr als Richtwert 8 bis 12 Prozent des Bauaufwands, bei 212 Stunden also etwa 17 bis 25 Stunden. Fragen Sie Ihren Anbieter vor Vertragsschluss nach genau dieser Zahl. Wer sie nicht nennt, hat den Betrieb nicht eingeplant, und Sie zahlen ihn später als Change Request. Welche Kostenblöcke darüber hinaus in eine Web-App-Kalkulation gehören, ist in Web App Entwicklung Kosten Hannover: Faktoren und Vergleich nach Positionen aufgeschlüsselt.

Wer baut: Drei Kostenstrukturen, nicht drei Preisschilder

Ein einzelner Entwickler hat den geringsten Koordinationsaufwand und das höchste Ausfallrisiko — bei 212 Stunden fällt eine Krankheitswoche direkt auf den Termin durch. Eine Agentur puffert Ausfälle ab und bringt Fixkosten mit, die im Angebot mitlaufen; dafür bekommen Sie Projektleitung, die Sie sonst selbst stellen. Inhouse ist erst ab dem zweiten Produkt rechenbar, weil Einarbeitung und Betrieb dauerhaft gebunden bleiben.

Die Frage, die die Struktur entscheidet, ist nicht „was ist günstiger", sondern: Wer hält das Ding am Laufen, wenn in Woche 14 der Zahlungs-Webhook ausfällt und Sie in einem Kundentermin sitzen? Die Abwägung zwischen direktem Kontakt und Agenturstruktur habe ich in Web-App ohne Agentur: Direkter Weg zum Freelancer-Entwickler ausführlicher aufgeschrieben.

Woran Sie früh merken, dass das MVP entgleist

• Ende Woche 3 gibt es keine erreichbare Umgebung. Nicht schön, nicht fertig — nur erreichbar. Fehlt sie, stimmt etwas mit dem Setup oder mit der Priorisierung nicht.
• Der Satz „das machen wir gleich richtig". Er kostet je nach Umfang schnell 30 bis 80 Stunden zusätzlich und beantwortet keine Produktfrage.
• Die Funktionsliste wächst zwischen Angebot und Kickoff um mehr als drei Positionen. Dann ist das Angebot nicht mehr die Grundlage, auf der kalkuliert wurde.
• Es gibt kein Abbruchkriterium. Ohne die vorab notierte Antwort auf „woran erkennen wir, dass die Annahme falsch war" wird aus jedem MVP automatisch Version 1.0 — auf einem Fundament, das nur zum Testen gebaut war.

Häufige Fragen

Was ist ein Minimum Viable Product? Die kleinste lauffähige Version, mit der echte Nutzer eine echte Aufgabe erledigen und dabei eine Annahme über Ihr Geschäft prüfen. Entscheidend ist das Wort *viable*: Der eine Weg, den das MVP abdeckt, muss vollständig funktionieren, inklusive Fehlerfällen. Alles daneben darf fehlen.

Wie hoch sind die Kosten für eine App im Vergleich zur Web-App? Eine zusätzliche native App für iOS und Android schlägt im Referenzmodell mit rund 120 Stunden zu Buche, dazu kommen Store-Konten, Review-Zyklen und eine zweite Release-Kette. Für die Frage, ob jemand zahlt, brauchen Sie das selten. Sinnvoll wird nativ, wenn Sie Sensoren, Hintergrundprozesse oder Push zwingend benötigen.

Was ist eine MVP-Plattform? Damit sind Baukästen und No-Code-Umgebungen gemeint, in denen Sie Oberflächen, Datentabellen und Abläufe zusammenklicken statt zu programmieren. Sie eignen sich, solange die Kernlogik aus Standardbausteinen besteht — und sie verschieben Aufwand nach hinten, sobald sie es nicht mehr tut.

Wie lange dauert ein Web-App-MVP? 212 Stunden Bauaufwand entsprechen bei einer Person mit 25 produktiven Wochenstunden etwa neun Wochen reiner Umsetzung. Rechnen Sie Abstimmung, Feedbackrunden und Ihre eigenen Zuarbeiten dazu, landen Sie realistisch bei elf bis zwölf Wochen ab Kickoff.

Wenn Sie ein konkretes Angebot vor sich haben: Zerlegen Sie es in die 14 Positionen oben und markieren Sie jede, die nicht zugeordnet werden kann. Diese Restmenge ist der Teil, über den Sie reden müssen.