
Der 4-Wochen-MVP-Fahrplan: Was wir von Tag 1 bis zum Launch wirklich machen
"Wir brauchen ein MVP" ist das, was wir am häufigsten von Gründern hören. Es ist auch das am meisten missverstandene Konzept. Ein MVP ist keine schlechte Version deines Produkts. Es ist die kleinste Version, die beweist, ob deine Idee funktioniert.
Wir haben Dutzende MVPs ausgeliefert. Einige wurden zu finanzierten Startups. Einige wurden nach zwei Wochen User-Testing eingestellt. Beide Ergebnisse sind ein Erfolg — weil die Gründer schnell und günstig gelernt haben.
Hier ist genau, was wir machen, Woche für Woche.
Woche 0: Das Gespräch bevor die Uhr läuft
Bevor ein Engagement beginnt, haben wir ein einziges Gespräch. Maximal eine Stunde. Das Ziel ist nicht, jedes Feature zu verstehen — es ist, drei Fragen zu beantworten:
- Welches Problem löst du? Nicht "was willst du bauen" — was ist der tatsächliche Schmerzpunkt?
- Wer hat dieses Problem? Kannst du fünf echte Personen nennen, die für eine Lösung bezahlen würden?
- Was ist das eine, das das MVP können muss? Nicht zehn Dinge. Eins.
Wenn ein Gründer diese Fragen nicht klar beantworten kann, fangen wir nicht an zu bauen. Wir helfen ihnen zuerst, die Antworten zu finden.
Die meisten MVPs scheitern, weil sie zu viel versuchen. Der schwierigste Teil unserer Arbeit ist nicht Code zu schreiben — es ist, Gründer zu überzeugen, dass 80% ihrer Feature-Liste warten sollte.
Woche 1: Discovery & Architektur
Tag 1–2: Requirements-Destillation
Wir nehmen die Vision des Gründers und reduzieren sie auf ein konkretes Scope-Dokument. Das beinhaltet:
- Core User Journey — der eine Pfad, der zählt (z.B. "Nutzer meldet sich an → erstellt ein Listing → erhält eine Buchung")
- Datenmodell — Prisma-Schema-Entwurf mit den wesentlichen Entitäten
- Integrationsmap — welche Third-Party-Services werden benötigt (Payments, E-Mail, Auth)
- Explizite Nicht-Ziele — Features, die wir bewusst noch nicht bauen
Die Nicht-Ziele-Liste ist das wichtigste Dokument. Sie verhindert Scope Creep, bevor er beginnt.
Tag 3–5: Tech-Setup & Architektur
Wir debattieren keine Technologie-Entscheidungen. Unser Stack ist standardisiert:
Framework: Next.js (App Router)
Sprache: TypeScript (strict mode)
Datenbank: PostgreSQL
ORM: Prisma
Auth: better-auth
Styling: Tailwind CSS
Deployment: Vercel oder Hetzner (abhängig vom Budget)
Den Stack zu standardisieren bedeutet, dass wir null Zeit für Setup-Entscheidungen aufwenden und unsere gesamte Zeit ins Produkt stecken.
Bis Freitag der Woche 1 haben wir:
- Eine deployed Skeleton-App (CI/CD funktioniert, Staging-Umgebung live)
- Datenbankschema migriert
- Authentifizierung funktionsfähig
- Einen klickbaren Wireframe der Core Journey
Woche 2: Kernfeature bauen
Das ist der Sprint. Wir bauen die eine User Journey, die das MVP definiert.
Was "Kern" bedeutet
Für einen Marktplatz: Listing-Erstellung + Entdeckung + Buchung. Für ein SaaS-Tool: Onboarding + der primäre Workflow + Output. Für eine Plattform: Registrierung + die Haupt-Interaktionsschleife.
Alles andere — Einstellungsseiten, Admin-Dashboards, Benachrichtigungspräferenzen, Profilbearbeitung — wartet.
// Woche-2-Code ist funktional, nicht hübsch.
// Das ist Absicht. Polish kommt nach der Validierung.
// ✅ Woche 2: funktioniert, beweist das Konzept
export async function createListing(data: ListingInput) {
return prisma.listing.create({
data: {
...data,
status: "ACTIVE",
ownerId: getCurrentUserId(),
},
});
}
// ❌ Nicht Woche 2: optimiert, abstrahiert, erweiterbar
// Das ist Woche 8 — falls wir dahin kommen.
Tägliche Check-ins
Wir machen jeden Tag ein 15-minütiges asynchrones Update. Keine Standups, keine Zeremonien. Ein Loom-Video oder eine kurze Nachricht: was ist fertig, was blockiert, was kommt als nächstes.
Wenn ein Feature mehr als 48 Stunden zur Implementierung braucht, ist es zu komplex für das MVP. Wir vereinfachen es entweder oder streichen es.
Woche 3: Polish & Randfälle
Die Core Journey funktioniert. Jetzt machen wir sie vorzeigbar.
Was wir polieren
- Fehlerzustände — was passiert, wenn etwas schiefgeht (Leerzustände, fehlgeschlagene Zahlungen, Netzwerkfehler)
- Ladezustände — Skeleton Screens, keine Spinner
- Mobile Responsiveness — die meisten Nutzer werden dein MVP auf dem Handy finden
- Transaktionale E-Mails — Bestätigung, Willkommen, Quittung (Plain Text reicht)
- Basic Analytics — PostHog oder Plausible, gerade genug um zu wissen, ob Leute es nutzen
Was wir nicht polieren
- Animationen und Micro-Interactions
- Dark Mode
- Internationalisierung
- Performance-Optimierung jenseits des Offensichtlichen
- Umfassende Testabdeckung (wir schreiben Tests nur für kritische Pfade)
Woche 4: Launch-Vorbereitung & Deploy
Tag 1–3: Testing & Bugfixing
Wir machen einen strukturierten Durchgang jedes Nutzerpfads. Keine automatisierten Tests — manuelles, bewusstes Testen als wären wir ein echter Nutzer. Wir fixen alles, was die Core Journey blockiert. Alles andere wird für später notiert.
Tag 4–5: Produktions-Deploy
- DNS und Domain-Setup
- SSL-Zertifikate
- Umgebungsvariablen geprüft
- Error-Monitoring (Sentry) konfiguriert
- Datenbank-Backups verifiziert
- Ein letzter End-to-End-Test auf Produktion
Bis Freitag ist das MVP live. Echte Nutzer können es verwenden. Der Gründer kann einen Link teilen, kein Pitch Deck.
Was nach Woche 4 passiert
Hier wird es interessant. Das MVP ist eine Hypothese. Jetzt testest du sie.
Wir empfehlen typischerweise:
- Gewinne 10 echte Nutzer in der ersten Woche. Keine Freunde — Leute, die das Problem haben, das du löst.
- Beobachte sie bei der Nutzung. Session-Recordings (mit Einverständnis) verraten mehr als jedes Analytics-Dashboard.
- Miss eine Metrik. Conversion Rate, Retention oder Activation — wähl eine.
- Entscheide in 2 Wochen. Entweder verdoppeln (einen v1.1-Sprint finanzieren) oder pivoten/einstellen.
Das wertvollste MVP, das wir je gebaut haben, wurde nach 10 Tagen eingestellt. Der Gründer sparte sechs Monate und 80.000 €, indem er lernte, dass der Markt nicht wollte, was er baute. Er pivotierte, und die zweite Idee funktionierte.
Warum das funktioniert
Geschwindigkeit heißt nicht, schnell Code zu schreiben. Es heißt, schnell Entscheidungen zu treffen. Unser Prozess funktioniert, weil:
- Keine Stack-Debatten — die Technologie steht fest, bevor wir anfangen
- Kein Scope Creep — die Nicht-Ziele-Liste schützt uns
- Keine großen Enthüllungen — der Gründer sieht jeden Tag Fortschritt
- Keine Perfektion — gut genug zum Validieren, nicht gut genug zum Bewundern
Vier Wochen. Eine Journey. Eine Antwort: Hat diese Idee Potenzial?
Dafür ist ein MVP da.
Du willst dein MVP mit uns bauen? Erfahre mehr über unseren MVP-Entwicklungsprozess oder buche eine kostenlose Beratung.


