MVP entwickeln: von der Idee zur ersten Version, für die Menschen zahlen

Ein MVP zu entwickeln bedeutet, die kleinste Version eines Produkts zu bauen, die echte Nutzer annehmen und im besten Fall bezahlen, damit Sie erfahren, ob die Idee trägt, bevor Sie die vollständige Entwicklung finanzieren. Gut gemacht ist es ein präzises unternehmerisches Experiment mit einem funktionierenden Produkt, keine billige oder unfertige App. Dieser Leitfaden zeigt, wozu ein MVP dient, wie es sich von Prototyp, Proof of Concept und MLP unterscheidet, die Regeln für den Umfang, den Ablauf Schritt für Schritt, den Zeitplan nach Phasen, was die Kosten treibt, das Leben nach dem Launch, DSGVO-Grundlagen und eine Checkliste für den Umfang.

Zuletzt aktualisiert: 19. Oktober 2026.

Wozu dient ein MVP?

Ein Minimum Viable Product (MVP) ist die erste Version eines Produkts, die ein echtes Problem für eine klar definierte Nutzergruppe so gut löst, dass sie es freiwillig nutzt. „Minimum“ bezieht sich auf den Umfang, nicht auf die Qualität. „Viable“ bedeutet: Es funktioniert, es ist sicher in der Nutzung, und jemand hat genug davon, um wiederzukommen.

Der Zweck eines MVP ist Wissen, nach dem Sie handeln können. Sie prüfen eine kleine Zahl riskanter Annahmen: dass das Problem echt ist, dass Menschen ihre Gewohnheiten ändern, um es zu lösen, und dass jemand dafür zahlt. Jede Funktion, die nicht hilft, diese Annahmen zu prüfen, ist in dieser Phase ein Kostenpunkt ohne Ertrag.

Deshalb ist der beste Maßstab für ein MVP nicht, wie viel es kann, sondern wie klar es die Frage beantwortet, für die es gebaut wurde. Bei Odduel, einer Agentur für Kreation und Technologie in Barcelona und São Paulo, beginnen wir jedes Projekt der App-Entwicklung für ein neues Produkt mit dieser Frage, schriftlich festgehalten, bevor ein einziger Screen entsteht.

Kurz gesagt: Ein MVP ist ein funktionierendes Produkt mit dem kleinsten Umfang, der Ihre riskanteste Annahme bestätigen oder widerlegen kann. Es muss gut genug sein, dass echte Menschen es nutzen, ohne zweimal gebeten zu werden. Es ist ein Schritt hin zu einem Geschäft, keine Demo. Wenn es Ihnen nichts beibringen kann, nach dem Sie handeln, ist es noch kein MVP.

MVP, Prototyp, Proof of Concept oder MLP: Was ist der Unterschied?

Diese vier Begriffe werden oft verwendet, als bedeuteten sie dasselbe. Das tun sie nicht, und sie zu verwechseln, ist einer der häufigsten Gründe, warum erste Versionen zu lange dauern oder zu viel kosten. Jeder beantwortet eine andere Frage für ein anderes Publikum.

	Proof of Concept	Prototyp	MVP	MLP (Minimum Lovable Product)
Frage, die es beantwortet	Lässt sich das bauen?	Ergibt das für Nutzer Sinn?	Werden Menschen es nutzen und bezahlen?	Werden Menschen es lieben und weiterempfehlen?
Wer es sieht	Ihr Team, Investoren	Testnutzer, Stakeholder	Echte Nutzer im Markt	Echte Nutzer in einem umkämpften Markt
Funktioniert es wirklich	Nur der riskante technische Teil	Nein, es sieht nur so aus	Ja, durchgängig	Ja, durchgängig und ausgefeilt
Echte Daten und Konten	Selten	Nein	Ja	Ja
Woraus es besteht	Code, oft zum Wegwerfen	Designdateien, klickbare Screens	Produktionscode	Produktionscode und fertige Marke
Was danach kommt	Ein Prototyp oder die Entscheidung aufzuhören	Ein MVP	Iterationen nach Nutzung	Wachstum und Skalierung

Ein Proof of Concept räumt technische Zweifel aus, etwa ob sich eine Integration oder ein Algorithmus wie erhofft verhält. Ein Prototyp räumt Zweifel am Erlebnis aus: Sie können beobachten, wie Menschen auf klickbaren Screens eine Aufgabe erledigen, bevor es Code gibt. Das MVP ist das Erste, was Sie dem Markt vorlegen.

Das MLP ist eine nützliche Idee, wenn es in Ihrem Markt schon gute Alternativen gibt. Dann reicht „es funktioniert“ nicht, damit jemand wechselt, und ein Teil des ersten Budgets gehört dem Gefühl des Produkts: seiner Marke, seinen Worten und der Sorgfalt im Detail. Viele gute erste Versionen liegen zwischen MVP und MLP: schmal im Umfang, aber fertig in allem, was sie enthalten.

Wie entscheiden Sie, was in ein MVP gehört?

Am Umfang entscheidet sich, ob die meisten ersten Versionen gelingen oder scheitern. Ein Team, das nicht Nein zu Funktionen sagen kann, landet bei einer langsamen, teuren Entwicklung, die nichts klar prüft. Diese Regeln halten den Umfang ehrlich.

Regeln für den Umfang, die halten

1. Ein Nutzer, ein Problem, eine Haupt-Journey. Beschreiben Sie den Nutzer in einem Satz und die Aufgabe, die er erledigen will. Alles in der ersten Version unterstützt diese Journey von Anfang bis Ende.
2. Schreiben Sie zuerst die riskanteste Annahme auf. Lautet der größte Zweifel „Zahlen Restaurants dafür monatlich?“, muss das MVP eine Zahlungsmöglichkeit enthalten, auch wenn der Rest schlicht ist.
3. Handarbeit hinter den Kulissen ist erlaubt. Aufgaben, deren Automatisierung Wochen dauern würde, lassen sich für die ersten Nutzer von Hand erledigen. Automatisieren Sie, sobald Sie wissen, dass die Aufgabe gebraucht wird.
4. Streichen Sie Funktionen, nicht Qualität. Ein kleineres Produkt, das zuverlässig funktioniert, lehrt Sie mehr als ein größeres, das ausfällt. Sicherheit, Barrierefreiheit und Datenumgang sind keine optionalen Extras.
5. Kaufen Sie zu, was Sie nicht unterscheidet. Zahlungen, Anmeldung, E-Mail-Versand und Analyse sind gelöste Probleme. Nutzen Sie bewährte Dienste und investieren Sie Ihr Budget in den Teil, den nur Sie bieten.
6. Jede Funktion nennt ihren Messwert. Können Sie nicht sagen, welche Zahl oder welches Verhalten zeigt, dass eine Funktion wirkt, wartet sie auf eine spätere Version.

Eine einfache Methode: Listen Sie jede Funktion auf, die jemand vorgeschlagen hat, und ordnen Sie jede einer von drei Gruppen zu: „Ohne sie bricht die Journey“, „Sie hilft, aber die Journey funktioniert“ und „Später“. Nur die erste Gruppe kommt ins MVP. Die zweite liefert die ersten Kandidaten für die nächste Version, geordnet danach, was Nutzer tatsächlich verlangen.

Wie läuft die MVP-Entwicklung Schritt für Schritt ab?

Der folgende Ablauf ist der, dem wir bei neuen Produkten folgen. Die Reihenfolge zählt mehr als die Namen der Phasen: Jeder Schritt verringert ein Risiko, bevor Geld in den nächsten fließt.

1. Das Problem fassen und festlegen, was bewiesen werden muss. Schreiben Sie auf, wer der Nutzer ist, was er heute stattdessen tut, warum das mühsam ist und wie Erfolg nach dem Launch aussähe. Einigen Sie sich auf die ein oder zwei Zahlen, die Ihnen sagen, ob Sie weitermachen.
2. Mit Nutzern sprechen, bevor gestaltet wird. Kurze Interviews mit Menschen, die Ihrem Zielnutzer entsprechen, zeigen die Worte, die sie verwenden, die Behelfslösungen, auf die sie sich verlassen, und den Preis, den sie angemessen finden. Günstiger werden Sie nie wieder recherchieren.
3. Die Haupt-Journey aufzeichnen. Zeichnen Sie den Weg vom ersten Besuch bis zu dem Moment, in dem der Nutzer einen Nutzen hat, Schritt für Schritt. Diese Karte wird zum Umfang: Was nicht darauf steht, gehört nicht ins MVP.
4. Prototyp bauen und testen. Machen Sie aus der Journey klickbare Screens und beobachten Sie etwa fünf Menschen dabei, wie sie sie durchlaufen. Beheben Sie, was sie verwirrt. Änderungen kosten hier Stunden; dieselben Änderungen im Code kosten Wochen.
5. Plattform und Technik wählen. Entscheiden Sie zwischen Web-App, nativer App und Cross-Platform-App danach, wo Ihre Nutzer sind und was das Produkt vom Gerät braucht. Unser Leitfaden Unternehmen gründen 2027: die digitalen Grundlagen behandelt die weiteren Entscheidungen, vor denen ein junges Unternehmen steht.
6. In kurzen Zyklen bauen. Arbeiten Sie in Zyklen von ein oder zwei Wochen, die jeweils mit etwas Funktionierendem enden, das Sie ausprobieren können. Hier zahlt sich ein Ansatz aus, der eine feste Discovery mit agilen Entwicklungszyklen verbindet; wir vergleichen die Optionen in Agil vs. Wasserfall bei App- und Website-Projekten.
7. Vor dem Launch mit echten Nutzern testen. Eine geschlossene Gruppe früher Nutzer findet die Fehler und die verwirrenden Momente, die das Team nicht mehr sieht. Prüfen Sie vor allem Barrierefreiheit, Performance auf gewöhnlichen Smartphones sowie die Schritte für Registrierung und Zahlung.
8. Für ein klar definiertes Publikum launchen. Starten Sie mit der Gruppe, die Sie erreichen und von der Sie lernen können, nicht mit allen. Eine fokussierte Landingpage, die das Produkt erklärt und Anmeldungen sammelt, leistet oft mehr als eine breite Kampagne; mehr dazu in unserem Leitfaden Was kostet eine Landingpage?
9. Messen, lernen und entscheiden. Vergleichen Sie die Nutzung mit den Zahlen, die Sie in Schritt eins vereinbart haben. Dann entscheiden Sie: weitermachen und verbessern, die Richtung ändern oder aufhören. Alle drei sind gültige Ergebnisse eines guten MVP.

Wie lange dauert die Entwicklung eines MVP?

Die ehrliche Antwort hängt vom Umfang ab, von der Plattform und davon, wie schnell auf Kundenseite entschieden wird. Mit Sicherheit lässt sich sagen, wie sich die Zeit auf die Phasen verteilt und welche Phasen sich gern dehnen.

Phase	Üblicher Anteil an der Zeit	Was sie meist verlängert
Problemdefinition und Nutzerforschung	Ein kleiner Anteil zu Beginn	Unklare Verantwortung für die Entscheidung
Journey-Mapping und Prototyp	Ein kleiner bis mittlerer Anteil	Zu viele Stakeholder, die Screens prüfen
Entwicklungszyklen	Der größte Anteil	Umfang, der während der Entwicklung hinzukommt, Integrationen mit Drittanbietern
Tests mit frühen Nutzern	Ein mittlerer Anteil	Sonderfälle bei Zahlung und Anmeldung, App-Store-Prüfung
Launch und erste Messung	Eine kurze Phase, dann laufend	Warten auf genug Nutzung, um die Zahlen zu lesen

Zwei Punkte sind wichtig. Erstens: Die Entwicklung ist die längste Phase, aber die Phasen davor entscheiden, wie lange sie dauert; ein getesteter Prototyp und ein fester Umfang verkürzen die Entwicklung stärker als jeder Mehraufwand währenddessen. Zweitens: Native Apps haben einen Schritt, den Websites nicht haben, weil die App Stores jede Version prüfen. Apple veröffentlicht seine Regeln in den App Store Review Guidelines, und eine erste Einreichung kann mit Änderungswünschen zurückkommen; planen Sie das ein.

KI übernimmt in unseren Projekten heute einen großen Teil der wiederkehrenden Produktion: Komponenten des Designsystems, Frontend-Code, erste Textentwürfe, Testfälle und erste Übersetzungsfassungen. Das verkürzt die Entwicklung und senkt ihre Kosten. Strategie, Entscheidungen über den Umfang, die Gestaltung des Erlebnisses und die finale Prüfung jeder Version bleiben menschliche Arbeit, und dort ist die Zeit einer ersten Version am besten investiert.

Was bestimmt die Kosten eines MVP?

Ohne Umfang gibt es keinen ehrlichen Preis. Statt Zahlen finden Sie hier deshalb die Posten eines Angebots und was jeden größer oder kleiner macht. Ein Festpreis folgt auf ein kurzes Briefing, sobald die Haupt-Journey klar ist.

Die Kostenposten

• Discovery und Recherche. Ein Bruchteil des Ganzen, und der Posten, der den Rest am stärksten senkt. Wer ihn auslässt, verschiebt die Kosten meist in die Entwicklung, wo sie höher ausfallen.
• UX- und Interface-Design. Wächst mit der Zahl unterschiedlicher Screens und Zustände, nicht damit, wie ausgefeilt sie aussehen. Ein MLP investiert hier mehr.
• Entwicklung. Der größte Anteil. Er wächst mit der Zahl der Nutzerrollen, dem Umfang der Geschäftslogik und jeder Integration mit einem anderen System.
• Integrationen. Zahlungen, Karten, Kalender, Buchhaltungstools oder eine bestehende Datenbank. Jede braucht eigene Arbeit und Tests, und manche Dienste verlangen eigene Gebühren.
• Tests und Qualität. Wachsen mit der Zahl der Geräte und Browser, die Sie unterstützen müssen, und damit, wie sensibel die Daten sind.
• Infrastruktur und Dienste. Hosting, E-Mail-Versand, Analyse und Monitoring. Anfangs gering; wächst mit der Nutzung.
• Launch und Store-Arbeit. Store-Einträge, Screenshots, eine Landingpage und die erste Einrichtung der Messung.

Was ein MVP teurer macht

Die stärksten Treiber sind, geordnet danach, wie oft wir sie sehen: mehrere Nutzerrollen vom ersten Tag an (etwa Kunden, Mitarbeiter und Administratoren), native Apps auf zwei Plattformen statt einer Web-App, individuelle Arbeit für etwas, das ein bewährter Dienst schon kann, und ein Umfang, der sich während der Entwicklung ändert. Selbst eine neue Geräteklasse wie ein faltbares Smartphone bringt Layouts und Tests in den Umfang einer App.

Wie Sie ein Angebot lesen

Ein gutes Angebot nennt die Journey und die Funktionen, die es abdeckt, was ausgeschlossen ist, die Annahmen dahinter, die Kostenposten oben und wie mit Änderungen umgegangen wird. Vorsicht bei einer einzelnen Zahl ohne Umfang: Sie versteckt entweder eine hohe Marge oder verschiebt die schwierigen Teile auf später. Fragen Sie, was in den ersten Monaten nach dem Launch passiert, denn dort wird das Budget oft vergessen.

Was passiert nach dem Launch des MVP?

Mit dem Launch beginnt der nützliche Teil. In den ersten Wochen beobachtet das Team, wie Menschen das Produkt tatsächlich nutzen: wo sie abspringen, welche Funktionen sie ignorieren, wonach sie in Supportnachrichten fragen. Diese Belege ersetzen Meinungen, wenn Sie entscheiden, was als Nächstes gebaut wird.

Führen Sie eine kurze Liste dessen, was Sie messen, etwa wie viele Registrierungen die Haupt-Journey abschließen, wie viele nach einer Woche wiederkommen und wie viele zahlen. Prüfen Sie sie in festem Rhythmus und planen Sie den nächsten Zyklus um das größte Problem, das die Zahlen zeigen. Beheben Sie Fehler und Verwirrung, bevor Sie Funktionen hinzufügen.

Planen Sie die Arbeit ein, die ein Produkt gesund hält: Sicherheitsupdates, Änderungen der Betriebssysteme auf Smartphones, neue Versionen der Dienste, auf die Sie sich stützen, und Backups. Ein Produkt, das nicht gewartet wird, verliert schnell das Vertrauen seiner ersten Nutzer, und gerade sie sind am schwersten zurückzugewinnen.

Was bedeutet die DSGVO für ein MVP mit Nutzerdaten?

Sobald Menschen Konten anlegen, enthält ein MVP personenbezogene Daten, und die Datenschutz-Grundverordnung, die seit dem 25. Mai 2018 gilt, gilt dafür wie für jedes andere Produkt, das Menschen in der EU nutzen. Klein oder früh zu sein, ändert daran nichts. Die gute Nachricht: Die Grundlagen lassen sich zu Beginn leichter einbauen als später nachrüsten.

1. Erheben Sie nur, was die Journey braucht. Brauchen Sie für die Leistung kein Geburtsdatum und keine Telefonnummer, fragen Sie nicht danach. Das ist der Grundsatz der Datenminimierung.
2. Kennen Sie Ihre Rechtsgrundlage. Für die meisten Kontodaten ist es der Vertrag mit dem Nutzer; für Marketing-E-Mails meist die Einwilligung, freiwillig erteilt und dokumentiert.
3. Schreiben Sie eine verständliche Datenschutzerklärung. Sagen Sie, was Sie erheben, warum, wie lange Sie es speichern, wer es in Ihrem Auftrag verarbeitet und wie Menschen ihre Rechte ausüben können.
4. Schließen Sie Auftragsverarbeitungsverträge. Hosting-, E-Mail-, Analyse- und Zahlungsdienste, die in Ihrem Auftrag personenbezogene Daten verarbeiten, sind Auftragsverarbeiter; mit jedem brauchen Sie einen Vertrag.
5. Sicherheit als Standard. Verschlüsseln Sie Daten bei der Übertragung, speichern Sie Passwörter sachgerecht, beschränken Sie, wer auf Ihrer Seite Nutzerdaten sehen kann, und protokollieren Sie Zugriffe.
6. Machen Sie Rechte praktisch nutzbar. Nutzer müssen ihre Daten einsehen, berichtigen, exportieren und löschen können. Ein einfacher Weg, das anzufragen, zügig bearbeitet, genügt für eine erste Version.
7. Holen Sie vor Trackern die Einwilligung ein. Analyse- und Werbe-Cookies, die nicht unbedingt nötig sind, laden erst, wenn der Nutzer zustimmt.

Dies ist eine allgemeine Information, keine Rechtsberatung. Bei sensiblen Daten wie Gesundheits- oder Finanzdaten oder Daten über Kinder sollte vor dem Launch ein Anwalt das Produkt prüfen.

Checkliste für den Umfang eines MVP

Nutzen Sie diese Liste, bevor die Entwicklung beginnt. Fehlt eine Antwort, ist der Umfang noch nicht bereit.

• Der Zielnutzer ist in einem Satz beschrieben.
• Das Problem und die heutige Behelfslösung sind aufgeschrieben.
• Die riskanteste Annahme ist benannt, und das MVP prüft sie direkt.
• Die Haupt-Journey ist vom ersten Besuch bis zum Moment des Nutzens aufgezeichnet.
• Jede Funktion ist markiert mit „Ohne sie bricht die Journey“, „Hilft“ oder „Später“.
• Der Prototyp wurde mit echten Menschen getestet und verbessert.
• Die Wahl der Plattform (Web, nativ, Cross-Platform) ist begründet.
• Zahlungen, Anmeldung und E-Mail laufen über bewährte Dienste.
• Jede Funktion im Umfang nennt den Messwert, der zeigt, dass sie wirkt.
• Es werden nur die personenbezogenen Daten erhoben, die die Journey braucht, mit Datenschutzerklärung und Auftragsverarbeitungsverträgen.
• Barrierefreiheit und Performance auf gewöhnlichen Smartphones gehören zu den Tests.
• Die zwei oder drei Zahlen für den Launch und der Termin der Auswertung sind vereinbart.
• Auf Kundenseite trifft jemand jede Woche die Entscheidungen.
• Es gibt ein Budget und einen Plan für die Monate nach dem Launch.

Häufige Fragen zur Agenturwahl

Haben Sie eine Idee und wollen daraus eine erste Version machen, die Menschen nutzen und bezahlen, beginnen Sie mit einem kurzen Briefing: wer der Nutzer ist, was das Problem ist und was Sie lernen müssen. Wir helfen Ihnen, den Umfang festzulegen, ihn zu testen und das Produkt zu bauen. Sehen Sie sich an, wie wir bei der App-Entwicklung arbeiten, oder erzählen Sie uns von Ihrem Produkt.

Weiterlesen: Native oder Cross-Platform-App: Flutter, React Native oder nativ, Kosten der SaaS-Entwicklung 2027: Aufschlüsselung nach Phasen, App-Entwicklung: von der Idee bis in den Store, Wie lange dauert die Entwicklung einer App? Ein realistischer Zeitplan, Agentische KI oder generative KI: Was beide für ein Unternehmen leisten können.