Warum wir produktionsqualitative MVPs bauen: keine Prototypen

Viele Playbooks empfehlen: zuerst schnell und günstig bauen, dann «richtig» investieren. Das klingt pragmatisch – führt aber häufig dazu, dass Nutzer die Erfahrung ablehnen, nicht die Idee. Ein Wegwerfprototyp liefert dann vor allem Prototyp-Daten: nützlich für Demos, riskant für eine Go/No-Go-Entscheidung.

Wir bauen MVPs von Tag eins in Produktionsqualität. Das ist keine ästhetische Vorliebe. Es ist für uns der zuverlässigste Weg, Messwerte zu gewinnen, auf die sich eine echte Unternehmensentscheidung stützen lässt – weil Produkt- und Infrastrukturfehler nicht mehr mit dem Marktfeedback vermischt sind. Wie dieser Prozess konkret abläuft, steht in wie wir MVPs in 12 Wochen validieren.

In der Schweiz, wo Kapital knapp ist und jede Entwicklungswoche Geld kostet, ist das keine philosophische Frage, sondern eine finanzielle.

Die falsche Ökonomie des Prototypen-First-Ansatzes

Die Logik hinter Prototype-First geht so: Produktionsqualität kostet Zeit und Geld, also bau erst etwas Günstiges, teste die Idee, und investiere danach in echtes Engineering. In der Praxis liefert der Prototyp oft weniger klare Antworten als erhofft – weil Nutzer auf Bugs und Latenzen mit Abbruch reagieren statt mit ehrlichem Feature-Feedback.

Wann Prototyp-First trotzdem reicht: Wenn du eine einzige, klar isolierte Frage testest (z. B. nur Nachfrage auf einer Landing Page) und bewusst keine Aussage über wiederholte Nutzung oder Zahlungsbereitschaft im echten Produkt treffen willst.

Echte Nutzer reagieren anders auf unzuverlässige Software. Wenn eine App langsam ist, unvorhersehbar abstürzt oder die Authentifizierung jede dritte Session versagt, geben Nutzer kein ehrliches Produktfeedback. Sie brechen ab. Sie kehren nicht zurück – nicht weil das Value Proposition nicht funktioniert, sondern weil die Erfahrung zu frustrierend war, um weiterzumachen. Was dann gemessen wird, ist die Reibung der Oberfläche, nicht die Tragfähigkeit des Geschäftsmodells.

Wer bezahlte Akquise auf einen Prototypen schaltet und schlechte Zahlen sieht, kann nicht entscheiden, ob der Markt das Produkt nicht will oder ob das Produkt schlicht zu kaputt war, um fair beurteilt zu werden. Das ist das Kernproblem: Was gemessen werden soll und das Messinstrument selbst sind miteinander verwoben. Das lässt sich nachträglich nicht mehr trennen.

Was Produktionsqualität konkret bedeutet

Produktionsqualität ist kein vager Standard. Konkret bedeutet das bei uns: Die Applikation läuft auf Azure, nicht auf einem lokalen Rechner oder in einer Development-Sandbox. Es gibt eine CI/CD-Pipeline von Tag eins – jede Code-Änderung durchläuft automatisierte Checks und wird über einen kontrollierten Prozess deployed. Die Authentifizierungsschicht ist real, kein hartcodierter Test-Account. Das Datenbankschema ist für den Dauerbetrieb konzipiert, nicht an einem Nachmittag zusammengehackt. Error Monitoring und Alerting sind eingerichtet, damit das Team weiss, wenn etwas bricht – bevor ein Nutzer es melden muss.

Das ist kein Gold-Plating. Jeder dieser Punkte adressiert eine konkrete Fehlerquelle, die Validierungsdaten beschädigt. Ist die Authentifizierung unzuverlässig, können Nutzer nach ihrer ersten Session nicht verlässlich zurückkehren – die Retention-Daten sind wertlos. Ist das Datenbankschema nicht sauber entworfen, lassen sich die Queries nicht ausführen, die zum Verstehen des Nutzerverhaltens nötig wären. Ohne Error Monitoring fliegt das Team blind durch den datenintensivsten Zeitraum des Unternehmens.

Das technische Fundament bestimmt die Qualität aller Messungen, die darauf aufbauen. Wer es falsch baut, hat Messwerte, denen er nicht vertrauen kann.

Das Datenproblem in der Praxis

Ein konkretes Beispiel: Ein B2B-SaaS-Prototyp ist live, Google-Anzeigen laufen, 200 Trial-Registrierungen kommen rein. Dreissig Prozent der Nutzer kommen nach der ersten Session nie wieder. Die Conversion von Trial zu Paid liegt bei 2 %.

Diese Zahlen müssen jetzt interpretiert werden. Bedeuten 30 % One-Session-Churn, dass das Produkt keinen Mehrwert liefert? Oder ist das Onboarding bei einem Drittel der Nutzer abgebrochen, bevor sie den Wert überhaupt gesehen haben? Ist eine 2-%-Conversion ein Product-Market-Fit-Problem, ein Preis-Problem oder ein Onboarding-Problem? Das ist nicht zu wissen. Und entscheidend: Es lässt sich jetzt nicht mehr herausfinden. Der Moment ist vorbei.

Wäre das Produkt von Anfang an zuverlässig gewesen – echte Auth, echtes Error Handling, ordentliches Monitoring – wäre bekannt, wo Nutzer abgesprungen sind, ob sie auf Fehler gestossen sind und welche Teile des Produkts tatsächlich genutzt wurden. Genau diese Information ist der Sinn der Validierungsübung. Ohne sie wurde Geld ausgegeben, um kaum etwas zu lernen.

Die Rebuild-Kosten, die niemand einrechnet

Das finanzielle Argument für Prototype-First lässt die zweite Hälfte der Rechnung regelmässig weg. Prototyp kostet X, Produktionssystem kostet Y – Prototype-First kostet also X + Y, Production-First nur Y. Stimmt das?

Nicht ganz. In der Praxis bedeutet «den Prototypen in die Produktion überführen» häufig einen vollständigen Rebuild – das ist eine Erfahrungsfaustregel aus vielen Projekten, kein Naturgesetz. Das auf Schnelligkeit ausgelegte Datenbankschema übersteht eine saubere Datenmodellierung nicht. Der Auth-Hack besteht keinen Security-Review. Die monolithische Architektur auf einem einzelnen Server skaliert unter echter Last nicht ohne erhebliches Re-Engineering. Das Team, das den Prototypen schnell und günstig gebaut hat, hat Entscheidungen getroffen, die für einen Prototypen sinnvoll waren – und für ein Produktionssystem nicht. Diese Entscheidungen sitzen tief im Code. Sie herauszuoperieren ist aufwendiger als neu anzufangen.

Die echte Rechnung: Prototyp-Kosten + Rebuild-Kosten (die nahe an Y liegen) + die Kosten der Zeit, in der der Prototyp im Betrieb war, bevor man zugegeben hat, dass er neu gebaut werden muss. Das ist deutlich mehr als von Anfang an richtig zu bauen.

Warum wir keine Prototypen bauen

Unser Geschäftsmodell ist so strukturiert, dass Equity genauso wichtig ist wie Cash-Fees. Wenn wir Equity an einem Unternehmen nehmen, ist das Produkt, das wir bauen, das Produkt, mit dem das Unternehmen in den Markt geht. Eine Wegwerfphase gibt es nicht, weil wir nicht für zwei Entwicklungsrunden bezahlt werden. Wir werden dafür bezahlt, die Idee zu validieren – und dafür brauchen wir belastbare Validierungsdaten.

Das setzt Anreize richtig. Wir wollen in Produktionsqualität bauen, weil wir selbst wissen wollen, ob das Produkt im Markt tatsächlich funktioniert. Nicht ob es in einer Demo-Umgebung läuft. Nicht ob Early Adopters eine holprige Experience tolerieren. Sondern ob das Produkt – auf echter Infrastruktur, über echte kommerzielle Kanäle – genug Wert erzeugt, dass Nutzer dafür zahlen und zurückkommen.

Diese Antwort ist nur möglich, wenn das Produkt zuverlässig genug ist, sie zu liefern. Also bauen wir genau das.

Für wen das relevant ist

Wer kurz vor einer Seed-Finanzierung steht, einen Co-Founder einbringen will oder erhebliches eigenes Kapital einsetzt, für den ist die Qualität der Validierungsdaten keine Engineering-Frage. Es ist eine existenzielle. Eine Go-Entscheidung auf Basis von Prototyp-Daten ist oft eine Go-Entscheidung auf Basis von kaum interpretierbaren Messwerten. Das Risiko sind nicht nur technische Schulden. Das Risiko ist, eine Wette auf die falschen Informationen zu setzen.

Produktionsqualität von Tag eins stellt sicher, dass die gesammelten Daten tatsächlich etwas bedeuten. Das ist der Grund, warum wir so arbeiten – und warum jeder andere Ansatz die entscheidende Wahl härter macht, wenn es darauf ankommt.

Nächster Schritt: Discovery Call

Im Gespräch klären wir konkret:

• welche Hypothese du testen willst und ob sich dafür Produktionsqualität lohnt;
• wie unser 12-Wochen-Ablauf bei deinem Thema aussehen würde;
• ob der Sprint für deine Phase passt, oder ob ein leichterer Einstieg sinnvoller ist.

Discovery Call buchen (kostenlos)