Warum wir MVPs in Produktionsqualität bauen

Viele Playbooks sagen: zuerst schnell und günstig bauen, danach «richtig» investieren. Das klingt pragmatisch. In der Praxis brechen Nutzer wegen der Erfahrung ab, bevor sie die Idee überhaupt geprüft haben. Ein Wegwerfprototyp liefert vor allem Prototyp-Daten. Gut für Demos, riskant für eine Go/No-Go-Entscheidung.

Wir bauen MVPs von Tag eins in Produktionsqualität. So kommen Messwerte zustande, auf die sich eine Firmenentscheidung stützen lässt, weil Produktfehler und Infrastrukturfehler nicht mehr im Marktfeedback stecken. Wie der Ablauf aussieht: wie wir MVPs in 12 Wochen validieren.

In der Schweiz ist Kapital knapp, und jede Entwicklungswoche kostet. Die Frage ist finanziell.

Die Rechnung hinter Prototype-First

Die Logik: Produktionsqualität kostet Zeit und Geld, also zuerst etwas Günstiges, die Idee testen, danach richtig bauen. In der Praxis gibt der Prototyp oft weniger klare Antworten als erhofft. Nutzer brechen wegen Bugs und Latenzen ab, bevor sie zum Feature-Feedback kommen.

Wann Prototype-First trotzdem reicht. Du testest eine einzige, klar isolierte Frage, zum Beispiel nur Nachfrage auf einer Landingpage, und du willst bewusst keine Aussage über wiederholte Nutzung oder Zahlungsbereitschaft im echten Produkt.

Echte Nutzer reagieren anders auf unzuverlässige Software. Ist eine App langsam, stürzt sie unvorhersehbar ab oder versagt die Anmeldung jede dritte Session, bekommst du kein ehrliches Produktfeedback. Sie brechen ab. Sie kommen nicht zurück, weil die Erfahrung zu frustrierend war. Was du misst, ist die Reibung der Oberfläche. Die Tragfähigkeit des Geschäftsmodells siehst du daran nicht.

Schaltest du bezahlte Akquise auf einen Prototyp und siehst schlechte Zahlen, kannst du nicht entscheiden, ob der Markt das Produkt nicht will oder ob das Produkt zu kaputt war, um fair beurteilt zu werden. Das, was du messen willst, und das Messinstrument hängen ineinander. Nachträglich trennst du das nicht mehr.

Was Produktionsqualität bei uns heisst

Konkret: die Applikation läuft auf Azure. Ein lokaler Rechner oder eine Development-Sandbox zählt hier nicht als Betrieb. Es gibt eine CI/CD-Pipeline ab Tag eins. Jede Code-Änderung durchläuft automatisierte Checks und geht über einen kontrollierten Prozess live. Die Authentifizierung ist echt, mit einem richtigen Konto, nicht mit einem hartcodierten Test-Login. Das Datenbankschema ist für den Dauerbetrieb gebaut. Ein Schema von einem Nachmittag hält das nicht aus. Error Monitoring und Alerting sind eingerichtet, damit das Team es merkt, wenn etwas bricht, bevor ein Nutzer schreiben muss.

Jeder Punkt trifft eine Fehlerquelle, die Validierungsdaten beschädigt. Ist die Anmeldung unzuverlässig, kommen Nutzer nach der ersten Session nicht verlässlich zurück, und die Wiederkehr-Zahlen sind wertlos. Ist das Datenbankschema unsauber, laufen die Abfragen nicht, mit denen du das Verhalten verstehen würdest. Ohne Error Monitoring fliegt das Team blind durch die datenintensivste Zeit der Firma.

Das technische Fundament bestimmt die Qualität aller Messungen, die darauf sitzen. Baust du es falsch, hast du Zahlen, denen du nicht trauen kannst.

Ein Rechenbeispiel

Kein Kundenfall, nur die Zahlen, wie sie in so einer Lage aussehen. 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 Prozent.

Jetzt die Interpretation. Heisst 30 Prozent Absprung nach einer Session, dass das Produkt keinen Nutzen liefert? Oder ist das Onboarding bei einem Drittel abgebrochen, bevor sie den Nutzen gesehen haben? Ist 2 Prozent Conversion ein Product-Market-Fit-Problem, ein Preisproblem oder ein Onboarding-Problem? Das weisst du nicht. Und du findest es an diesem Datensatz nicht mehr heraus. Der Moment ist vorbei.

Wäre das Produkt von Anfang an zuverlässig gewesen, echte Anmeldung, echtes Error Handling, ordentliches Monitoring, wüsstest du, wo Nutzer abgesprungen sind, ob sie auf Fehler gestossen sind und welche Teile genutzt wurden. Diese Information ist der Sinn der Validierung. Ohne sie hast du Geld ausgegeben und kaum etwas gelernt.

Die Neuaufbau-Kosten, die in der Rechnung fehlen

Das finanzielle Argument für Prototype-First lässt die zweite Hälfte oft weg. Prototyp kostet X, Produktionssystem kostet Y, Prototype-First kostet also X plus Y, Production-First nur Y. Stimmt das?

Nicht ganz. «Den Prototypen in die Produktion überführen» heisst in der Praxis häufig einen vollständigen Neuaufbau. Das ist eine Faustregel aus vielen Projekten, kein Naturgesetz. Das Datenbankschema, das auf Tempo ausgelegt war, ü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 Prototyp schnell und günstig gebaut hat, hat Entscheidungen getroffen, die für einen Prototyp sinnvoll waren und für ein Produktionssystem nicht. Die Entscheidungen sitzen tief im Code. Sie herauszulösen ist aufwendiger als neu anzufangen.

Die echte Rechnung: Prototyp-Kosten plus Neuaufbau (nahe an Y) plus die Zeit, in der der Prototyp im Betrieb war, bis klar war, dass er neu gebaut werden muss. Das ist deutlich mehr, als von Anfang an richtig zu bauen.

Warum wir keine Prototypen bauen

Unser Modell hängt an Equity genauso wie an Cash-Fees. Nehmen wir Anteile an einer Firma, ist das Produkt, das wir bauen, das Produkt, mit dem die Firma 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 prüfen. Dafür brauchen wir belastbare Daten.

Die Anreize sitzen so, dass wir selbst wissen wollen, ob das Produkt im Markt funktioniert. Ob es in einer Demo läuft, reicht nicht. Ob frühe Nutzer eine holprige Oberfläche aushalten, auch nicht. Ob das Produkt auf echter Infrastruktur, über echte kommerzielle Kanäle, genug Wert erzeugt, dass Nutzer zahlen und zurückkommen: das ist die Frage.

Diese Antwort bekommst du nur, wenn das Produkt zuverlässig genug ist, sie zu liefern. Also bauen wir das.

Für wen das zählt

Stehst du kurz vor einer Seed-Finanzierung, willst du einen Co-Founder reinholen oder setzt du erhebliches eigenes Kapital ein, ist die Qualität der Validierungsdaten keine reine Engineering-Frage. Eine Go-Entscheidung auf Prototyp-Daten ist oft eine Go-Entscheidung auf Zahlen, die du kaum lesen kannst. Das Risiko sind technische Schulden und eine Wette auf die falschen Informationen.

Produktionsqualität ab Tag eins heisst: die gesammelten Daten lassen sich lesen. Ein anderer Weg macht die Entscheidung härter, wenn sie fällt.

Nächster Schritt: Gespräch

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 ein leichterer Einstieg sinnvoller ist.

Gespräch buchen (kostenlos)