MVP entwickeln lassen: Umfang, Dauer und Kosten realistisch planen

Sie haben eine Produktidee, einen ersten Kundenkreis im Kopf und die Frage: Was kostet das, wie lange dauert es und womit fange ich an? Wer ein MVP entwickeln lassen möchte, bekommt auf dieselbe Beschreibung erfahrungsgemäß sehr weit auseinanderliegende Angebote. Der Grund sind selten die Stundensätze, sondern die Tatsache, dass jeder Anbieter etwas anderes unter dem Umfang versteht. Dieser Beitrag zeigt Ihnen, was ein MVP ist und was nicht, wie Sie den Umfang zuschneiden, mit welcher Dauer und welchen Kosten Sie realistisch rechnen sollten und was Sie vor dem ersten Gespräch klären können.

Was ist ein MVP und was ist es ausdrücklich nicht?

Ein Minimum Viable Product ist die kleinste Version Ihres Produkts, mit der echte Nutzer einen echten Nutzen erhalten und die Ihnen eine belastbare Antwort auf eine geschäftliche Frage liefert. Entscheidend sind zwei Wörter: viable, also tatsächlich benutzbar und im Alltag tragfähig, und minimum, also ohne alles, was für diese eine Antwort nicht gebraucht wird.

Ein MVP ist damit weder eine abgespeckte Vollversion noch ein Wegwerfstück. Es ist Software, die in Produktion läuft, Geld einnehmen kann und auf der weitergebaut wird. In der Praxis werden fünf Begriffe durcheinandergeworfen, die völlig unterschiedliche Aufwände bedeuten:

Diese Unterscheidung ist keine Wortklauberei, sondern der größte Kostenhebel im ganzen Vorhaben. Ein Klickdummy kostet einen Bruchteil eines MVP, beantwortet aber nur Fragen zur Bedienung, nicht zur Zahlungsbereitschaft. Wer wissen will, ob Menschen für etwas zahlen, braucht ein MVP. Wer wissen will, ob eine Oberfläche verständlich ist, braucht zuerst einen Klickdummy.

Wie schneiden Sie den Umfang so zu, dass er finanzierbar bleibt?

Die wirksamste Regel lautet: ein einziger Kernworkflow. Beschreiben Sie in einem Satz, was ein Nutzer mit Ihrer Software von Anfang bis Ende erledigen können muss, damit er einen Nutzen hat. Alles, was nicht auf diesem Weg liegt, gehört nicht in Version eins.

Ein Beispiel: "Ein Pflegedienstleiter legt einen Tourenplan an, weist Mitarbeiter zu und versendet den Plan." Das ist ein Kernworkflow. Urlaubsverwaltung, Abrechnung, Statistiken, Mandantenfähigkeit und ein Kundenportal liegen nicht darauf, so wichtig sie später sein mögen.

Für die Priorisierung hat sich MoSCoW bewährt, wobei im MVP vor allem die letzte Kategorie zählt:

• Must: Ohne diese Funktion ist der Kernworkflow nicht durchführbar. Meist sind das zwischen fünf und fünfzehn Funktionen, nicht mehr.
• Should: Deutlich wertvoll, aber der Nutzer kommt vorerst ohne aus oder behilft sich anders.
• Could: Wünschenswert, wird in Version zwei bewertet.
• Won't: Ausdrücklich nicht Teil dieses Projekts, schriftlich festgehalten. Diese Liste ist die wichtigste von allen, weil sie Diskussionen im laufenden Projekt beendet, bevor sie beginnen.

Führen Sie die Won't-Liste nicht im Kopf, sondern im Dokument. Wie Sie Anforderungen so formulieren, dass sie prüfbar und kalkulierbar sind, zeigt unsere Anleitung samt Lastenheft-Vorlage. Für ein MVP genügen davon meist vier bis sechs Seiten.

Was können Sie manuell erledigen, statt es zu bauen?

Der zweitgrößte Kostenhebel besteht darin, Prozesse in Version eins von Hand zu erledigen, die später automatisiert werden. Jede Funktion, die Sie im ersten Durchlauf nicht bauen, spart nicht nur Entwicklungszeit, sondern auch Test-, Betriebs- und Wartungsaufwand.

Der wichtigste Nebeneffekt ist nicht die Ersparnis, sondern der Erkenntnisgewinn: Wer den Prozess drei Monate lang von Hand erledigt, kennt danach die echten Sonderfälle und automatisiert das Richtige statt das Vermutete.

Wie lange dauert die Entwicklung eines MVP?

Für ein sauber zugeschnittenes Web-MVP sollten Sie mit 8 bis 16 Wochen kalendarischer Laufzeit rechnen, gerechnet vom Start des Discovery-Workshops bis zum Launch mit echten Nutzern. Der Löwenanteil entfällt auf die Entwicklung, die drei anderen Phasen entscheiden aber darüber, ob diese Entwicklungszeit produktiv genutzt wird.

Laufzeit ist nicht gleich Aufwand: Zwölf Wochen Laufzeit bedeuten keine zwölf Wochen Vollauslastung eines Teams. Sie bedeuten aber, dass Sie als Auftraggeber verfügbar sein müssen, für Rückfragen innerhalb von ein bis zwei Werktagen, für die Sprint-Abnahmen und für Beispieldaten und Testnutzer. Die häufigste Ursache für Verzögerungen ist nicht die Technik, sondern eine Entscheidung, auf die zwei Wochen gewartet wird.

Was kostet es, ein MVP entwickeln zu lassen?

Für ein Web-MVP mit Login, einem sauber umgesetzten Kernprozess und einem Adminbereich liegt der übliche Rahmen im deutschen Markt bei 20.000 bis 60.000 Euro. Klickdummies bewegen sich je nach Anzahl der Bildschirme im niedrigen vierstelligen bis niedrigen fünfstelligen Bereich. Kommen mobile Apps, mehrere Rollen oder Schnittstellen zu Fremdsystemen hinzu, liegt der Rahmen höher.

Diese Spannen sind keine Preisliste, sondern Erfahrungswerte. Was Ihr Vorhaben innerhalb der Spanne nach oben oder unten verschiebt, sind vor allem fünf Treiber:

• Anzahl der Rollen: Jede zusätzliche Rolle bringt eigene Ansichten, eigene Berechtigungen und eigene Testfälle mit. Zwei Rollen sind Standard, fünf Rollen verdoppeln den Oberflächenaufwand schnell.
• Integrationen: Anbindungen an DATEV, ein ERP oder einen Zahlungsanbieter sind selten schwierig, aber fast immer aufwendiger als erwartet, weil Testzugänge, Sonderfälle und Fehlerbehandlung dazugehören. Fehlt eine dokumentierte Schnittstelle, wird es teuer.
• Mobile: Eine für das Smartphone optimierte Weboberfläche ist im MVP fast immer die richtige Wahl. Eine native App in zwei Stores bedeutet zusätzliche Entwicklung, Store-Prozesse und eine zweite Testmatrix.
• Datenschutzanforderungen: Werden Gesundheits-, Beschäftigten- oder Finanzdaten verarbeitet, kommen Löschkonzept, Protokollierung, differenzierte Zugriffsrechte und ein sauber dokumentierter Auftragsverarbeitungsvertrag hinzu.
• Qualität der Vorarbeit: Wer mit einem klaren Kernworkflow und entschiedenen Fragen ins Projekt geht, liegt regelmäßig am unteren Rand der Spanne. Wer während der Entwicklung noch grundsätzliche Entscheidungen trifft, am oberen.

Eine erste eigene Einschätzung können Sie über unseren Kostenrechner für individuelle Software gewinnen. Unsere Konditionen und Tagessätze finden Sie auf der Seite Preise.

Was gehört neben der Entwicklung ins MVP-Budget?

Ein MVP ist nach dem Launch nicht fertig, sondern in Betrieb. Wer nur die Entwicklungskosten einplant, hat das Projekt zu knapp kalkuliert und steht drei Monate später vor unangenehmen Überraschungen. Rechnen Sie diese Positionen von Anfang an mit:

• Hosting und Infrastruktur: Bei überschaubarer Nutzerzahl liegen die monatlichen Kosten meist im niedrigen zweistelligen bis niedrigen dreistelligen Bereich, inklusive Datenbank, Backups und Testumgebung.
• Monitoring und Fehlerverfolgung: Sie müssen wissen, wenn die Anwendung nicht erreichbar ist oder Nutzer auf Fehler laufen, und zwar bevor der erste Kunde anruft.
• Datenschutz: Auftragsverarbeitungsvertrag, Verzeichnis von Verarbeitungstätigkeiten, Datenschutzerklärung, Lösch- und Aufbewahrungskonzept. Das ist bei einem MVP überschaubar, aber es ist nicht optional.
• Wartung nach dem Launch: Sicherheitsupdates von Framework und Bibliotheken, Aktualisierungen der Laufzeitumgebung, kleine Korrekturen. Was dazugehört und wie sich der Aufwand bemisst, erklärt unser Leitfaden zur Softwarewartung.
• Weiterentwicklung: Ein MVP, das funktioniert, erzeugt sofort Wünsche. Planen Sie Budget für die ersten drei bis sechs Monate nach dem Launch ein, sonst steht das Produkt genau dann still, wenn es Zugkraft entwickelt.

Was der laufende Betrieb einer eigenen SaaS-Anwendung im Alltag konkret bedeutet, von Updates über Support bis zu Ausfallszenarien, beschreiben wir ausführlich im Beitrag zum SaaS-Betrieb nach dem Launch.

Welches Vertragsmodell passt zu einem MVP?

Bewährt hat sich eine Kombination: Discovery zum Festpreis, anschließend Entwicklung in Sprints nach Aufwand mit vereinbartem Budgetdeckel. So haben Sie am Anfang volle Kostensicherheit für den Schritt, der über den Rest entscheidet, und behalten danach die Flexibilität, die ein MVP naturgemäß braucht.

Ein reiner Festpreis über das gesamte MVP verlangt eine vollständige, eingefrorene Spezifikation. Genau die widerspricht dem Zweck eines MVP, denn Sie lernen in Sprint drei, dass der Ablauf anders sein muss als gedacht. Die Folge sind entweder Änderungsanträge für jede Kleinigkeit oder ein deutlicher Risikoaufschlag im Preis. Die vollständige Abwägung finden Sie im Beitrag Festpreis oder Time and Material.

Achten Sie unabhängig vom Modell auf drei Punkte im Vertrag: Die Nutzungsrechte am erstellten Code liegen vollständig bei Ihnen, der Code liegt in einem Repository, auf das Sie jederzeit Zugriff haben, und die Kündigung ist zwischen den Sprints ohne lange Frist möglich. Wer diese drei Punkte hat, kann den Dienstleister wechseln, ohne das Produkt zu verlieren.

Welche Fehler kosten am meisten Zeit und Geld?

Die teuren Fehler passieren nicht in der Entwicklung, sondern in den Entscheidungen davor. Vier Muster tauchen in gescheiterten MVP-Projekten immer wieder auf:

1. Zu viele Funktionen in Version eins. Aus Sorge, ein Kunde könnte etwas vermissen, wächst der Umfang, bis das Budget aufgebraucht ist, bevor irgendein Nutzer die Software gesehen hat. Gegenmittel: die Won't-Liste, schriftlich und mit Datum.
2. Kein Messplan. Wenn vorher nicht feststeht, woran Sie Erfolg erkennen, wird nach dem Launch endlos diskutiert statt entschieden. Legen Sie zwei bis drei Zahlen fest, etwa "20 aktive Nutzer nach acht Wochen" oder "fünf zahlende Kunden im ersten Quartal", und richten Sie die passende Auswertung mit ein.
3. Keine echten Nutzer vor dem Launch. Ein Klickdummy, den acht potenzielle Kunden durchklicken, deckt Missverständnisse auf, die sonst erst nach der Umsetzung sichtbar werden.
4. Technologieentscheidung nach Mode. Ein MVP braucht keine Microservices, keine Kubernetes-Cluster und kein exotisches Framework, für das es regional drei Entwickler gibt. Es braucht eine bewährte, gut wartbare Basis, die in zwei Jahren noch jemand weiterentwickeln kann.

Welche Ursachen darüber hinaus dazu führen, dass Softwareprojekte aus dem Ruder laufen, und woran Sie die Warnzeichen früh erkennen, haben wir im Beitrag zu den Ursachen gescheiterter Softwareprojekte aufgearbeitet.

Was sollten Sie vor dem Erstgespräch klären?

Fünf Punkte genügen, um aus einem unverbindlichen Gespräch eine belastbare Einschätzung zu machen. Sie brauchen dafür kein Dokument, Stichpunkte reichen:

• Zielgruppe: Wer soll die Software nutzen, in welcher Rolle? "KMU" ist keine Zielgruppe, "Disponenten in Pflegediensten mit 15 bis 60 Mitarbeitern" ist eine.
• Kernproblem: Was tun diese Menschen heute stattdessen, und warum ist das schlecht? Wenn die Antwort "Excel" lautet, ist das ein gutes Zeichen, denn dann existiert der Prozess bereits.
• Der eine Workflow: Was muss ein Nutzer von Anfang bis Ende erledigen können, damit er einen Nutzen hat? Ein Satz.
• Erfolgskriterium: Woran erkennen Sie in drei Monaten, dass es sich lohnt, weiterzumachen? Eine Zahl mit einem Datum.
• Budgetrahmen: Welche Größenordnung ist finanzierbar? Ein genannter Rahmen ist keine Einladung, ihn auszuschöpfen, sondern die Grundlage für einen sinnvollen Zuschnitt. Ohne Rahmen kalkuliert jeder Anbieter etwas anderes.

Wenn Sie darüber hinaus grundsätzlich abwägen, ob aus Ihrer Idee ein eigenes Produkt werden soll, lohnt der Blick in unseren Beitrag dazu, wie KMU eine eigene SaaS-Software entwickeln.

Wie Ucar Solutions MVPs baut

Wir setzen MVPs mit bewährten Technologien um: PHP mit Symfony oder Laravel im Backend, TypeScript im Frontend, gehostet in Rechenzentren in Deutschland. Der Code liegt von Tag eins im Repository unseres Kunden. Sie sehen jederzeit, was entstanden ist, und sind nicht davon abhängig, dass wir das Projekt fortführen.

Wir starten mit einem Discovery-Block zum Festpreis, in dem Kernworkflow, Umfang und Aufwand entstehen. Danach arbeiten wir in zweiwöchigen Sprints, nach jedem Sprint gibt es eine lauffähige Version auf einer Testumgebung. Unsere Tagessätze und Konditionen stehen offen auf der Seite Preise, damit Sie vor dem ersten Gespräch wissen, worauf Sie sich einlassen.

Ein Unterschied zu reinen Projektdienstleistern: Wir betreiben eigene SaaS-Produkte und kennen deshalb auch das, was nach dem Launch kommt, von Updates über Supportanfragen bis zu der Frage, welche Auswertung wirklich zeigt, ob ein Produkt angenommen wird.

Häufige Fragen zum MVP

Was kostet ein MVP mindestens?
Unterhalb von etwa 20.000 Euro wird es für ein produktiv nutzbares Web-MVP eng, weil Betrieb, Datenschutz und Tests unabhängig vom Funktionsumfang anfallen. Liegt Ihr Budget darunter, ist ein Klickdummy plus manueller Prozess oft der bessere erste Schritt: Sie prüfen die Nachfrage, ohne die Software vorher zu bauen.

Kann ich mit einem MVP schon Geld verdienen?
Ja, und genau darum geht es. Ein MVP ist produktive Software, keine Demo. Die Rechnungsstellung darf manuell laufen, das ändert nichts daran, dass echte Kunden echtes Geld zahlen. Der Nachweis der Zahlungsbereitschaft ist meist die wertvollste Erkenntnis des Projekts.

Was passiert mit dem Code, wenn sich die Idee als Fehlschlag herausstellt?
Der Code gehört Ihnen und liegt in Ihrem Repository. Häufiger als ein vollständiger Fehlschlag ist die Erkenntnis, dass die Zielgruppe eine andere ist als gedacht. Dann bleibt der Großteil der Basis nutzbar, angepasst werden Oberfläche und Fachlogik.

Sollten wir das MVP intern bauen statt zu beauftragen?
Wenn Sie ein eingespieltes Entwicklungsteam mit freier Kapazität haben, gerne. In den meisten KMU bindet ein internes MVP jedoch genau die Personen, die das Tagesgeschäft tragen, und dauert dadurch das Zwei- bis Dreifache. Ein häufiger Mittelweg ist die externe Umsetzung des MVP mit anschließender Übergabe an einen eigenen Entwickler, den Sie parallel aufbauen.

Wie geht es nach dem Launch weiter?
Sie beobachten Ihre Erfolgszahlen, sammeln Rückmeldungen der ersten Nutzer und entscheiden nach sechs bis zwölf Wochen, welche Funktionen aus der Should-Liste als nächstes kommen. Parallel läuft die Wartung mit Sicherheitsupdates. Meist folgt eine zweite Ausbaustufe, in der die manuellen Schritte automatisiert werden.

Fazit

Ein MVP ist kein billigeres Softwareprojekt, sondern ein kleineres mit klarem Zweck: eine geschäftliche Frage mit echten Nutzern zu beantworten. Wer den Umfang auf einen Kernworkflow begrenzt, Randfunktionen in eine schriftliche Won't-Liste schiebt und einzelne Schritte zunächst manuell erledigt, kommt regelmäßig mit 20.000 bis 60.000 Euro und 8 bis 16 Wochen aus. Wer den Umfang nicht begrenzt, zahlt ein Vielfaches und erfährt trotzdem später, ob die Idee trägt.

Formulieren Sie Ihren Kernworkflow in einem Satz, notieren Sie Ihr Erfolgskriterium als Zahl mit Datum und bringen Sie beides mit ins Gespräch. Wir sagen Ihnen konkret, was daraus in welcher Zeit und in welcher Größenordnung machbar ist. Erreichbar sind wir über das Kontaktformular oder direkt über die Terminbuchung zum Erstgespräch.