MVP in 12 Wochen: Wie wir digitale Produkte von der Idee zum Launch bringen

Zwölf Wochen klingen nach wenig Zeit für ein MVP — ein Minimum Viable Product. Und trotzdem launchen wir regelmäßig in diesem Zeitrahmen — mit funktionierenden Produkten, die echte Nutzer haben und echten Umsatz generieren. Kein Zufall, sondern ein erprobter Prozess.

In diesem Artikel zeige ich Ihnen konkret, wie wir bei Renzi ein MVP von der ersten Idee bis zum Go-Live bringen. Mit echten Beispielen aus unseren eigenen Produkten GeoUp, eFlipCard und survey!.

Warum 12 Wochen?

Zwölf Wochen sind lang genug, um etwas Substanzielles zu bauen. Und kurz genug, um den Fokus nicht zu verlieren. Wer sich sechs Monate Zeit nimmt, baut unweigerlich Features, die niemand braucht. Wer in vier Wochen fertig sein will, liefert einen Prototyp — kein Produkt.

Unser Ansatz: Wir bauen keine Wegwerf-Prototypen. Alles was in den 12 Wochen entsteht, ist produktionsreifer Code auf einer Architektur, die skaliert. Das unterscheidet ein professionelles MVP von einer Demo.

Phase 1: Strategie und Architektur (Woche 1-2)

Bevor eine Zeile Code geschrieben wird, treffen wir die Entscheidungen, die später nicht mehr korrigierbar sind. Diese zwei Wochen sind die wichtigsten des gesamten Projekts.

Was passiert konkret:

• Geschäftsmodell und Zielgruppe schärfen — wer zahlt wofür?
• Feature-Scope definieren: Was muss rein, was kann warten?
• Tech-Stack festlegen (Sprache, Framework, Datenbank, Hosting)
• Datenmodell und API-Struktur entwerfen
• CI/CD-Pipeline und Deployment aufsetzen

Bei eFlipCard haben wir in dieser Phase entschieden, von Anfang an auf Laravel mit einer sauberen REST-API zu setzen — obwohl ein simples Frontend mit statischem Backend schneller gewesen wäre. Diese Entscheidung hat uns später Monate gespart, weil die Plattform ohne Rewrite skalieren konnte.

Die teuersten Fehler in der Softwareentwicklung passieren nicht beim Programmieren, sondern beim Planen. Oder genauer: beim Nicht-Planen.

Phase 2: Backend und API (Woche 3-4)

In diesen zwei Wochen entsteht das Fundament. Keine UI, kein Design — reines Backend. Das klingt für Auftraggeber oft frustrierend, weil es nichts zu sehen gibt. Aber genau hier entscheidet sich, ob das Produkt später stabil läuft oder unter Last zusammenbricht.

Typische Bausteine:

• Authentifizierung und Rollen-System
• Kern-Datenmodelle und Migrationen
• API-Endpoints für alle Hauptfeatures
• Validierung und Fehlerbehandlung
• Erste automatisierte Tests

Bei survey! war das Datenmodell besonders kritisch: Umfragen mit dynamischen Fragetypen, bedingter Logik und Echtzeit-Auswertung. Hätten wir das Datenmodell nicht in Woche 3 sauber durchdacht, wäre die Auswertungslogik später ein Alptraum geworden.

Phase 3: Frontend und Integration (Woche 5-8)

Jetzt wird es sichtbar. In vier Wochen entsteht die gesamte Nutzeroberfläche, verbunden mit dem Backend aus Phase 2. Hier investieren wir die meiste Zeit — und hier zahlt sich die Vorarbeit aus.

Der Ablauf:

• UI-Komponenten entwickeln (Design-System first)
• Frontend mit API verbinden
• Benutzer-Flows durchgängig implementieren
• Responsive Design und Performance-Optimierung
• Interne Reviews nach jedem Sprint

Vier Wochen für das komplette Frontend klingt ambitioniert. Hier kommt KI-gestützte Entwicklung ins Spiel: Repetitive Aufgaben wie Formular-Validierungen, Standard-Komponenten und Boilerplate-Code lassen wir von KI-Tools generieren und überprüfen. Das spart pro Sprint mehrere Tage, die wir in die wirklich komplexen Interaktionen investieren.

Bei GeoUp bedeutete das: Die Kartenintegration, Filter-Logik und Echtzeit-Suche bekamen die volle Aufmerksamkeit, während Standard-UI-Elemente deutlich schneller entstanden.

Phase 4: Testing und Launch (Woche 9-12)

Die letzten vier Wochen gehören nicht der Feature-Entwicklung — sondern der Qualität. Neue Features werden in dieser Phase konsequent abgelehnt. Stattdessen:

• End-to-End-Testing aller kritischen User-Flows
• Performance-Tests und Optimierung
• Security-Audit (Authentifizierung, API, Datenbank)
• Monitoring und Alerting einrichten
• Dokumentation für Nutzer und Betrieb
• Soft Launch mit Beta-Nutzern, dann öffentlicher Launch

Wir unterscheiden zwischen Soft Launch und öffentlichem Launch. Der Soft Launch (Woche 10-11) geht an eine kleine Gruppe echter Nutzer. Deren Feedback fliesst in die letzten Korrekturen ein, bevor das Produkt öffentlich wird.

Was gehört in ein MVP — und was nicht

Die wichtigste Fähigkeit bei der MVP-Entwicklung ist Nein sagen. Hier unsere Faustregel:

Gehört rein:

• Das eine Kern-Feature, das Ihr Produkt definiert
• Saubere Authentifizierung und Datenschutz
• Ein Zahlungs-Flow (wenn Ihr Modell es erfordert)
• Grundlegendes Monitoring und Error-Tracking
• Responsive Design

Kann warten:

• Social-Login, SSO und erweiterte Account-Features
• Umfangreiche Admin-Panels
• Mehrsprachigkeit
• Native Mobile Apps (responsive Web reicht zum Start)
• Erweiterte Analytics und Reporting

Der Fehler, den wir am häufigsten sehen: Gründer wollen zum Launch ein Produkt, das mit etablierten Wettbewerbern mithalten kann. Das ist weder möglich noch nötig. Ihr MVP muss eine Sache besser machen als alle anderen — nicht alles.

KI als Geschwindigkeitsmultiplikator

Wir setzen KI-gestützte Entwicklung nicht als Ersatz für Engineering ein, sondern als Verstärker. Konkret bedeutet das: Code-Generierung für Standardmuster, automatisierte Test-Erstellung, schnellere Debugging-Zyklen und Dokumentation. Das spart je nach Projekttyp 20-30% der Entwicklungszeit — Zeit, die direkt in Produktqualität fliesst.

Entscheidend: KI-generierter Code wird immer von erfahrenen Entwicklern reviewed. Geschwindigkeit ohne Qualitätskontrolle führt zu technischen Schulden, die später ein Vielfaches kosten.

Von der Idee zum Produkt — nicht zum Prototyp

Der wichtigste Unterschied in unserem Ansatz: Wir bauen ab Tag eins für den Produktivbetrieb. Saubere Architektur, automatisierte Tests, dokumentierte APIs. Kein Code, der nach dem Launch weggeworfen und neu geschrieben werden muss.

Das kostet in den ersten Wochen etwas mehr Zeit. Aber es bedeutet, dass Sie nach dem Launch sofort iterieren können — statt die nächsten Monate mit einem Rewrite zu verbringen.