MVP in 90 Tagen entwickeln — Vom Konzept zum bezahlenden Kunden

Wer 2026 ein neues Software-Produkt auf den Markt bringen will, hat zwei Möglichkeiten: zwölf bis achtzehn Monate Stillstand mit Lasten- und Pflichtenheft, Architektur-Workshops und Feature-Diskussionen — oder neunzig Tage Disziplin von der Idee zur ersten bezahlten Rechnung. Der zweite Weg ist nicht billiger, aber er ist ehrlicher: nach drei Monaten wissen Sie, ob Ihr Konzept zahlende Kunden findet oder nicht. Das spart in vielen Fällen 200.000 Euro Aufwand für eine Lösung, die der Markt am Ende nicht haben wollte. Für mittelständische Unternehmen, die neue Produkt-Linien testen, für Spin-offs aus etablierten Industrie-Häusern und für gut finanzierte Gründer-Teams ist der 90-Tage-MVP heute das risikoärmste Vorgehen, um eine Geschäfts-Hypothese in den Markt zu bringen. Dieser Artikel zeigt, was MVP-Entwicklung 2026 wirklich heißt, wann sie passt, wie die drei Dreißig-Tage-Phasen konkret aussehen, mit welchem Stack sich Tempo machen lässt und mit welchen Kosten Sie realistisch rechnen. Für die Einordnung in die Gesamtstrategie siehe unseren Softwareentwicklungs-Guide.

Was MVP-Entwicklung 2026 wirklich heißt

Der Begriff Minimum Viable Product ist in den letzten Jahren so weichgespült worden, dass er fast nichts mehr bedeutet. Für seriöse Produkt-Arbeit hilft eine harte Definition: ein MVP ist die kleinste produktionsreife Version eines Produkts, mit der ein zahlender Kunde sein Problem tatsächlich lösen kann — und für die Lösung Geld überweist. Dieser Satz enthält drei Verschärfungen, die in der Praxis oft fehlen.

Erstens produktionsreif: ein MVP ist keine Klick-Demo, kein Figma-Prototyp und kein Pitch-Deck. Er hat Auth, Bezahlung, Datenbank-Backups, ein Mindestmaß an Monitoring und erfüllt DSGVO-Grundpflichten. Wer diese Elemente weglässt, baut keine validierbare Software, sondern eine Verkaufs-Demo, die keine Erkenntnisse über echtes Nutzungs-Verhalten liefert. Zweitens zahlende Kunden: ein MVP, der nur kostenlose Tester findet, ist nicht validiert. Geld ist das einzige Signal, das die Hypothese trägt — alles andere ist Höflichkeits-Feedback. Drittens ein Problem: der MVP löst genau ein Problem für genau eine eng definierte Zielgruppe. Versuche, von Tag eins drei Probleme für drei Zielgruppen zu lösen, scheitern systematisch an Scope-Inflation.

Was ein MVP 2026 nicht ist: kein Prototyp im klassischen Hardware-Sinne — ein Prototyp testet Machbarkeit, ein MVP testet Markt. Keine Demo — eine Demo zeigt, ein MVP wird benutzt. Kein „erstes Release“ im Wasserfall-Sinne — der MVP ist nicht der Beginn der Roadmap, sondern der Mess-Punkt, an dem Sie entscheiden, ob es eine Roadmap geben soll.

Aus unserer Beratungs-Praxis: rund die Hälfte der Projekte, die uns als „MVP-Entwicklung“ angefragt werden, beschreiben in Wirklichkeit ein ausgereiftes Produkt mit zwanzig bis dreißig Funktionen. In diesen Fällen besteht die wertvollste Beratung darin, das Konzept gemeinsam auf den ersten echten Kern-Schmerz zu reduzieren — typischerweise auf drei bis fünf Funktionen, die zusammen einen kompletten Wert-Kreislauf abbilden. Erst dann passen 90 Tage.

Wann der MVP-Approach passt — und wann nicht

Der 90-Tage-MVP ist kein universelles Vorgehen. Er passt in klar definierten Situationen, und er passt deutlich nicht in anderen. Die folgende Übersicht hilft bei der Vorab-Einordnung.

MVP-Approach passt	MVP-Approach passt nicht
Neues Produkt mit unklarem Markt-Bedarf	Bekannter Markt mit erprobtem Bedarf und harter Compliance
Spin-off oder neue Geschäfts-Linie eines Mittelständlers	Ablösung eines geschäftskritischen Bestands-Systems
Gründungs-Team in der Pre-Seed- oder Seed-Phase	Regulierte Branchen mit Zulassungs-Pflicht ab Tag eins (Medizin, Bank)
Schmaler initialer Funktions-Umfang, klarer Wert-Kreislauf	Großer initialer Funktions-Umfang über mehrere Bereiche
Internes Tool, das ein konkretes Team-Problem löst	Plattform mit Netzwerk-Effekten, die kritische Masse braucht

Eine besonders häufige Fehl-Anwendung: der MVP-Ansatz wird auf die Ablösung eines bestehenden, geschäftskritischen Systems angewendet — etwa eine ERP-Komponente oder ein Kunden-Portal mit zehn Jahren Funktions-Tiefe. Hier reicht die kleinste produktionsreife Version nicht aus, weil sie nicht „etwas Neues testet“, sondern „etwas Etabliertes ersetzen“ muss. Solche Vorhaben brauchen eine andere Methodik, oft mit parallelem Betrieb über Monate.

Tag 1 bis 30: Discovery

Die ersten dreißig Tage sind die wertvollsten und gleichzeitig die, die in der Praxis am häufigsten übersprungen werden. Wer hier abkürzt, baut in den Tagen 31 bis 90 eine Lösung für ein Problem, das so nicht existiert. Discovery hat drei Bausteine, die parallel laufen.

Problem-Interviews mit Zielkunden. Zwischen fünfzehn und fünfundzwanzig strukturierte Gespräche mit Personen, die das vermutete Problem haben. Wichtig: Sie verkaufen nichts, Sie fragen nichts hypothetisches, Sie hören zu. Die richtigen Fragen sind „Wann hatten Sie das letzte Mal …“ und „Was haben Sie dann gemacht …“ — nicht „Würden Sie ein Produkt nutzen, das …“. Aus diesen Gesprächen kommen zwei Ergebnisse: eine präzise Problem-Beschreibung in den Worten der Zielgruppe, und eine Liste der heute genutzten Workarounds, die der MVP übertreffen muss.

Smoke-Tests zur Nachfrage-Messung. Eine schlanke Landing-Page mit präziser Problem-Beschreibung, ein „Jetzt vormerken“-Formular und 1.500 bis 5.000 Euro Performance-Marketing-Budget zum Test. Die wichtige Kennzahl ist nicht die absolute Klick-Zahl, sondern die Conversion-Rate von Anzeige zu Vormerkung. Liegt sie über zwei Prozent in der spitzen Zielgruppe, hat das Konzept Tragkraft. Liegt sie unter einem Prozent, ist das ein Frühwarn-Signal — entweder am Konzept, an der Positionierung oder an der Zielgruppe stimmt etwas nicht.

Lo-Fi Mockups und Wireframes. Parallel entstehen einfache Skizzen — bewusst lo-fi, weil schöne Designs in Interviews die Aufmerksamkeit auf Optik statt Inhalt lenken. Tools wie Figma, Excalidraw oder auch Bleistift auf Papier reichen. Diese Mockups werden in den letzten Interviews der Discovery-Phase als Stimulus eingesetzt: nicht „gefällt Ihnen das?“, sondern „wo wäre der erste Punkt, an dem Sie hängen bleiben?“.

Am Ende von Tag 30 stehen drei Artefakte fest: eine präzise Problem-Beschreibung, eine validierte Nachfrage-Hypothese mit Conversion-Zahlen, ein dünnes Wireframe-Set für die fünf bis acht wichtigsten Screens. Wer hier nicht weiterkommt, sollte nicht in den Build gehen — die Wahrscheinlichkeit, in den Tagen 31 bis 90 ein nicht-validiertes Produkt zu bauen, ist sehr hoch.

Tag 31 bis 60: Build mit dem Lean-Stack

Die zweite Phase ist die intensivste und die, in der sich Tempo-Disziplin entscheidet. Wer hier auf Eigen-Entwicklung von nicht-differenzierenden Komponenten setzt, verliert die 90 Tage. Wir empfehlen für die allermeisten 2026er MVPs einen konsequenten Lean-Stack:

• Frontend und Backend: Next.js 15 mit App-RouterEine Codebasis für UI und API, server-rendert ohne separates Backend, Type-Safety durchgängig mit TypeScript. Spart in 90 Tagen etwa drei Wochen gegenüber getrennten Frontend- und Backend-Codebasen.
• Datenbank: Managed Postgres bei Neon oder SupabaseKein DB-Server zu betreiben, Backups automatisch, Branching für Preview-Deployments. Drizzle ORM für Type-Safety in TypeScript-Migrations, Volltext-Suche und JSON-Felder out-of-the-box.
• Authentifizierung: ClerkLogin, Registrierung, Passwort-Reset, SSO mit Google und Microsoft, 2FA — alles in einem Tag eingebunden. Eigene Auth zu bauen kostet zwei bis vier Wochen und liefert kein einziges Marktwert-Argument.
• Bezahlung: Stripe Checkout und Customer PortalAbonnements, einmalige Zahlungen, Mehrwertsteuer-Logik für die EU, Kunden-Self-Service für Rechnungen — fertig konfigurierbar in zwei Tagen. Stripe Tax übernimmt die korrekte Steuer-Berechnung in allen EU-Ländern.
• Hosting: VercelGit-Push deployt automatisch, Preview-URLs pro Branch, Edge-Funktionen, Analytics. Keine Server-Administration, kein Patch-Management, kein eigenes CDN. Kosten in der MVP-Phase typischerweise unter 50 Euro pro Monat.

Dieser Stack ist nicht der einzige sinnvolle, aber einer der wenigen, die in der Praxis konsequent 90 Tage halten. Eine ausführliche Stack-Vergleichs-Argumentation finden Sie in unserem Cluster zur Webapp-Entwicklung 2026.

Inhaltlich gilt in dieser Phase eine Regel: Wireframes-First. Bevor eine Zeile UI-Code geschrieben wird, ist jeder Screen als Low-Fi-Wireframe geklärt, jede Form als Skizze festgehalten, jeder Datenfluss als Sequenz-Diagramm notiert. Diese Vorarbeit kostet drei bis fünf Tage und spart in der Implementierung mehrere Wochen Hin und Her. Parallel läuft Feature-Cut radikal: jedes Feature, das nicht für den Wert-Kreislauf des ersten zahlenden Kunden zwingend ist, fliegt raus. Nutzer-Profile mit Avatar? Raus. Mehrsprachigkeit? Raus. Admin-Backend? Raus, solange ein direkter Datenbank-Zugriff reicht. Nice-to-haves fressen MVP-Zeit ohne Markt-Erkenntnis.

Am Ende von Tag 60 steht ein Produkt, das ein zahlender Kunde nutzen könnte: Registrierung, Kern-Funktionalität, Bezahlung, Daten-Export, ein Mindestmaß an Onboarding. Das Design ist ordentlich, nicht aufregend. Es gibt einen Status-Page, ein Sentry-Konto, ein Backup-Konzept und ein Datenschutz-Hinweis-Konzept. Alles weitere wartet auf Marktrückmeldung.

Tag 61 bis 90: Test, Launch und Pricing

Die dritte Phase ist die, die am häufigsten unterschätzt wird. Sie ist nicht „Launch und fertig“, sondern „kontrollierter Markt-Eintritt mit echten Kunden“. Drei Bausteine prägen sie.

Closed Beta mit zehn bis dreißig zahlenden Kunden. Der MVP geht nicht öffentlich, sondern an eine kleine, ausgewählte Gruppe — oft genau jene Personen, die in den Discovery-Interviews den schärfsten Schmerz beschrieben haben. Diese Gruppe zahlt von Tag eins, allerdings zu einem Beta-Tarif. Geld ist Pflicht, weil nur zahlende Kunden ehrliches Feedback geben. Kostenlose Tester sind freundlich und nicht aussage-kräftig.

Pricing-Tests mit drei Preisstufen. Drei Tarife — etwa 49, 99 und 199 Euro pro Monat — werden parallel im Closed-Beta-Konto angeboten. Die Verteilung der gewählten Tarife ist die wichtigste Pricing-Information, die Sie in dieser Phase bekommen können. Bonus: jede ausgesprochene Reaktion auf den Preis („zu teuer“, „dafür reicht der mittlere Tarif“) ist eine direkte Information über wahrgenommenen Wert. Die meisten MVPs unterpreisen sich, weil das Gründungs-Team selbst den Wert noch nicht sieht.

Conversion-Funnel-Auswertung. Vom ersten Seitenbesuch bis zur zweiten Rechnung wird jeder Schritt gemessen: Landing-Page-Conversion, Sign-up-Rate, Activation-Rate (haben die Nutzer die Kern-Funktion mindestens einmal genutzt?), Conversion auf zahlend, Verlängerungs-Rate nach dem ersten Monat. Diese fünf Zahlen bilden den MVP-Funnel und sind die Datenbasis für die Tag-91-Entscheidung.

Parallel laufen in dieser Phase die Sammlung von Testimonials, der Aufbau einer Wartelisten-Mechanik für den Public Launch nach Tag 90, sowie die Verfeinerung der Onboarding-Flows anhand der ersten Nutzer-Sessions.

KPIs: Discovery, Build, Launch

Jede der drei Phasen hat eigene Erfolgs-Kennzahlen. Wer in Phase eins die Build-KPIs misst oder in Phase drei die Discovery-KPIs prüft, optimiert auf die falsche Ebene. Die folgende Übersicht ordnet die wichtigsten zu.

Phase	Leit-Kennzahl	Schwellenwert
Discovery (Tag 1–30)	Anzahl strukturierter Problem-Interviews	mindestens 15, idealerweise 20–25
Discovery (Tag 1–30)	Conversion-Rate Smoke-Test-Landing-Page	über 2 % in der spitzen Zielgruppe
Discovery (Tag 1–30)	Anzahl glaubwürdiger Workarounds in Zielgruppe	mehr als 3 unterschiedliche Notlösungen
Build (Tag 31–60)	Anteil weggeschnittener Features gegenüber Initial-Liste	über 50 % Cut-Rate
Build (Tag 31–60)	Anzahl produktiv genutzter externer Services	fünf bis acht Lean-Stack-Bausteine
Build (Tag 31–60)	Lead-Time von Commit zu Produktion	unter 15 Minuten
Launch (Tag 61–90)	Anzahl zahlender Closed-Beta-Kunden	10–30
Launch (Tag 61–90)	Activation-Rate (Kern-Feature mindestens einmal genutzt)	über 40 %
Launch (Tag 61–90)	Monatliche Verlängerungs-Rate	über 70 % im ersten Monat

Die wichtigste Kennzahl über alle Phasen hinweg ist die Geschwindigkeit, mit der Hypothesen widerlegt werden. Ein MVP, der nach 90 Tagen sagt „wir haben festgestellt, dass das Problem so nicht existiert, hier sind die Belege“, ist erfolgreicher als einer, der nach 90 Tagen ohne Daten weiter baut. Validierung schließt Falsifikation ein.

Typische Fehler in 90-Tage-MVPs

Wir sehen in der Beratung immer wieder die gleichen drei Muster, die MVPs zum Scheitern bringen. Wer sie kennt, vermeidet sie.

Feature-Bloat. Die Initial-Liste mit zwanzig Features fühlt sich „minimal“ an, weil intern schon 200 diskutiert wurden. Tatsächlich ist sie viermal zu groß für 90 Tage. Disziplin hier heißt: jedes Feature muss in einem Satz erklären, warum der erste zahlende Kunde ohne es nicht zahlt. Wer den Satz nicht hinkriegt, streicht das Feature.

Perfekte Architektur. Drei Wochen Diskussion über Microservices, Event-Bus, Multi-Tenant-Strategie und Internationalisierungs-Konzept sind in MVP-Phasen tödlich. Die Lösung ist ein einziger Next.js-Monolith mit Postgres dahinter — kein Microservice, kein Event-Bus, kein Mehr-Sprachen-Setup. Architektur-Skalierung folgt der Validierung, nicht umgekehrt.

Closed Beta endlos. Manche Teams bleiben aus Bequemlichkeit in der Closed Beta hängen — die Kunden sind nett, das Team kennt sie, der Druck ist gering. Das verdeckt das Risiko, dass das Produkt einer breiteren Öffentlichkeit nichts sagt. Die Closed Beta ist auf vier bis acht Wochen begrenzt, danach kommt der Public Launch oder die Pivot-Entscheidung.

Weitere häufige Fehler: Kein klares Kunden-Profil — der MVP versucht es allen recht zu machen und niemandem. Eigene Auth und Bezahlung statt Clerk und Stripe — kostet vier Wochen, liefert keinen Markt-Vorteil. Kein definierter Erfolgs-Schwellenwert für Tag 91 — der MVP läuft danach unentschieden weiter, weil niemand weiß, wann er abgebrochen werden müsste.

Realistisches Budget zwischen 30 und 80 Tausend Euro

Die Kosten eines seriös aufgesetzten 90-Tage-MVP liegen in Deutschland zwischen 30.000 und 80.000 Euro netto. Diese Spanne mag hoch wirken im Vergleich zu Angeboten für 8.000 Euro Klick-Demos, aber sie spiegelt die Realität produktionsreifer Software wider. Die folgende Tabelle ordnet typische Bestandteile zu.

Phase	Aufwand-Anteil	Typische Kosten
Discovery (Tag 1–30)	15–20 %	5.000–15.000 €
Build (Tag 31–60)	50–60 %	17.000–48.000 €
Test und Launch (Tag 61–90)	20–25 %	6.000–20.000 €
Laufende Infrastruktur (Hosting, Stripe, Clerk)	—	200–600 € pro Monat
Performance-Marketing für Smoke-Test	—	1.500–5.000 € einmalig

Was die Position innerhalb dieser Spanne treibt: Funktions-Tiefe und Anzahl der Kern-Screens, Komplexität der Daten-Modelle, Tiefe der Integrationen in bestehende Systeme, gewünschtes Design-Niveau und Verfügbarkeit von Discovery-Vorarbeit aus dem Kunden-Team. MVPs mit klar definiertem Scope, zugänglichen Zielkunden und ohne komplexe Integration in Bestands-IT landen am unteren Rand. MVPs mit Schnittstellen zu ERP-, CRM- oder Branchen-Systemen am oberen Rand. Eine detailliertere Aufstellung möglicher Kostenfaktoren bietet unser Cluster zu Softwareentwicklungs-Kosten 2026.

Unter 30.000 Euro entsteht in 90 Tagen typischerweise kein produktionsreifer MVP, sondern ein hübsches Klick-Modell ohne echte Validierungs-Tiefe — das Geld ist verloren, weil keine belastbare Markt-Erkenntnis entsteht. Über 80.000 Euro lohnt sich nur, wenn der MVP bereits validierte Nachfrage adressiert und mit größerem Initial-Setup direkt skalieren soll. In diesem Bereich verlässt der Ansatz oft den MVP-Charakter und wird zu einer Version 1.0 mit vollem Roadmap-Anschluss.

Was nach 90 Tagen passiert — Skalieren oder Pivot

Am Tag 91 fällt eine Entscheidung, die vorab anhand der KPIs definiert wurde. Drei Wege sind realistisch.

Skalieren. Die Closed Beta produziert zahlende Kunden, die Verlängerungs-Rate liegt über 70 Prozent, die Activation-Rate über 40 Prozent. Jetzt geht es um Public Launch, Performance-Marketing, Vertriebs-Aufbau und Architektur-Härtung. Das ist der wahrscheinlich häufigste Pfad bei sauber validierten MVPs, aber nicht die Mehrheit aller MVPs — das ist wichtig zu wissen, damit Erwartungen realistisch bleiben.

Pivotieren. Das Problem stimmt, die Lösung trifft den Schmerz aber nicht oder die Zielgruppe ist anders als angenommen. Pivot-Entscheidungen sind die wertvollsten Ergebnisse vieler MVPs — und sie sind nur möglich, weil die 90 Tage echte Markt-Daten produziert haben. Ein Pivot ist kein Scheitern, sondern eine Schärfung des Konzepts mit deutlich reduziertem Risiko.

Einstellen. Weder Problem-Tragfähigkeit noch Zahlungs-Bereitschaft sind gegeben. Diese Entscheidung ist emotional schwer und finanziell richtig: 60.000 Euro investiert und gestoppt ist deutlich günstiger als 400.000 Euro investiert und gehofft. Die saubere Einstellung mit dokumentierter Begründung ist ein professioneller Vorgang, kein Makel.

Die SaaS-spezifische Skalierungs-Diskussion mit Pricing-Modellen, Vertriebs-Aufbau und Investor-Logik finden Sie ausführlich in unserem SaaS-Aufbauen-Leitfaden.

Der Reepa-MVP-Approach

Wir bauen MVPs nach einem festen Drei-Sprint-Modell: Sprint 1 Discovery (vier Wochen) mit eigenem Interview-Lead und Smoke-Test-Setup, Sprint 2 Build (fünf Wochen) auf Lean-Stack mit täglichem Deployment, Sprint 3 Launch (drei Wochen) mit Closed-Beta-Begleitung und Pricing-Test-Auswertung. Über die gesamten 90 Tage steht ein dedizierter Ansprechpartner zur Verfügung, ein wöchentlicher Steering-Termin sichert die Disziplin im Scope. Wir arbeiten mit kleinen Teams — typischerweise zwei bis drei Personen — und ohne Sub-Sub-Sub-Unternehmer-Ketten. Das hält Kommunikation kurz und Verantwortung klar.

Unser Stack-Default ist der oben beschriebene: Next.js, Drizzle, Postgres bei Neon, Clerk, Stripe, Vercel. Abweichungen sind möglich — etwa wenn Bestands-Systeme andere Datenbanken vorgeben — aber sie kosten Tempo und werden bewusst entschieden. Design liefern wir auf einem Niveau, das im B2B-Kontext professionell wirkt, ohne dafür Wochen zu verbrennen.

Was uns wichtig ist: am Tag 91 muss Klarheit herrschen. Skalieren, Pivot oder Stopp — diese Entscheidung soll auf Daten beruhen, nicht auf Hoffnung. Deshalb definieren wir gemeinsam am Tag eins die KPI-Schwellenwerte, ab denen wir gemeinsam von einem erfolgreichen MVP sprechen. Diese Disziplin ist unbequem, aber sie schützt vor 200.000-Euro-Folge-Investitionen in nicht-tragfähige Konzepte.

Häufige Fragen