MVP in 8 Wochen planen

Ein Minimum Viable Product (MVP) ist die kleinste Version eines Produkts, mit der echte Nutzer ein echtes Problem lösen können – und die Ihnen zeigt, ob Sie auf dem richtigen Weg sind. Es ist kein Prototyp, keine Demo und keine „Version 1 mit allem“. Gut gemacht dauert ein MVP sechs bis zehn Wochen. Schlecht gemacht dauert es neun Monate und lehrt Sie trotzdem nichts.

Dieser Artikel beschreibt den Acht-Wochen-Plan, den wir für Festpreis-MVPs nutzen – Woche für Woche.

Vor Woche 1: Sind Sie bereit?

Sie sind bereit für ein MVP, wenn Sie drei Fragen in je einem Satz beantworten können:

1. Für wen ist es? Eine konkrete Gruppe, etwa „Servicetechniker mittelständischer Heizungs- und Klimabetriebe“, nicht „alle“.
2. Welches Problem löst es? Zum Beispiel: „Techniker verlieren täglich 30 Minuten mit Papierberichten.“
3. Woran merken Sie, dass es funktioniert? Ein messbares Signal, etwa: „50 % der Techniker reichen Berichte innerhalb von vier Wochen in der App ein.“

Können Sie das noch nicht beantworten, starten Sie besser mit einem kurzen Discovery-Workshop oder einem klickbaren Prototyp.

Woche 1: Discovery und Umfang

Die erste Woche entscheidet über den Erfolg des Projekts.

• Kickoff-Workshop mit den Menschen, denen das Problem gehört, und denen, die das Produkt nutzen werden.
• User Journey für den einen Kernablauf: Was tut ein Nutzer von Anfang bis Ende?
• Funktionsliste, konsequent gekürzt. Fragen Sie bei jeder Funktion: Kann der Nutzer das Kernproblem auch ohne sie lösen? Wenn ja, wartet sie.
• Technischer Check: Schnittstellen, Daten, Hosting, Datenschutzanforderungen.

Ergebnis: ein schriftlicher Umfang von ein bis drei Seiten mit Kernablauf, Funktionsliste (Pflicht / später), Abnahmekriterien und Festpreis.

Fallstrick: „Wenn wir schon dabei sind“-Funktionen. Jede zusätzliche Funktion verzögert das Lernen.

Woche 2: Design und Architektur

• Wireframes für jeden Screen des Kernablaufs, danach visuelles Design auf Basis eines bestehenden UI-Kits, um Zeit zu sparen.
• Klickbarer Prototyp in Figma, getestet mit drei bis fünf echten Nutzern. Was verwirrt, wird geändert.
• Architektur: Datenmodell, API-Vertrag, Authentifizierung, Hosting. Für die meisten MVPs nutzen wir bewährte Bausteine, etwa Flutter oder Next.js im Frontend und NestJS oder FastAPI mit PostgreSQL im Backend.

Ergebnis: freigegebenes Design und ein kurzes Architekturdokument.

Fallstrick: perfektes Design. Das MVP braucht Klarheit, keine Pixelperfektion.

Wochen 3–6: Entwicklung in Sprints

Zwei Sprints à zwei Wochen, jeweils mit einer Demo auf einer Staging-Umgebung, die Sie selbst nutzen können.

• Sprint 1: Authentifizierung, das zentrale Datenmodell und die erste Hälfte des Kernablaufs, durchgängig. Ende Woche 4 können Sie eine echte, schlanke Version durchklicken.
• Sprint 2: der Rest des Kernablaufs, das Nötigste im Admin-Panel, Benachrichtigungen und die erste Schnittstelle.

Jede Änderung wird per Code-Review geprüft, kritische Pfade erhalten automatisierte Tests, und der Build läuft automatisch. Jede Woche bekommen Sie ein kurzes schriftliches Update: Was ist erledigt, was kommt, was ist gefährdet?

Fallstrick: Richtungswechsel mitten im Sprint. Sammeln Sie Feedback und entscheiden Sie im Sprint-Review – nicht an einem Dienstagnachmittag.

Woche 7: Stabilisierung und Pilotvorbereitung

• Fehlerbehebung, Performance-Prüfung und Grundlagen der Barrierefreiheit.
• Sicherheitsprüfung: Berechtigungen, Eingabevalidierung, Secrets, Backups.
• Analytics: die Ereignisse, mit denen Sie Ihr Erfolgssignal messen.
• Rechtliche Grundlagen: Datenschutzerklärung, Impressum, Auftragsverarbeitungsverträge und bei Apps die Datenschutzangaben im Store.
• Onboarding-Material für die ersten Nutzer.

Woche 8: Launch

• Veröffentlichung: im App Store und bei Google Play (planen Sie einige Tage für das Review ein) oder im Web in Produktion.
• Pilotnutzer: Starten Sie mit einer kleinen Gruppe, mit der Sie direkt sprechen können.
• Monitoring: Crash-Reports, Fehlertracking und die ersten Nutzungszahlen.
• Retrospektive: Was haben wir gelernt, was kommt als Nächstes?

Nach Woche 8: messen, lernen, entscheiden

Das MVP hat seine Aufgabe erfüllt, wenn Sie auf Basis echter Nutzung entscheiden können: verstärken, Richtung ändern oder stoppen. Die meisten erfolgreichen Produkte durchlaufen nach dem MVP mehrere Verbesserungsrunden. Dann ist ein dediziertes Team mit Monatsbudget meist sinnvoller als ein weiterer Festpreis.

Zehn Regeln, die MVPs im Zeitplan halten

1. Ein Kernablauf, nicht fünf.
2. Eine entscheidungsbefugte Person auf Kundenseite, die jede Woche verfügbar ist.
3. Schriftlicher Umfang mit Abnahmekriterien.
4. Bewährte Komponenten nutzen; individuell nur dort, wo es Wert schafft.
5. Eine Staging-Umgebung ab Woche 3.
6. Demos statt Statusberichte.
7. Ein Änderungsbudget: Neue Ideen kommen auf eine Liste für nach dem Launch.
8. Schnittstellen in Woche 1 prüfen, nicht in Woche 6.
9. Barrierefreiheit und Datenschutz eingebaut, nicht nachgerüstet.
10. Der Code liegt ab dem ersten Tag in Ihrem Repository.

Was kostet ein MVP?

MVP-Budgets hängen von Plattformen, Funktionen und Schnittstellen ab. Unser Artikel Was kostet App-Entwicklung in Deutschland? erklärt die Kostentreiber, und der App-Rechner zeigt Ihnen schnell Aufwand und Zeitrahmen.

Was ein MVP nicht ist

• Kein Prototyp. Ein Prototyp prüft das Verständnis; ein MVP wird von echten Menschen für echte Arbeit genutzt.
• Keine billige erste Version zum Wegwerfen. Der Code sollte sauber genug sein, um zu wachsen – erfolgreiche MVPs werden selten neu gebaut.
• Nicht „alles, aber fehlerhaft“. Wenige, sauber umgesetzte Funktionen lehren Sie mehr als viele schlecht umgesetzte.
• Kein Marketing-Launch. Ein MVP geht an eine kleine Gruppe, von der Sie lernen können; der große Launch kommt später.

Beispiel: ein MVP für den Außendienst

Für einen Servicebetrieb, der Papierberichte ablösen will, könnte der Kernablauf so aussehen: Der Techniker meldet sich an, sieht die Aufträge des Tages, öffnet einen Auftrag, erfasst Arbeit und Material, macht Fotos, holt die Unterschrift des Kunden ein und sendet ab. Das Büro sieht den Bericht in einem Web-Dashboard und exportiert ihn für die Rechnung. Alles andere – Disposition, Routenplanung, Ersatzteillager, Kundenportal – wartet, bis der Kernablauf funktioniert und die Techniker ihn nutzen.

Rollen auf beiden Seiten

Auf Ihrer Seite: eine Product Ownerin oder ein Product Owner, die bzw. der innerhalb eines Tages entscheiden kann, Zugang zu einer Handvoll echter Nutzer für Tests und jemand, der Daten oder Zugänge zu anzubindenden Systemen bereitstellen kann.

Auf unserer Seite: eine Projektleitung in Deutschland, die Umfang, Zeitplan und Kommunikation verantwortet; ein Designer für die Wochen eins und zwei; zwei bis drei Entwickler für die Umsetzung; und Qualitätssicherung über die gesamte Laufzeit. Alle sind beim Kickoff dabei, damit bei Übergaben nichts verloren geht.

Was nach dem Launch passiert

In den ersten Wochen nach dem Launch zählen zwei Dinge: schnelle Fehlerbehebung und strukturiertes Lernen. Wir sammeln Nutzerfeedback, werten die Analytics-Ereignisse aus und schlagen Ihnen auf dieser Basis die nächsten zwei bis drei Verbesserungen vor – priorisiert nach Wirkung und Aufwand.

Fazit

Acht Wochen reichen für ein echtes MVP, wenn Sie sich auf eine Nutzergruppe, ein Problem und einen Kernablauf konzentrieren und beide Seiten schnell entscheiden. Das Ergebnis ist kein fertiges Produkt. Es ist etwas Besseres: belastbare Erkenntnisse darüber, was als Nächstes gebaut werden sollte.

MVP mit uns planen