We Launch Rockets ist ein Product-Engineering- und AI-Product-Engineering-Studio in Deutschland. Ein KI-MVP validiert Ihre Kernhypothese in 2–4 Wochen, in vier Phasen von Discovery und Scope über Entwicklung und Härtung bis zum Launch. Sie haben eine Idee für ein KI-gestütztes Produkt und wollen nicht sechs Monate planen, bevor Sie wissen, ob der Ansatz funktioniert: Das KI-MVP ist kein fertiges Endprodukt, sondern ein gezielter Test mit echten Nutzern. Wann vier Wochen realistisch sind, steht weiter unten in diesem Beitrag.
Dieser Artikel gibt Ihnen einen konkreten Fahrplan. Von der Problemdefinition über ki-gestütztes Prototyping bis zum Go-Live. Mit realistischen Kostenrahmen, ohne Agentur-Verkaufsrhetorik.
Was ist ein KI-MVP — und was ist es nicht?
Ein KI-MVP (Minimum Viable Product) ist die kleinstmögliche Version eines KI-gestützten Produkts, die eine einzige Geschäftshypothese mit echten Nutzern validiert — in der Regel innerhalb von 2–4 Wochen.
Konkret beantwortet es eine zentrale Frage: Löst diese KI-Funktion ein echtes Problem für echte Nutzer? Nicht mehr, nicht weniger.
Das unterscheidet es von zwei Dingen, die oft damit verwechselt werden. Ein Proof of Concept (PoC) zeigt nur, dass etwas technisch machbar ist. Sie bauen ihn für sich selbst, nicht für Nutzer. Ein MVP dagegen geht an echte Nutzer und misst, ob sie den Mehrwert erkennen. Ein fertiges Produkt wiederum hat Features, Skalierung, Compliance und Support. All das braucht Ihr MVP noch nicht.
Konkret heißt das: Ihr KI-MVP hat genau einen Use Case. Einen Datenfluss. Eine Kernfunktion. Alles andere kommt später — oder gar nicht, falls der Test zeigt, dass die Idee nicht trägt. Gerade bei KI-Projekten scheitern Unternehmen selten an der Modellwahl. Sie scheitern daran, dass sie zu viel gleichzeitig bauen wollen, bevor die Grundannahme validiert ist.
Der 4-Phasen-Plan: Vom Prototyp zum Produkt
Phase 1: Discovery und Scope (Woche 1)
In der ersten Woche geht es um Klarheit, nicht um Code. Sie definieren das eine Problem, das Ihr KI-MVP lösen soll. Nicht drei Probleme, nicht ein vages Ziel wie „KI für bessere Prozesse“ — sondern eine messbare Hypothese. Wie Sie Discovery strukturieren, steht im Ratgeber zu Product Discovery.
Ein Beispiel: „Wenn wir eingehende Support-Anfragen automatisch kategorisieren und priorisieren, reduziert sich die durchschnittliche Reaktionszeit um 40 %.“ Das ist testbar. Das ist messbar. Und es grenzt den Scope so ein, dass Sie in vier Wochen fertig werden.
In dieser Phase klären Sie drei Fragen. Erstens: Welches Kernproblem lösen Sie, und woran messen Sie den Erfolg? Zweitens: Welche Daten liegen bereits in brauchbarer Qualität vor? Daten sind bei KI-Projekten laut McKinsey der häufigste Showstopper — nicht die Technologie. Drittens: Was ist der kleinstmögliche Feature-Umfang, der die Hypothese testet?
Am Ende von Woche 1 haben Sie ein priorisiertes Backlog mit maximal 5–8 User Stories und einen klaren KPI. Kein Lastenheft. Kein Wireframe-Marathon. Ein fokussiertes, einseitiges Briefing.
Phase 2: KI-gestützte Entwicklung (Woche 2–3)
Jetzt bauen Sie. Der Schlüssel zur Geschwindigkeit liegt nicht darin, schneller zu programmieren, sondern weniger zu programmieren. Moderne KI-Coding-Tools wie Cursor, GitHub Copilot oder Full-Stack-Generatoren wie Lovable und Bolt.new beschleunigen die Entwicklungszeit bei Routineaufgaben um rund 55 Prozent, wie eine Studie von GitHub zeigt.
In der Praxis sieht das so aus: Sie nutzen bestehende LLM-APIs (OpenAI, Anthropic, Google) für die KI-Logik, statt eigene Modelle zu trainieren. Sie bauen eine einfache Oberfläche, die den Kern-Use-Case abbildet. Und Sie integrieren nur die Datenquelle, die Ihr MVP tatsächlich braucht — keinen universellen Daten-Hub.
Ein typischer Tagesrhythmus in dieser Phase: Morgens eine funktionale Komponente bauen. Nachmittags testen. Abends den Scope für den nächsten Tag anpassen. Das klingt agil, weil es agil ist — aber in einer radikalen Kurzform, die nur funktioniert, wenn Phase 1 den Scope sauber eingegrenzt hat.
Wichtig ist, was Sie in dieser Phase nicht tun: keine Nutzerverwaltung mit Rollenkonzept, kein Billing-System, keine Multi-Tenancy, keine CI/CD-Pipeline mit 98 % Test Coverage. All das ist wichtig — aber erst in Phase 2 Ihres Produkts, nicht in Phase 2 Ihres MVPs.
Phase 3: Härtung und Testing (Ende Woche 3)
Geschwindigkeit ist kein Freibrief für Schlampigkeit. Ende Woche 3 durchläuft Ihr MVP einen strukturierten Review. Ein erfahrener Entwickler prüft den generierten Code auf Sicherheitslücken, Datenflüsse und Fehlerbehandlung. Gerade bei KI-generiertem Code ist dieser Review unverzichtbar, weil KI-Assistenten konsistenten, aber nicht immer sicheren Code produzieren.
Parallel laufen erste Nutzertests. Sie brauchen dafür keine 500 Tester. Fünf bis zehn Personen aus Ihrer Zielgruppe reichen, um die zentrale Frage zu beantworten: Verstehen sie den Mehrwert? Nutzen sie die Kernfunktion? Wo haken sie?
In dieser Phase passiert meistens auch das erste Scope-Trimming. Features, die Sie in Woche 1 für wichtig gehalten haben, stellen sich als irrelevant heraus. Andere, an die Sie nicht gedacht haben, werden plötzlich sichtbar. Dieses Lernen ist der eigentliche Wert des MVPs — nicht das Produkt selbst.
Phase 4: Deployment und Launch (Woche 4)
Ihr MVP geht live. Nicht auf einer hochverfügbaren Kubernetes-Infrastruktur, sondern auf einer pragmatischen Cloud-Umgebung. Firebase, Vercel, Railway — die Wahl hängt von Ihrem Stack ab, nicht von Skalierungsphantasien. Sie brauchen einfaches Monitoring (Fehler-Tracking, API-Kosten), keine Observability-Plattform.
Der Go-Live ist leise. Sie rollen an eine kontrollierte Gruppe aus, sammeln Daten, und werten nach 7–14 Tagen aus. Die Frage am Ende von Woche 4 lautet nicht „Ist das Produkt perfekt?“ sondern „Hat die Hypothese gehalten?“
Wenn ja: Roadmap für Phase 2 planen, Team aufbauen, Skalierung vorbereiten. Wenn nein: Sie haben vier Wochen und einen überschaubaren Betrag investiert statt sechs Monate und ein Vielfaches — und wissen jetzt, warum die Idee nicht funktioniert.
Was kostet ein KI-MVP? Eine ehrliche Einordnung
Die Kostenspanne hängt von drei Faktoren ab: Komplexität, Datenbereitschaft und Teamstruktur. Eine realistische Einordnung für den DACH-Markt:
| Kategorie | Budget | Was Sie bekommen |
|---|---|---|
| Lean KI-MVP | ca. 15.000 EUR | Eine Kernfunktion, bestehende LLM-APIs, einfache Oberfläche, Cloud-Deployment |
| Standard KI-MVP | ca. 30.000 EUR | Mehrere integrierte Funktionen, robustes Backend, Nutzerverwaltung, produktionsnahe Umgebung |
| Komplexe KI-Plattform | ab 40.000 EUR | Eigene Modelle, Compliance (Medizin/Fintech), komplexe Daten-Pipelines |
Für ein echtes MVP — also den Test einer Kernhypothese in 2–4 Wochen — bewegen Sie sich im Lean-Bereich: 15.000 EUR. Der „Standard“-Bereich ist bereits kein MVP mehr, sondern ein erstes Produkt.
Drei Kostenfallen, die viele Teams übersehen: Erstens die laufenden API-Kosten. LLM-Tokens kosten pro Aufruf. Bei einem MVP mit 100 Nutzern ist das vernachlässigbar. Bei 10.000 Nutzern kann das schnell mehrere tausend Euro im Monat bedeuten. Zweitens die Datenvorbereitung. Wenn Ihre Unternehmensdaten nicht in brauchbarem Format vorliegen, frisst die Aufbereitung leicht 30–50 % des Gesamtbudgets. Drittens der Faktor Erfahrung: Wenn Ihr Team zum ersten Mal ein KI-Projekt umsetzt, lernen Sie im Projekt — das ist wertvoll, kostet aber Zeit. Ein erfahrener Partner beschleunigt genau diese Lernkurve.
Wegwerf-Prototyp oder produktionsreifes MVP?
Bevor Sie starten, klären Sie eine strategische Frage: Bauen Sie einen Wegwerf-Prototypen oder ein MVP, das direkt in den Live-Betrieb übergeht?
Ein Wegwerf-Prototyp dient dem Lernen. Sie bauen ihn bewusst schnell und schmutzig, um eine Annahme zu testen. Nach dem Test werfen Sie den Code weg und bauen — mit den Erkenntnissen — das echte Produkt von Grund auf neu. Dieser Ansatz ist sinnvoll, wenn die Kernfrage noch offen ist: „Wollen Nutzer das überhaupt?“ Tools wie Figma, No-Code-Builder oder schnelle Prompt-Prototypen eignen sich hier.
Ein produktionsreifes MVP hingegen wird zum Fundament Ihres Produkts. Der Code muss sauber genug sein, dass ein Team darauf aufbauen kann. Die Architektur muss erweiterbar sein. Dieser Ansatz lohnt sich, wenn die Grundannahme validiert ist und Sie direkt Richtung Produkt gehen wollen. Hier brauchen Sie erfahrene Entwickler und Tools, die produktionsreifen Code generieren.
Die häufigste Fehlentscheidung: Ein Wegwerf-Prototyp wird zum Produkt erklärt, weil „er ja funktioniert“. Das führt zu technischen Schulden, die Sie sechs Monate später einholen. Treffen Sie die Entscheidung bewusst und kommunizieren Sie sie im Team.
Wann sind 2–4 Wochen realistisch — und wann nicht?
Vier Wochen sind realistisch, wenn drei Bedingungen erfüllt sind. Erstens: Der Scope ist radikal eingegrenzt auf einen Use Case. Zweitens: Brauchbare Daten liegen bereits vor. Drittens: Sie haben Zugang zu einem Team (intern oder extern), das KI-Projekte nicht zum ersten Mal umsetzt.
Vier Wochen sind nicht realistisch bei regulierten Branchen (Medizin, Fintech) mit Freigabeprozessen, bei komplexen Legacy-Integrationen („SAP-Anbindung in vier Wochen“ ist ein Wunschtraum), oder wenn erst Trainingsdaten gesammelt und gelabelt werden müssen. In diesen Fällen planen Sie mit 8–12 Wochen — oder trennen Sie den Scope so, dass Sie eine regulatorisch unkritische Teilfunktion als erstes MVP bauen.
Nächste Schritte
Sie haben jetzt einen klaren Fahrplan. Die entscheidende Frage ist: Was ist die eine Hypothese, die Sie als Erstes testen wollen?
Definieren Sie sie in einem Satz. Prüfen Sie, ob Ihre Daten bereit sind. Und entscheiden Sie, ob Sie intern die Kapazität haben oder einen erfahrenen Partner brauchen, der den Prozess in 2–4 Wochen durchsteuert. Mehr zu unserem Vorgehen finden Sie unter AI Product Engineering.
FAQ
Was unterscheidet ein KI-MVP von einem normalen MVP?
Ein KI-MVP validiert eine Hypothese, die auf einer KI-Funktion basiert — etwa automatische Textklassifikation oder Bilderkennung. Der Unterschied zum klassischen Software-MVP: Sie arbeiten mit probabilistischen Modellen statt deterministischer Logik. Das bedeutet, dass Ihr MVP auch Fehler machen wird. Der Test zeigt, ob die Fehlerrate niedrig genug ist, um echten Nutzen zu stiften.
Brauche ich eigene Trainingsdaten für ein KI-MVP?
In den meisten Fällen nicht. Moderne LLM-APIs wie GPT-4 oder Claude funktionieren mit Zero-Shot- oder Few-Shot-Prompting und brauchen keine eigenen Trainingsdaten. Für spezialisierte Aufgaben (medizinische Textanalyse, domänenspezifische Bilderkennung) brauchen Sie gelabelte Daten — aber das ist dann kein 4-Wochen-MVP mehr.
Kann ich ein KI-MVP ohne Programmiererfahrung bauen?
Bedingt. No-Code-Tools wie Lovable oder Bolt.new generieren funktionale Prototypen aus Textbeschreibungen. Für einen Wegwerf-Prototyp reicht das oft. Für ein produktionsreifes MVP brauchen Sie jemanden, der den generierten Code reviewen, absichern und erweitern kann.
Wie messe ich den Erfolg meines KI-MVPs?
Definieren Sie vor dem Bau einen einzigen KPI, der Ihre Kernhypothese misst. Beispiel: „Automatische Kategorisierung hat eine Genauigkeit von mindestens 85 %“ oder „Nutzer sparen durchschnittlich 30 Minuten pro Woche“. Messen Sie nach 7–14 Tagen im Live-Betrieb. Alles andere — Nutzerzufriedenheit, Retention, Weiterempfehlung — kommt in Phase 2. Das Grundprinzip kontrollierter Vergleiche kennen Sie vielleicht schon aus unserem Artikel Was ist A/B-Testing? — bei einem MVP wenden Sie dieselbe Messdisziplin auf ein ganzes Produkt statt auf eine einzelne Variante an.
