Prototyp, MVP oder fertige Software? Ein Entscheidungsleitfaden
Wenn eine digitale Produktidee noch offen ist, muss nicht sofort die vollständige Anwendung gebaut werden. Entscheidend ist, welche Unsicherheit der nächste Entwicklungsschritt tatsächlich auflösen soll.
Prototyp: einen Nutzerweg verständlich machen
Ein Prototyp zeigt, wie ein Ablauf aussehen oder sich anfühlen könnte. Er eignet sich, um Navigation, Begriffe, Reihenfolge und erste Rückmeldungen zu prüfen. Ein klickbarer Prototyp kann echte Interaktionen simulieren, ohne bereits ein belastbares Backend oder produktive Daten zu enthalten.
Ein Prototyp beantwortet vor allem: Verstehen Nutzer den Ablauf? Fehlt ein wichtiger Schritt? Ist die Lösung für die Aufgabe plausibel? Er beweist nicht, dass Architektur, Sicherheit, Skalierung oder Wirtschaftlichkeit bereits funktionieren.
MVP: die Kernannahme in realer Nutzung prüfen
Ein Minimum Viable Product ist mehr als ein klickbares Modell. Es ist eine begrenzte, nutzbare Produktversion, mit der eine zentrale Annahme unter klaren Bedingungen geprüft wird. Dafür braucht es mindestens einen definierten Nutzerkreis, einen eingegrenzten Funktionsumfang, passende Daten und Verantwortliche für Support und Fehler.
Auch ein MVP muss seiner Nutzung angemessene Zugriffskontrollen, Datensicherung und einen Umgang mit Fehlern haben. Sobald Nutzer sich auf das System verlassen oder echte personenbezogene Daten verarbeitet werden, steigen die Anforderungen über einen Demonstrator hinaus.
Produktionssoftware: verlässlich im Betrieb sein
Produktionssoftware muss nicht jede denkbare Funktion enthalten. Sie muss den vereinbarten Ablauf zuverlässig unterstützen und betreibbar sein. Dazu gehören je nach Anwendung Authentifizierung und Berechtigungen, Protokollierung, Monitoring, Sicherungen, Wiederherstellung, Dokumentation, Wartung und ein klarer Verantwortlicher.
Welche Kontrollen angemessen sind, hängt von den Daten, Nutzern, Ausfallfolgen und externen Systemen ab. Ein Prototyp, der im Workshop funktioniert, ist deshalb nicht automatisch für den täglichen Betrieb bereit.
Welche Stufe passt jetzt?
- Die Nutzer und der Ablauf sind noch unklar → erst Problemgespräche und ein Prototyp.
- Die Bedienlogik ist klar, aber die Nutzungshypothese offen → ein begrenzter Test mit klaren Erfolgskriterien.
- Der Ablauf ist validiert und Nutzer sollen sich darauf verlassen → Anforderungen an Produktivbetrieb, Daten, Sicherheit und Wartung planen.
- Die bestehende Software deckt den Kern schon ab → lieber integrieren oder konfigurieren statt neu bauen.
Vor dem Übergang zur nächsten Stufe
Halte fest, welche Beobachtung den nächsten Schritt rechtfertigt und welche Frage noch offen ist. Definiere den zentralen Nutzerweg, die Fälle außerhalb des Standardablaufs, benötigte Daten und Systemzugriffe. Kläre außerdem, wer die Lösung nach dem Start betreibt, Fehler entgegennimmt und Änderungen verantwortet.
Wenn eine Annahme nicht bestätigt wird, ist ein kleiner verworfener Prototyp oft eine bessere Erkenntnis als ein größeres, noch nicht validiertes System.
Was ein Prototyp-Sprint liefern sollte
Ein klar begrenzter Sprint sollte einen konkreten Nutzerweg, einen testbaren Prototyp, eine Feedbackrunde und eine schriftliche Empfehlung für den nächsten Schritt enthalten. Produktionsintegrationen und Backend-Entwicklung müssen separat eingeplant werden, sobald sie Teil des Ziels sind.
Mauna Labs bietet einen fünftägigen Prototyp-Sprint mit vereinbartem Umfang, einer Feedbackrunde und einer Empfehlung an. Das ist ein klar abgegrenzter Prototyp – keine Zusage, dass ein Produkt nach fünf Tagen produktionsbereit ist.