MVP-Entwicklungsdienste: Was Sie Woche für Woche erwartet

Sie haben Anbieter verglichen, die Angebote gelesen und mit einem MVP-Entwicklungsteam unterschrieben. Nun ändert sich die Frage von wer soll das bauen zu was passiert jetzt. Zu wissen, wie ein typisches Projekt abläuft, hilft Ihnen, vorbereitet aufzutreten, Probleme früh zu erkennen und die zwei häufigsten Gründerfehler zu vermeiden: drei Wochen verschwinden oder das Produkt jeden Montag neu entwerfen wollen.

So sieht ein gut geführtes MVP-Projekt von innen aus.

Woche 0 bis 1: Discovery und Abstimmung

In der ersten Woche geht es nicht um Code. Es geht darum sicherzustellen, dass das Team dasselbe Produkt baut, das Sie im Angebot beschrieben zu haben glaubten.

Erwarten Sie Sitzungen, die Folgendes abdecken:

• Das Kundenproblem und wer es hat, in konkreten Worten
• Die eine Annahme, die das MVP prüfen muss
• Der eine Nutzerpfad, der von Anfang bis Ende funktionieren muss
• Welche Funktionen im Umfang sind, welche ausdrücklich nicht, und welche noch offen sind
• Technische Unbekannte — Integrationen, Datenquellen, Drittanbieter-APIs, KI-Komponenten
• Wie Sie messen werden, ob das MVP erfolgreich war

Wenn Sie diese Überlegungen noch nicht angestellt haben, bringt die Discovery-Woche sie zutage. Haben Sie es getan — etwa über einen strukturierten MVP-Planungsprozess vor Beginn der Entwicklung — dann verläuft diese Woche schneller und bestätigt vor allem Entscheidungen.

Das Ergebnis ist ein Umfangsdokument und ein grober Sprintplan. Lesen Sie das Umfangsdokument sorgfältig. Alles, was nicht darin steht, wird standardmäßig nicht gebaut.

Woche 1 bis 2: Scoping, Design und Einrichtung der Umgebung

Während die Discovery abschließt, beginnt das Team, den Umfang in etwas Baubares zu übersetzen:

• Low-Fidelity-Wireframes oder Bildschirmabläufe für den Kernpfad
• Ein Datenmodell — was das System speichern muss und wie Datensätze zusammenhängen
• Ein technischer Ansatz: Stack, Hosting, wichtigste Bibliotheken, Integrationsmethoden
• Repository, Umgebungen und Deployment-Pipeline eingerichtet
• Ein Backlog an Arbeitspaketen, geordnet danach, was den Kernpfad zuerst liefert

Sie sollten die Wireframes sehen und abnehmen. Dies ist der günstigste Zeitpunkt, um zu sagen: „So soll der Buchungsablauf nicht funktionieren.“ Dieselbe Änderung kostet weit mehr, sobald sie gebaut ist.

Woche 2 bis 8: Build-Sprints

Der Build läuft in festen Zyklen, meist von zwei Wochen. Jeder Sprint folgt demselben Rhythmus:

Sprint-Ereignis	Was passiert	Ihre Rolle
Sprint-Planung	Team verpflichtet sich auf eine Menge an Backlog-Punkten	Teilnahme optional; Prioritäten bestätigen
Tägliche Arbeit	Funktionen gebaut, getestet, auf eine Staging-Umgebung ausgerollt	Fragen innerhalb eines Tages beantworten
Zwischenstand	Kurzes asynchrones Update zu Fortschritt und Blockern	Lesen; Bedenken ansprechen
Sprint-Review	Funktionierende Software auf Staging vorgeführt	Teilnehmen; Feedback geben
Sprint-Retro	Team passt seinen eigenen Prozess an	Nicht Ihr Meeting

Die wichtigste Gewohnheit hier ist, die Staging-Umgebung zwischen den Reviews selbst zu nutzen. Klicken Sie sich durch die Abläufe. Ein Gründer, der wöchentlich testet, fängt Missverständnisse ab, solange sie günstig zu beheben sind. Ein Gründer, der nur die Demo ansieht, entdeckt oft in Woche sieben, dass eine Kerninteraktion in Woche drei falsch gebaut wurde.

Erwarten Sie, dass sich der erste Sprint oder zwei bei sichtbaren Funktionen langsam anfühlen — Fundamentarbeit wie Authentifizierung, Datenmodelle und Deployment lässt sich schlecht vorführen, aber alles andere hängt davon ab. Danach beschleunigt sich der sichtbare Fortschritt.

Woche 8 bis 10: Härtung und Launch-Vorbereitung

Der letzte Abschnitt betrifft keine neuen Funktionen. Es geht darum, das Vorhandene für echte Nutzer vertrauenswürdig zu machen:

• Die in den Reviews gefundenen Bugs beheben
• Randfälle im Kernpfad testen — leere Zustände, fehlgeschlagene Zahlungen, fehlerhafte Eingaben
• Grundlegende Sicherheitsprüfung: Zugriffskontrollen, Datenverarbeitung, Abhängigkeitsprüfung
• Fehlerüberwachung und grundlegende Analysen einrichten
• Produktions-Deployment und ein Smoke-Test mit echten Konten
• Übergabedokumentation schreiben

Dies ist auch der Zeitpunkt, an dem Sie dem Wunsch widerstehen sollten, „nur noch eine Sache“ hinzuzufügen. Jede späte Ergänzung überspringt den Review-Zyklus, der früher im Build Probleme aufgefangen hat.

Launch und Übergabe

Eine ordentliche Übergabe umfasst:

• Die Anwendung läuft in Produktion, auf Infrastruktur, die Sie kontrollieren
• Quellcode in einem Repository, das Ihnen gehört, nicht der Agentur
• Jedes Konto, jeder API-Schlüssel und jede Zugangsdaten, die das System nutzt
• Ein schriftlicher Überblick über die Architektur und wie man sie lokal betreibt
• Eine Live-Sitzung, die die Codebasis und das Deployment durchgeht
• Eine Vereinbarung darüber, welcher Support gegebenenfalls nach dem Launch weiterläuft

Ist einer dieser Punkte in Ihrem Vertrag vage, klären Sie ihn jetzt statt nach der Schlussrechnung. Gründer, die diesen Schritt überspringen, finden sich oft vom operativen Wissen über ihr eigenes Produkt ausgesperrt.

Wie gute und schlechte Projekte aussehen

Signal	Gesundes Projekt	Warnzeichen
Kommunikation	Wöchentliche Demo an echter Software, asynchrone Updates dazwischen	Nur Text-Updates, Demos verschieben sich oder fallen aus
Umfang	Änderungen benannt als im Umfang oder als kalkulierte Änderung	Alles ist „das kriegen wir wahrscheinlich noch unter“
Staging-Zugang	Sie können den Build jederzeit nutzen	Sie sehen immer nur einen geteilten Bildschirm
Erste Sprints	Fundamentarbeit, ehrlich über geringe sichtbare Ausbeute	Beeindruckende Demo, aber nichts funktioniert, wenn Sie es versuchen
Übergabe	Von Anfang an im Vertrag festgehalten	Zum ersten Mal am Ende angesprochen

Kommen Sie vorbereitet

MVP-Entwicklungsdienste funktionieren am besten, wenn der Gründer das Projekt als arbeitende Partnerschaft behandelt: verfügbar, entscheidungsfreudig und das Produkt jede Woche testend — nicht abwesend und nicht bei jedem Gespräch neu entwerfend. Je klarer Ihr Problem, Ihre Annahme und Ihr Kernpfad am ersten Tag sind, desto mehr des Budgets fließt in den Bau der richtigen Sache.

Wenn Sie einen strukturierten Weg wollen, den Umfang vor dem Start zu definieren, schlüsselt unser Leitfaden dazu, was tatsächlich in MVP-Entwicklungsdiensten enthalten ist, die üblichen Ergebnisse auf, und die Startup Library von Y Combinator enthält nützliches Material zum Scoping einer ersten Version.

Häufig gestellte Fragen

Wie lange dauern MVP-Entwicklungsdienste in der Regel?

Die meisten fokussierten MVP-Projekte dauern sechs bis zwölf Wochen vom Kickoff bis zu einer nutzbaren ersten Version. Discovery und Scoping brauchen ein bis zwei Wochen, der Build läuft in Zwei-Wochen-Sprints, und die Launch-Vorbereitung fügt eine letzte Woche hinzu. Produkte mit vielen Integrationen, Anforderungen an KI-Genauigkeit oder regulatorischer Prüfung dauern länger.

Was muss der Gründer während eines MVP-Projekts tun?

Der Gründer nimmt an einem wöchentlichen Review teil, beantwortet Produktfragen innerhalb von ein bis zwei Tagen, gibt Zugang zu Konten oder Daten, die der Build braucht, und trifft Priorisierungsentscheidungen, wenn Abwägungen auftauchen. Die technischen Entscheidungen liegen beim Team, aber die Produktentscheidungen bleiben bei Ihnen.

Was erhalte ich am Ende tatsächlich?

Sie sollten eine laufende Anwendung in Produktion erhalten, den Quellcode in einem Repository, das Ihnen gehört, Konten und Zugangsdaten für jeden genutzten Dienst, grundlegende Dokumentation und eine kurze Übergabesitzung. Bestätigen Sie all das im Vertrag, bevor Sie unterschreiben.

Kann sich der Umfang während des Builds ändern?

Kleine Anpassungen sind normal und werden meist innerhalb eines Sprints aufgefangen. Größere Änderungen — ein neuer Nutzertyp, eine größere Integration, eine andere Plattform — werden als Umfangsänderung mit eigener Schätzung behandelt, weil sie Zeitplan und Kosten erhöhen. Ein guter Anbieter sagt Ihnen, in welche Kategorie eine Anfrage fällt.