Wenn Sie hier gelandet sind, fragen Sie sich wahrscheinlich, was ein MVP ist und ob es sich wirklich lohnt, eines zu bauen, bevor Sie Ihr komplettes Produkt entwickeln. Die Kurzfassung: Ein MVP (Minimum Viable Product, auf Deutsch etwa „minimal funktionsfähiges Produkt“) ist die kleinstmögliche Version Ihres Produkts, mit der Sie prüfen, ob Ihre Idee einen Markt hat – ohne das Budget der nächsten zwei Jahre in etwas zu stecken, das womöglich niemand will.
Ich sehe seit mehr als zehn Jahren zu, wie Startups in Spanien an den Start gehen. Die, die das erste Jahr überleben, haben meist etwas gemeinsam: Sie haben früh gelauncht, unfertig gelauncht und dabei auf die Nutzer gehört. Die, die scheitern, sind fast immer diejenigen, die 14 Monate für die „finale Version“ gebraucht haben und dann, als das Geld schon weg war, feststellten, dass die Kunden etwas anderes wollten.
In diesem Artikel erkläre ich Ihnen, was ein MVP wirklich ist (nicht die Lehrbuchversion), warum es ein teurer Fehler ist, darauf zu verzichten, wie Sie es angehen, wenn Sie Ihr Startup-MVP dieses Jahr launchen, und welche Signale zeigen, dass Sie bereit zum Skalieren sind. Ohne Füllstoff.
Was genau ist ein MVP (und was nicht)?
Klären wir das, denn hier herrscht viel Verwirrung. Ein Minimum Viable Product ist die einfachste Version Ihres Produkts, die einem Nutzer echten Mehrwert liefert und vor allem validiertes Lernen ermöglicht. Die ursprüngliche Definition stammt von Eric Ries aus The Lean Startup. Das Buch hat einige Jahre auf dem Buckel, aber die Grundidee gilt unverändert: nur das bauen, was nötig ist, um die riskantesten Fragen Ihres Geschäftsmodells zu beantworten.
Achtung, denn hier irren sich fast alle: Ein MVP ist keine Demo, keine Landingpage mit Formular und kein Wireframe in Figma. Es ist auch nicht „Version 1.0 mit weniger Funktionen“. Ein MVP muss von echten Menschen unter echten Bedingungen nutzbar sein und Ihnen erlauben, Konkretes zu messen: Nutzen sie es? Empfehlen sie es weiter? Zahlen sie dafür? Springen sie am dritten Tag ab?
Der Unterschied zwischen MVP, Prototyp und Proof of Concept (PoC)
Diese Begriffe werden ständig verwechselt. Ein Prototyp ist ein visuelles oder interaktives Modell, mit dem Sie Design oder Ablauf testen, meist ohne funktionierenden Code dahinter. Ein Proof of Concept (PoC) zeigt, dass etwas technisch machbar ist („Ja, wir können Holded mit dieser Logistik-API verbinden“). Ein MVP ist bereits ein Produkt, das ein Kunde wirklich nutzen kann, auch wenn es nur die nötigsten Funktionen hat und das Design noch Luft nach oben lässt.
Wenn Sie nur einen Kaufprozess testen wollen, reicht vielleicht ein Prototyp in Figma. Wenn Sie wissen wollen, ob Menschen dafür zahlen, brauchen Sie ein MVP. Der Unterschied ist enorm und schlägt sich direkt im Budget nieder.
Warum der Verzicht auf ein MVP der teuerste Fehler eines Startups ist
Jetzt kommt das Wichtige. Wenn Gründer das MVP überspringen, hat das meist einen von zwei Gründen: Entweder sind sie in ihre Idee verliebt („Ich weiß doch, was der Kunde will“), oder ein ungeduldiger Investor verlangt „sofort etwas Professionelles“. Beides sind schlechte Ratgeber.
Mehrere Branchenstudien zum Scheitern von Startups (CB Insights, Failory) kommen übereinstimmend zu dem Ergebnis, dass 35 % bis 42 % der Projekte aus demselben Grund scheitern: Es gibt keinen Markt für das, was sie gebaut haben. Nicht wegen fehlender Finanzierung, nicht wegen eines schlechten Teams, nicht wegen der Konkurrenz. Sie haben etwas gebaut, das niemand kaufen wollte. Und genau das soll ein MVP verhindern.
Ohne MVP zu launchen ist, als würden Sie ein Restaurant mit 200 Plätzen eröffnen, ohne je für mehr als 10 Personen gekocht zu haben. Kann gut gehen. Statistisch gesehen geht es nicht gut.
Eine Routenplanungsplattform kann eine App für Fahrer, eine Verwaltungsoberfläche, eine ERP-Anbindung und Analysen umfassen. Alles zu bauen, bevor die Nachfrage bestätigt ist, ist riskant: Mit einem MVP prüfen Sie zuerst, was die Nutzer brauchen und ob sie bereit sind, dafür zu zahlen.
So legen Sie den Umfang Ihres Minimum Viable Product fest
Hier bleiben die meisten hängen. Die Frage lautet nicht „Was baue ich ein?“, sondern „Was lasse ich weg?“. Und das tut weh, weil jede einzelne Funktion unverzichtbar wirkt. Fast nie ist sie es.
Am besten funktioniert meiner Erfahrung nach die Methode, bei der riskantesten Annahme anzusetzen. Setzen Sie sich mit Ihrem Team zusammen und beantworten Sie: Was muss stimmen, damit dieses Geschäft funktioniert? Wenn Sie am meisten fürchten, dass niemand zahlt, braucht Ihr MVP vom ersten Tag an einen echten Zahlungsanbieter (Stripe, Redsys oder was auch immer passt). Wenn Sie am meisten die Akzeptanz fürchten, reicht vielleicht eine Landingpage mit Warteliste und Kampagnen über LinkedIn Ads.
Der Drei-Fragen-Test
Prüfen Sie jede Funktion, die ins MVP soll, mit diesen drei Fragen:
- Ist sie unverzichtbar, damit der Nutzer den Kernnutzen erhält? Wenn nicht: raus.
- Ist die Annahme, die sie validiert, unsere riskanteste? Wenn nicht: raus (zumindest vorerst).
- Können wir ohne sie launchen und sie in Iteration 2 ergänzen? Wenn ja: raus.
Konsequent angewendet, kommt ein typisches B2B-SaaS-MVP in Spanien mit Registrierung, Login, der Kernfunktion (nur einer), einem Zahlungsanbieter und einem einfachen Admin-Bereich aus. Vergessen Sie Rollen, erweiterte Berechtigungen, Mehrsprachigkeit, Dark Mode und PDF-Export. Das ist etwas für Version 1.5.
Was ein Startup-MVP in Spanien kostet
Das Budget eines MVP hängt von der Annahme ab, die Sie validieren wollen, von den wesentlichen Funktionen und von den Schnittstellen. Fordern Sie ein Angebot mit festem Umfang an, das die erste Validierung von der späteren Weiterentwicklung trennt.
Der Preis hängt vor allem von drei Faktoren ab: ob Sie eine native App brauchen (iOS + Android kostet etwa das 1,8-Fache einer PWA), wie komplex die Integrationen sind (die Anbindung an das spanische Finanzamt für Veri*Factu, das neue spanische Pflichtsystem für Rechnungssoftware, an Bank-Gateways oder an ERP-Systeme wie Sage 50 oder Odoo kostet zusätzliche Stunden) und welches Niveau an UX-Design Sie benötigen.
Der Zeitfaktor, über den kaum jemand spricht
Ein gut geplantes MVP ist in etwa 6 Wochen entwickelt. Wenn Ihnen jemand eines in 3 Wochen verspricht, seien Sie skeptisch: Entweder hat er den Code schon fertig und verwertet ihn für Sie wieder, oder Sie bekommen etwas Unbrauchbares. Wenn von 7 Monaten die Rede ist, ist das kein MVP mehr, sondern ein Produkt.
Für Gründer mit knappem Budget: Starten Sie lieber mit individuellen Webanwendungen statt mit einer nativen App. Sie funktionieren auf dem Smartphone, Sie müssen nicht durch die App Stores, und Kosten und Zeitaufwand halbieren sich. Skalieren können Sie, sobald die Idee validiert ist.
Geschäftsidee validieren: Was Sie vor und nach dem Launch messen sollten
Ein MVP ohne klare Kennzahlen zu launchen ist, als würden Sie sich ohne Waage wiegen und sagen: „Ich glaube, es geht mir besser.“ Ziel der Validierung ist nicht „mal sehen, ob es sich verkauft“, sondern konkrete Fragen mit Daten zu beantworten, die Sie formuliert haben, bevor die erste Zeile Code geschrieben wurde.
Die Kennzahlen, die bei einem MVP wirklich zählen, nach Wichtigkeit geordnet:
- Aktivierung: Welcher Anteil der registrierten Nutzer erreicht den „Aha-Moment“ (den Moment, in dem sie den Nutzen zum ersten Mal verstehen)? Unter 25–30 % haben Sie ein Problem beim Onboarding oder beim Nutzenversprechen.
- Retention in Woche 1 und Woche 4: Wie viele der aktivierten Nutzer kommen wieder? Das ist die Königskennzahl. Liegt die W4-Retention bei B2B-SaaS unter 15–20 %, stimmt etwas nicht.
- Zahlungsbereitschaft: Validieren Sie einen echten Abschluss zu klaren Konditionen, nicht nur das Interesse, das jemand im Interview äußert.
- NPS und qualitatives Feedback: 10 Gespräche mit echten Nutzern sagen Ihnen mehr als 500 Umfragen.
Wenn Ihr MVP die Frage „Würden diese Leute für die Vollversion bezahlen?“ nicht mit Daten beantwortet, ist es kein MVP, sondern ein ästhetisches Experiment.
Kurios ist, dass viele Gründer sich auf Eitelkeitskennzahlen (Besuche, Downloads, Follower) stürzen und den wichtigen Kennzahlen ausweichen, weil genau die wehtun, wenn sie schlecht ausfallen. Mein Rat: Richten Sie das Kennzahlen-Dashboard vor dem Launch ein. Wenn Sie es auf später verschieben, machen Sie es nie.
Typische Fehler beim MVP-Launch (und wie Sie sie vermeiden)
Von den Fehlern, die ich bei Gründern immer wieder sehe, die nach eigenen Versuchen zu uns kommen, hier die fünf teuersten:
1. Funktionen „für alle Fälle“ einbauen
Der Klassiker. „Wenn wir schon dabei sind, bauen wir gleich das Rechnungsmodul mit ein, der Kunde wird es sowieso wollen.“ Nein, der Kunde fragt erst in drei Monaten danach, und bis dahin wissen Sie, ob er überhaupt kauft. Jede zusätzliche Funktion kostet zusätzliche Wochen und verbranntes Geld.
2. Ein MVP mit einem hübschen Prototyp verwechseln
Drei Monate lang das Design in Figma polieren, ohne eine Zeile Code zu schreiben. Am Ende haben Sie eine wunderschöne Idee und null Marktvalidierung. Design ist wichtig, aber beim MVP ist wichtiger, dass es funktioniert und jemand es nutzt.
3. Vor dem Bauen nicht mit Nutzern sprechen
Vorab-Interviews mit potenziellen Kunden helfen, das MVP zu konkretisieren. Planen Sie Zeit ein, um nach ihren Problemen, ihren aktuellen Tools und ihrem Kaufentscheidungsprozess zu fragen.
4. Den spanischen Rechtsrahmen vergessen
Impressum, Datenschutzerklärung nach DSGVO und spanischem Datenschutzgesetz (LOPDGDD), Cookies, AGB, wenn Sie Geld verlangen. Wenn Sie in Spanien Rechnungen stellen, muss Ihr MVP auch Veri*Factu erfüllen, sobald es für Ihren Fall verpflichtend wird. Das ist nicht optional und nicht „für später“.
5. Skalieren wollen, bevor es Traktion gibt
Wenn Ihr MVP anfängt zu funktionieren (Glückwunsch, damit gehören Sie zur Minderheit), ist die Versuchung groß, alles als Microservices-Architektur neu zu schreiben. Widerstehen Sie. Bestätigen Sie zuerst mit Zahlen, dass das Wachstum nachhaltig ist, und denken Sie dann an die Entwicklung eines skalierbaren SaaS. Andersherum ist es der schnellste Weg, am Erfolg zugrunde zu gehen, ohne je Erfolg gehabt zu haben.
Vom MVP zum Produkt: wann und wie Sie den Sprung schaffen
Jetzt kommt die Phase, die kaum jemand gut erklärt. Ihr MVP läuft, die ersten 30–100 Nutzer zahlen, die Retention-Kennzahlen sind ordentlich. Und jetzt?
Der Sprung vom MVP zum echten Produkt passiert nicht an einem bestimmten Tag. Es ist eine Übergangsphase, die meist 3 bis 9 Monate dauert. Ich empfehle, an drei Fronten gleichzeitig zu arbeiten, aber keine davon zu beschleunigen, bevor es klare Signale gibt:
- Refaktorieren, was bricht: MVP-Code enthält meist Abkürzungen. Das ist normal. Während Sie skalieren, erkennen Sie die technischen Engpässe und lösen sie nach und nach. Schreiben Sie nicht alles auf einmal neu.
- Die meistgewünschten Funktionen ergänzen, nicht die auffälligsten: Sortieren Sie das Nutzerfeedback nach Häufigkeit und nach Wirkung auf die Retention. Beide Kennzahlen. Was nicht auf dieser Liste steht, wird nicht gebaut.
- Den Betrieb vorbereiten: Support, wiederkehrende Abrechnung mit Stripe oder GoCardless (in Spanien verbreiteter, als man denkt), teilautomatisiertes Onboarding, Dokumentation. Das wird oft vernachlässigt, und das merkt man an der Abwanderungsrate (Churn).
Ein Signal, das ich als Kriterium für die Skalierungsreife sehr schätze: Wenn Sie seit 3 Monaten organisch wachsen (ohne Ausgaben für Kundengewinnung) und die monatliche Retention über 80 % liegt, haben Sie Product-Market-Fit. Wenn nicht, sind Sie noch in der MVP-Phase, auch wenn schon ein Jahr vergangen ist. Und das ist in Ordnung: Besser, Sie erkennen das an, als die Skalierung zu erzwingen.
Wenn Sie sich nur eine Sache merken, dann diese: Ein MVP ist keine billige Version Ihres Produkts, sondern der günstigste und schnellste Weg herauszufinden, ob das, was Sie im Kopf haben, jemanden interessiert, der auch bereit ist, dafür zu zahlen. Punkt. Alles andere (die perfekte App, das Premium-Design, die 40 Funktionen) kommt später, wenn Sie wissen, dass Sie nicht auf Sand bauen.
Mein Rat nach etlichen Projekten: Investieren Sie mehr Zeit in die Definition der Annahmen und Kennzahlen, die Sie messen wollen, als in die Diskussion, ob der Button oben oder unten sitzt. Launchen Sie in 6 Wochen etwas Unfertiges, aber Funktionierendes, stellen Sie es echten Nutzern vor, hören Sie zu (vor allem: hören Sie zu) und iterieren Sie erneut. Wenn Sie Ihr erstes Startup gründen, erspart Ihnen diese Arbeitsweise Ärger, Geld und – das Wertvollste – Monate Ihres Lebens.
Und wenn Sie Ihren konkreten Fall besprechen möchten, bevor Sie loslegen: Bei Interconecta begleiten wir Gründer bei der Definition ihres MVP, ohne ihnen leere Versprechen zu verkaufen. Manchmal ist das Nützlichste, was wir Ihnen sagen können, dass Sie noch gar nichts entwickeln müssen.