Prototyp, Proof of Concept oder MVP: Was braucht das Projekt?

„Wir brauchen mal schnell ein MVP.” Wenn dieser Satz in einem Projektgespräch fällt, lohnt eine Rückfrage: Meint ihr ein klickbares Modell für die Geschäftsführung, einen Technik-Test mit euren echten Daten – oder eine Software, die ab nächstem Quartal täglich im Einsatz ist? Das sind drei völlig verschiedene Vorhaben mit verschiedenen Kosten, Laufzeiten und Ergebnissen. Und genau diese Vermischung ist einer der häufigsten Gründe, warum Digitalprojekte in kleinen und mittleren Unternehmen enttäuschen: Bestellt wurde ein Experiment, erwartet wurde ein Produkt.

Dieser Artikel gehört zu unserem Themen-Cluster KI-Softwareentwicklung und klärt die drei Begriffe so, dass du sie im nächsten Angebot, Kick-off oder Budgetgespräch sauber verwenden kannst: Was ein Prototyp ist, was ein Proof of Concept prüft, was ein MVP nutzbar macht, wie sich Kosten und Dauer unterscheiden – und welches Format zu welcher Art von Unsicherheit passt.

Das Problem: Ein Wort für drei verschiedene Dinge

Der Schaden durch vermischte Begriffe ist konkret und kommt in zwei Varianten.

Variante 1: Der PoC, der plötzlich Produkt sein soll. Ein Team baut in drei Wochen einen technischen Machbarkeitsnachweis – etwa: „Kann ein Sprachmodell unsere Lieferantenrechnungen zuverlässig genug auslesen?” Die Demo überzeugt, die Geschäftsführung fragt: „Super, wann rollen wir das aus?” Nur: Der PoC hat keine Benutzerverwaltung, keine Fehlerbehandlung, keine Datenschutz-Prüfung, keinen Betrieb. Der Weg von der Demo zum betreibbaren Werkzeug ist oft der größere Teil der Arbeit – und der war nie beauftragt. Ergebnis: Enttäuschung auf beiden Seiten.

Variante 2: Das „MVP”, das keines ist. Ein Dienstleister liefert nach Monaten ein „MVP”, das in Wahrheit ein Prototyp ist: Es sieht fertig aus, aber die Hälfte der Buttons führt ins Leere, und produktiv nutzen kann es niemand. Oder das Gegenteil: Das „MVP” ist ein überladenes Erstprodukt, in dem ein Jahr Entwicklungszeit steckt, bevor der erste echte Nutzer es gesehen hat – womit der eigentliche Zweck eines MVP, früh aus echtem Verhalten zu lernen, verfehlt ist.

Beide Varianten haben dieselbe Wurzel: Es wurde nicht geklärt, welche Frage das Vorhaben beantworten soll. Genau dafür sind die drei Begriffe da – sie stehen für drei verschiedene Fragen, nicht für drei Reifegrade desselben Dings.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU – also an die Seite, die solche Vorhaben beauftragt, budgetiert und abnimmt.

Begriffe und Abgrenzung: Drei Fragen, drei Formate

Bevor wir in die Tiefe gehen, die Kurzfassung. Jedes Format beantwortet eine andere Leitfrage:

• Prototyp – „Verstehen und wollen Nutzer das so?” Ein bewusst unfertiges Anschauungs- und Testmodell, das Konzept und Bedienung erlebbar macht. Muss nicht funktionieren.
• Proof of Concept (PoC) – „Geht das technisch überhaupt?” Ein kleines, abgegrenztes Experiment, das eine kritische Machbarkeitsannahme belegt oder widerlegt. Muss funktionieren, aber nur im Labor.
• MVP (Minimum Viable Product) – „Nutzen Menschen das wirklich, und lernen wir daraus?” Die kleinste Produktversion, die echte Nutzer produktiv einsetzen können. Muss im Alltag funktionieren – für einen bewusst schmalen Anwendungsfall.

Zwei Klarstellungen, die in der Praxis viel Verwirrung ersparen:

Erstens: Die drei Formate sind keine Pflicht-Stufenleiter. Nicht jedes Projekt braucht alle drei. Ein internes Tool auf bewährter Technik braucht selten einen PoC; ein Projekt mit klarer Nutzerakzeptanz braucht vielleicht keinen ausgefeilten Prototyp. Du wählst das Format nach der Unsicherheit, die du ausräumen musst – dazu unten mehr.

Zweitens: „Fertig aussehen” und „fertig sein” sind unabhängige Eigenschaften. Ein Prototyp kann täuschend echt aussehen und trotzdem nichts können; ein PoC kann technisch beeindrucken und trotzdem meilenweit vom Produkt entfernt sein. Gerade KI-gestützte Entwicklung hat diese Lücke vergrößert: Ansehnliche Oberflächen und Demos entstehen heute in Tagen. Das ist ein echter Vorteil – aber nur, wenn alle Beteiligten wissen, dass eine gute Demo noch kein Produkt ist.

Was ist ein Prototyp?

Ein Prototyp ist ein Modell deines Produkts, das genau so viel zeigt, wie nötig ist, um eine Design-Entscheidung zu testen. Die Nielsen Norman Group bringt es auf den Punkt: Ein Prototyp ist eine Hypothese – ein Lösungskandidat für ein konkretes Designproblem, den du mit echten Nutzern überprüfst, bevor teurer Code entsteht. Der ökonomische Kern dahinter: Einen Prototyp zu verwerfen kostet fast nichts, fertigen Code zu verwerfen kostet viel.

Prototypen unterscheiden sich in ihrer Fidelity, also darin, wie nah sie am fertigen System sind – und zwar laut NN/g auf drei unabhängigen Achsen: Interaktivität (von statisch bis voll klickbar), Optik (von Skizze bis pixelgenau) und Inhalt (von Platzhaltertext bis echten Daten). Daraus ergibt sich ein Spektrum:

• Low-Fidelity: Papierskizzen, Whiteboard-Abläufe, grobe Wireframes. Stärken: in Stunden erstellt, während eines Tests änderbar, niemand hängt emotional daran, und Feedback fällt ehrlicher aus, weil erkennbar nichts „fertig” ist.
• High-Fidelity: Klickbare Oberflächen, die sich fast wie das echte Produkt anfühlen. Stärken: realistische Reaktionen, konkrete UI-Entscheidungen testbar, gut geeignet, um Stakeholdern das Zielbild zu zeigen.

Wichtig für dich als Auftraggeber: Ein Prototyp liefert keine belastbare Aussage über technische Machbarkeit, Datenqualität oder Betriebskosten. Er beantwortet ausschließlich Fragen zu Verständlichkeit, Bedienung und Akzeptanz. Wenn ein klickbarer Prototyp im Meeting begeistert, ist das ein gutes Zeichen für das Konzept – und keinerlei Beleg dafür, dass die dahinterliegende Automatisierung mit euren echten Daten funktioniert.

Was prüft ein Proof of Concept?

Ein Proof of Concept prüft, ob eine Idee, eine Methode oder eine Technologie technisch machbar und tragfähig ist – als kleinformatige Demonstration, bevor nennenswerte Ressourcen in die eigentliche Entwicklung fließen. So beschreibt es auch Atlassian in seinem PoC-Leitfaden: Zweck ist, Risiken früh sichtbar zu machen, Schwachstellen und technische Hürden zu identifizieren und Stakeholdern eine belastbare Entscheidungsgrundlage zu geben. Ein PoC darf dabei ausdrücklich zum Ergebnis kommen, dass ein Vorhaben angepasst oder verworfen werden sollte – das ist kein Scheitern, sondern genau seine Funktion.

Ein guter PoC hat drei Eigenschaften:

1. Eine konkrete, falsifizierbare Annahme. Nicht „Wir testen mal KI”, sondern: „Das Modell ordnet mindestens einen definierten Anteil unserer Support-Mails der richtigen Kategorie zu – gemessen an einem Testdatensatz, den der Fachbereich vorher abgenommen hat.” Die Erfolgskriterien stehen fest, bevor gebaut wird.
2. Einen bewusst engen Scope. Alles, was nicht zur Beantwortung der Machbarkeitsfrage nötig ist – Benutzerverwaltung, schöne Oberfläche, Randfälle – bleibt weg. Ein PoC, der nebenbei hübsch werden soll, ist meistens beides nur halb.
3. Ein Verfallsdatum. Der Code eines PoC ist Labormaterial. In meiner Arbeit gilt die Regel: PoC-Code wird nicht „weiterverwendet und aufgeräumt”, sondern das Gelernte fließt in eine saubere Umsetzung. Der Versuch, aus PoC-Code direkt ein Produkt zu ziehen, ist eine der zuverlässigsten Quellen technischer Schulden.

Gerade bei KI-Vorhaben ist der PoC oft der wichtigste Schritt überhaupt, weil die zentrale Unsicherheit dort selten das Interface ist, sondern die Frage: Ist das Verfahren auf unseren echten Daten gut genug? Diese Frage lässt sich weder mit einem Prototyp noch mit Anbieterfolien beantworten – nur mit einem Experiment auf euren Daten, gegen vorher definierte Kriterien.

Was macht ein MVP nutzbar?

Der Begriff MVP stammt aus dem Lean-Startup-Umfeld. Eric Ries’ Original-Definition: Das Minimum Viable Product ist „diejenige Version eines neuen Produkts, die es einem Team erlaubt, mit dem geringsten Aufwand die maximale Menge an validiertem Lernen über Kunden zu sammeln”. Zwei Dinge daran werden regelmäßig überlesen:

Erstens: Das MVP ist ein Lerninstrument, kein Sparprogramm. Der Maßstab ist nicht „so billig wie möglich”, sondern „maximales validiertes Lernen pro eingesetztem Aufwand”. Validiertes Lernen heißt: Du beobachtest, was echte Nutzer mit dem Produkt tun – nicht, was sie in einer Umfrage sagen, dass sie tun würden. Die Agile Alliance betont in ihrem Glossar genau diesen Punkt: Ein MVP ist ein echtes, den Nutzern übergebenes Produkt, an dessen tatsächlichem Verhalten das Team entscheidet, ob es weitermacht, umsteuert oder abbricht. Ries selbst weist zudem darauf hin, dass ein MVP sogar Mehraufwand bedeutet, weil Messung und Auswertung dazugehören – wer nur baut und nie auswertet, hat kein MVP, sondern nur ein kleines Produkt.

Zweitens: „Viable” ist keine Verzierung. Die Agile Alliance nennt es als häufiges Missverständnis, Minimalismus über Tragfähigkeit zu stellen und schlicht ein schlechtes Produkt auszuliefern. Nutzbar – und damit MVP-tauglich – ist eine Version erst, wenn sie einen kompletten Anwendungsfall zuverlässig abdeckt. Dazu gehören die unspektakulären Teile, die in Prototyp und PoC bewusst fehlen:

• Ein echter, durchgängiger Kernprozess (lieber einer ganz als fünf halb)
• Umgang mit Fehlern: ungültige Eingaben, ausgefallene Schnittstellen, das falsch formatierte Excel
• Zugriffskontrolle und Datenschutz auf dem Niveau, das eure Daten erfordern
• Betrieb: Hosting, Backups, Monitoring, ein Weg, Fehler zu melden und Updates einzuspielen
• Genug Benutzerführung, dass die Zielgruppe ohne Schulungsmarathon arbeiten kann

Im B2B- und KMU-Kontext heißt „Markt” übrigens oft: die eigenen Mitarbeitenden oder eine Handvoll Pilotkunden. Ein internes Abrechnungstool, das drei Personen zwei Wochen lang produktiv nutzen, ist ein vollwertiges MVP – die Logik des validierten Lernens gilt dort genauso. Mehr dazu im Cluster KI-Softwareentwicklung.

Vergleichsmatrix: Prototyp, PoC und MVP im Überblick

Die folgende Matrix ist mein Arbeitswerkzeug aus Kundenprojekten – nutze sie, um im nächsten Projektgespräch zu klären, worüber ihr eigentlich redet:

Kriterium	Prototyp	Proof of Concept	MVP
Leitfrage	Verstehen und wollen Nutzer das so?	Geht das technisch überhaupt?	Wird es real genutzt, und was lernen wir daraus?
Getestete Unsicherheit	Konzept, Bedienung, Akzeptanz	Machbarkeit, Datenqualität, Integration	Nutzen im Alltag, Zahlungs-/Nutzungsbereitschaft
Muss funktionieren?	Nein – darf simuliert sein	Ja, aber nur im Laborrahmen	Ja, im echten Betrieb
Echte Nutzer, echte Daten?	Nutzer ja (Tests), Daten meist nein	Daten ja (Stichprobe), Nutzer nein	Beides ja
Typisches Ergebnis	Überarbeitetes Konzept, Design-Entscheidung	Belegte oder widerlegte Annahme, Go/No-Go	Messbares Nutzungsverhalten, Weiter/Umsteuern/Stopp
Lebensdauer des Artefakts	Wird verworfen	Wird verworfen (Erkenntnis bleibt)	Wird weiterentwickelt
Typische Fehlverwendung	Wird für „fast fertig” gehalten	Soll „schnell noch” Produkt werden	Wird zum überladenen Erstrelease aufgeblasen
Abnahmekriterium	Testnutzer kommen ohne Hilfe durch den Kernablauf	Vorher definierte Messlatte erreicht/verfehlt	Kernprozess läuft produktiv, Nutzung wird gemessen

Eigene Entscheidungsmatrix Philogic Labs, abgeleitet aus Beratungs- und Umsetzungsprojekten; Begriffsbasis: Ries, Agile Alliance, NN/g, Atlassian (siehe Quellen).

Wie unterscheiden sich Kosten und Dauer?

Ehrliche Vorbemerkung: Seriöse Pauschalpreise gibt es hier nicht, und Studien mit belastbaren Durchschnittskosten für „ein MVP” sind mit Vorsicht zu genießen – zu unterschiedlich sind Scope, Branche und Integrationsaufwand. Was ich stattdessen anbieten kann, sind Bandbreiten aus meiner eigenen Projektpraxis mit den Annahmen, unter denen sie gelten:

• Klick-Prototyp: typischerweise Tage bis wenige Wochen. Annahmen: ein Kernablauf, Standard-Designwerkzeuge oder KI-gestützte UI-Erstellung, Feedbackrunden mit einer Handvoll Testnutzern eingerechnet.
• Proof of Concept: typischerweise zwei bis sechs Wochen. Annahmen: eine klar formulierte Machbarkeitsfrage, Testdaten sind verfügbar und dürfen genutzt werden, Erfolgskriterien stehen vor Beginn fest. Verzögerungen entstehen hier fast nie durch Technik, sondern durch Datenbeschaffung und Freigaben.
• MVP: typischerweise sechs Wochen bis wenige Monate. Annahmen: ein einziger durchgängiger Kernprozess, überschaubare Schnittstellen (ein bis zwei Systeme), Betrieb auf Standard-Cloud-Infrastruktur, keine besonderen Zertifizierungsanforderungen. Jede zusätzliche Integration, jede Sonderrolle im Berechtigungskonzept und jede regulatorische Anforderung verschiebt das obere Ende.

Die wichtigere Erkenntnis als jede Zahl: Der große Kostensprung liegt zwischen PoC und MVP. Vom Prototyp zum PoC wächst vor allem der Technikanteil; vom PoC zum MVP kommen die Dinge dazu, die man in Demos nie sieht – Fehlerbehandlung, Sicherheit, Betrieb, Datenmigration, Benutzerführung. Wer ein PoC-Budget freigibt und ein Produkt erwartet, unterschätzt das Vorhaben meist um ein Mehrfaches. Umgekehrt gilt: Ein PoC ist die günstigste Versicherung gegen das teuerste Szenario – monatelang das falsche Produkt zu bauen.

KI-gestützte Entwicklung verschiebt diese Bandbreiten real nach unten, aber ungleichmäßig: Prototypen und PoCs sind heute drastisch schneller machbar als noch vor wenigen Jahren. Beim MVP schrumpft vor allem die Bauzeit – Anforderungsklärung, Datenfragen, Freigaben und Betrieb schrumpfen nicht im gleichen Maß.

Was passt zu welcher Unsicherheit?

Die eigentliche Entscheidungsregel ist einfach: Benenne die größte Unsicherheit deines Vorhabens – und wähle das billigste Format, das genau diese Unsicherheit ausräumt.

Deine größte Unsicherheit klingt so …	… dann brauchst du	Warum
„Ich weiß nicht, ob unsere Leute / Kunden das verstehen und annehmen.”	Prototyp	Akzeptanz und Bedienung testest du am billigsten am Modell – nicht am fertigen Produkt.
„Ich weiß nicht, ob das mit unseren Daten/Systemen technisch funktioniert.”	PoC	Machbarkeit klärt nur ein Experiment mit echten Daten gegen definierte Kriterien.
„Technik und Konzept scheinen klar – aber wird es im Alltag wirklich genutzt?”	MVP	Echtes Nutzungsverhalten siehst du nur im echten Betrieb.
„Eigentlich ist alles klar, wir wollen nur klein anfangen.”	MVP (oder direkt Phase 1 des Produkts)	Ohne echte Unsicherheit brauchst du kein Experiment, sondern einen sauber geschnittenen ersten Ausbauschritt.
„Unklar ist ehrlich gesagt alles.”	Erst Gespräch, dann Prototyp oder PoC	Wenn Problem und Zielgruppe unscharf sind, ist Bauen – egal was – noch verfrüht.

Sind mehrere Unsicherheiten offen, räume sie in der Reihenfolge der Ausräumkosten aus – meist: Prototyp vor PoC vor MVP, weil ein verworfenes Konzept billiger ist als ein verworfenes Experiment, und beides billiger als ein verworfenes Produkt. Aber erzwinge die Kette nicht: Bei einem KI-Vorhaben mit klarer Nutzerakzeptanz, aber fraglicher Datenlage ist der PoC der richtige erste Schritt, kein Klickmodell.

Umsetzung: So beauftragst du das richtige Format

Aus Auftraggebersicht entscheidet sich der Projekterfolg oft schon vor der ersten Zeile Code. Vier Dinge, die ich in jedem Vorhaben festhalte:

1. Die Frage schriftlich fixieren. Ein Satz: „Dieses [Prototyp/PoC/MVP] beantwortet die Frage X.” Wenn dieser Satz nicht formulierbar ist, ist das Vorhaben noch nicht reif für die Umsetzung.
2. Erfolgskriterien vor Baubeginn definieren. Beim Prototyp: Welche Abläufe müssen Testnutzer ohne Hilfe schaffen? Beim PoC: Welche Messlatte auf welchem Testdatensatz? Beim MVP: Welche Nutzung in welchem Zeitraum gilt als Erfolg, und was folgt aus einem Misserfolg?
3. Das Danach vorab klären. Was passiert mit dem Artefakt? Prototyp und PoC werden verworfen – das gehört ins Angebot, damit später niemand „den PoC schnell produktiv nehmen” will. Beim MVP gehört umgekehrt geklärt: Wer betreibt es, wer wertet die Nutzung aus, wann wird über Ausbau entschieden?
4. Beim MVP den Scope aktiv verteidigen. Die größte Gefahr für ein MVP ist nicht zu wenig Funktionsumfang, sondern zu viel. Jede Anforderung muss die Frage beantworten: Brauchen wir das, um zu lernen, ob das Produkt trägt? Wenn nein: Phase 2.

Wenn du unsicher bist, welches Format dein Vorhaben braucht oder ob ein vorliegendes Angebot Scope und Reifegrad sauber trennt, kannst du das im Rahmen unserer KI-Beratung prüfen lassen – oder du meldest dich direkt für ein unverbindliches Erstgespräch. Genau solche Scope- und Architekturfragen sind unser Tagesgeschäft.

Risiken und Grenzen

Damit dieser Artikel nicht selbst falsche Erwartungen weckt – die wichtigsten Grenzen der drei Formate:

• Ein erfolgreicher PoC garantiert kein erfolgreiches Produkt. Er belegt Machbarkeit unter Laborbedingungen. Skalierung, Randfälle, Datenqualität im Dauerbetrieb und organisatorische Einbettung bleiben offene Risiken.
• Ein begeistert aufgenommener Prototyp garantiert keine Nutzung. Zustimmung im Test ist etwas anderes als geändertes Verhalten im Arbeitsalltag. Genau diese Lücke schließt erst das MVP.
• Ein MVP ohne Messung ist keines. Wenn niemand definiert, was gemessen wird und welche Entscheidung daraus folgt, entsteht kein validiertes Lernen – sondern nur ein kleines Produkt ohne Erkenntnisgewinn.
• Begriffe schützen nicht vor schlechtem Schnitt. Auch ein korrekt benanntes MVP kann am falschen Problem gebaut sein. Die Formatwahl ersetzt keine saubere Problem- und Zielgruppenklärung.
• Nicht jedes Vorhaben braucht die volle Kette. Drei Experimentierstufen für ein internes Standardtool sind Overhead, kein Vorgehen. Die Formate sind Werkzeuge gegen Unsicherheit – wo keine ist, weglassen.

Checkliste: In fünf Schritten zum richtigen Format

1. Unsicherheit benennen: Was ist die eine Frage, die dich nachts umtreibt – Akzeptanz, Machbarkeit oder Alltagsnutzen? In einem Satz aufschreiben.
2. Format zuordnen: Akzeptanz → Prototyp. Machbarkeit → PoC. Alltagsnutzen → MVP. Mehrere offene Fragen → billigste zuerst.
3. Erfolgskriterien fixieren: Vor Baubeginn schriftlich festhalten, woran Erfolg und Misserfolg erkannt werden – inklusive der Konsequenz aus einem Misserfolg.
4. Das Danach klären: Prototyp/PoC → wird verworfen, Erkenntnis dokumentiert. MVP → Betrieb, Messung und Entscheidungstermin für den Ausbau festlegen.
5. Erwartungen synchronisieren: Allen Beteiligten – besonders denen, die nur die Demo sehen – sagen, was das Artefakt ist und was nicht. Ein Satz im Meeting spart Monate an Enttäuschung.

Stand: Juli 2026. Die Begriffsdefinitionen folgen den in den Quellen genannten Originaltexten; Bandbreiten zu Kosten und Dauer sind Erfahrungswerte aus unserer Projektpraxis unter den jeweils genannten Annahmen.