Wie lange dauert die Entwicklung eines MVP? Echte Zeitpläne nach Produkttyp

Die Komplexität sagt den Zeitplan eines MVP am besten voraus. Wir nutzen bei der Kalkulation drei Stufen.

Dieselben Stufen bestimmen das Budget. Unsere Übersicht dazu, was ein SaaS-MVP kostet, nennt die Preisspanne für jede Stufe.

Produkttypen lassen sich recht verlässlich diesen Stufen zuordnen. Die Tabelle zeigt, wo verbreitete MVPs meist landen; Ihr Produkt kann je nach Details eine Stufe höher oder niedriger liegen.

Eine Telegram Mini App landet meist in der einfachen oder mittleren Stufe. Sie öffnet sich in Telegram, deshalb entfällt die Einreichung im App Store, und das Konto kommt direkt aus Telegram.

Jedes MVP durchläuft dieselben Phasen, auch wenn sie sich stärker überlappen, als eine einfache Liste vermuten lässt.

• Kalkulation. Aus Ihrem Briefing wird ein Angebot mit Umfang, Zeitplan und Preis. Bei Sakura gehen die meisten Angebote innerhalb von 2–3 Werktagen nach einem vollständigen Briefing raus.
• Design. Erst die Nutzerabläufe, dann Screens aus einem wiederverwendbaren Komponentensystem, dann ein klickbarer Prototyp.
• Entwicklung. Frontend, Backend und Integrationen, mit einem funktionierenden Build, den Sie jede Woche durchklicken können.
• Tests. Jeder Ablauf auf den vereinbarten Browsern und Geräten, dazu Performance und grundlegende Barrierefreiheit.
• Launch. Deployment, Analytics, Einreichung im App Store bei einer mobilen App und die ersten Fehlerbehebungen, sobald echte Nutzer kommen.

Design und Entwicklung überlappen bewusst. Sobald die ersten Abläufe freigegeben sind, beginnt deren Entwicklung, während die übrigen noch gestaltet werden.

Das Design beginnt meist zuerst und endet vor der Entwicklung, aber beides sollte nicht strikt nacheinander laufen. Übergibt das Design eine fertige Datei und verabschiedet sich, zeigt sich in der Entwicklung oft, dass manche Screens teuer umzusetzen sind, und Wochen fließen in Nacharbeit.

Die Lösung: in denselben Komponenten gestalten, die die Entwickler bauen werden. Dann ist ein freigegebener Screen schon fast gebaut, und Fragen werden geklärt, solange es günstig ist.

Ein Beispiel: AutoIntel, ein B2B-Werkzeug für den deutschen Gebrauchtwagenmarkt, begann mit Produktdesign und einem interaktiven Prototyp auf Beispielanzeigen. Der Kunde hat sein Team durch den Prototyp geführt und festgelegt, welche Felder und Filter zählen, bevor die Datenstrecke kalkuliert wurde. Diese Reihenfolge hält den teuersten Teil der Entwicklung auf das fokussiert, was die Oberfläche tatsächlich braucht.

Sie planen einen Launch-Termin? Schicken Sie uns ein kurzes Briefing, und wir sagen Ihnen, in welche Stufe Ihr Produkt fällt und wie ein realistischer Zeitplan aussieht.

Manche Funktionen wirken im Briefing klein und kosten in der Entwicklung Wochen. Auf diese sollten Sie achten:

• Integrationen. Zahlungen, Login-Anbieter, CRMs und externe APIs bringen jeweils Einrichtung, Fehlerbehandlung und Tests mit sich.
• Rollen und Berechtigungen. Jede zusätzliche Rolle vervielfacht die Zustände, die jeder Screen abdecken muss.
• Eine native App. Sie bedeutet ein zweites Frontend und eine Prüfung im App Store. Das App Review von Apple bearbeitet mindestens 50% der Einreichungen in weniger als 24 Stunden und 90% in weniger als 48 Stunden, aber eine Ablehnung setzt die Uhr zurück.
• Mehrere Sprachen. Jeder Text, jede Fehlermeldung und jeder Hilfetext muss in jeder Sprache existieren, und das Layout muss die längste Fassung aufnehmen.
• Späte Inhalte. Texte, Preise, Rechtstexte und echte Daten, die in der letzten Woche kommen, blockieren die Tests.
• Langsame Entscheidungen. Eine Frage, die eine Woche auf eine Antwort wartet, verzögert alles, was darauf aufbaut.

Sie verkürzen den Zeitplan eines MVP, indem Sie weniger tun, nicht indem Sie es schlechter tun. Diese Entscheidungen sparen die meiste Zeit:

• Ganze Abläufe streichen, nicht den Feinschliff. Verschieben Sie Nebenabläufe in ein späteres Release, statt jeden Ablauf halb zu bauen.
• Zuerst im Web starten. Eine responsive Web-App erreicht Nutzer auf Smartphone und Desktop und braucht keine Store-Prüfung.
• Bewährte Dienste nutzen. Gehosteter Checkout, vorhandene Login-Anbieter und E-Mail-Dienste sind schneller und sicherer als Eigenbauten.
• Schnell entscheiden. Benennen Sie eine Person, die Designs freigibt und Fragen innerhalb eines Tages beantwortet.
• Früh mit wenigen Nutzern testen. Die Forschung von Jakob Nielsen hat gezeigt, dass Tests mit 5 Nutzern die meisten Usability-Probleme aufdecken, deshalb schlagen mehrere kleine Runden eine große.

CarPixly, ein KI-Fotostudio für Autoinserate, hat die Android-Version als APK über die eigene Download-Seite veröffentlicht, während der iOS-Build noch unterwegs war. Dort zu starten, wo es geht, und Plattformen später zu ergänzen, ist oft der schnellste Weg zu echten Nutzern.

Die ersten Wochen laufen schneller, wenn vor dem Kickoff einige Dinge bereitliegen. Keines davon erfordert technisches Wissen:

• Eine kurze Liste der zentralen Abläufe. Die ein bis drei Aufgaben, die Nutzer zum Launch erledigen können müssen, in einfachen Worten.
• Eine Person, die entscheidet. Jemand, der Designs freigibt und Fragen innerhalb eines Tages beantwortet.
• Zugang zu bestehenden Accounts. Domain, Hosting, Analytics, Zahlungsanbieter und alle APIs, die Sie bereits nutzen.
• Echte Inhalte oder ein Termin dafür. Texte, Preise, Rechtsseiten und Beispieldaten, die das Produkt zeigen wird.
• Ihre Vorgabe für den Launch. Das Ereignis, der Investorentermin oder die Saison, die das Datum wichtig macht.

Liegt das bereit, dauert die Kalkulation Tage statt Wochen, und das Design kann mit echten Inhalten statt mit Platzhaltern beginnen.

Zeitpläne verschieben sich selten, weil Entwickler langsam tippen. Sie verschieben sich wegen Entscheidungen, die rund um die Entwicklung getroffen oder nicht getroffen werden:

• Der Umfang wächst mitten im Projekt ohne schriftlichen Änderungsprozess.
• Feedbackrunden dauern eine Woche statt eines Tages.
• Niemand hat aufgeschrieben, was „fertig“ bedeutet, deshalb werden die letzten Wochen zur Debatte.
• Integrationen stehen als eine Zeile im Umfang statt mit ihren echten Sonderfällen.

Ein fester Umfang mit Änderungsprozess hält das meiste davon unter Kontrolle. Wie das geht, erklären wir in Festpreis oder Stundenabrechnung.

Der Launch startet eine zweite Uhr, er stoppt nicht die erste. Die ersten Wochen nach dem Release sind meist die arbeitsreichsten des ganzen Projekts.

Echte Nutzer finden Fehler, die die Tests übersehen haben, wünschen sich kleine Änderungen und nutzen das Produkt auf Arten, die niemand geplant hat. Planen Sie direkt nach dem Launch eine kurze Phase für Fehlerbehebungen und schnelle Verbesserungen ein, vor allen neuen Funktionen.

Danach geht die Arbeit in einen gleichmäßigen Rhythmus über: ein monatlicher Plan mit Verbesserungen auf Basis der echten Nutzung. Zu jedem Sakura-Projekt gehört ein festgelegtes Gewährleistungsfenster für Fehlerbehebungen, und die laufende Arbeit kann über einen Monatsplan weitergehen oder an Ihr eigenes Team übergehen.

So kurz wie möglich, solange es Ihre wichtigste Annahme noch testet. Der Sinn eines MVP ist nach den Worten von Lean Startup, „so schnell wie möglich mit dem Lernen zu beginnen“.

Reicht Ihr Plan deutlich über die komplexe Stufe hinaus, fragen Sie sich, was Sie lernen wollen und ob ein kleineres Produkt Ihnen dasselbe zeigen könnte. Oft beantwortet ein einzelner Ablauf, der früher startet, die wichtigste Frage.

Wenn Sie Ihres planen möchten, erzählen Sie uns von Ihrem Produkt. Sie bekommen ein Angebot mit Umfang, Zeitplan und Festpreis und jede Woche einen Build, an dem Sie sehen, wie das Produkt entsteht.