Proof of Concept (PoC)

In der Softwareentwicklung und bei Systemauswahlen im E-Commerce ist der PoC das wichtigste Mittel, um teure Fehlentscheidungen früh zu vermeiden. Wer eine neue Plattform, ein Framework oder eine Integration bewertet, kann Datenblättern, Demos und Referenzen glauben oder selbst prüfen, ob die kritischen Punkte im eigenen Umfeld tragen. Der PoC ist die zweite Option.

Was ein Proof of Concept ist und was nicht

Der Begriff wird oft schlampig verwendet. Ein PoC ist kein fertiges Teilprodukt. Er darf hässlich, unvollständig und nicht wartbar sein, solange er die Ausgangsfrage sauber beantwortet. Er wird typischerweise nach der Bewertung verworfen oder als Wissensgrundlage archiviert, nicht als Fundament für die Produktion weiterverwendet.

Bedeutung und Herkunft des Begriffs

Wörtlich heißt Proof of Concept „Nachweis des Konzepts“. Der Ausdruck stammt nicht aus der Softwareentwicklung. Belegt ist er seit Ende der 1960er-Jahre, damals für eine Entwicklungsphase, in der experimentelle Hardware gebaut und getestet wurde. Heute ist er auch im Ingenieurwesen und in der Arzneimittelentwicklung verbreitet. Der Kern ist meist derselbe: der Nachweis, dass ein Konzept trägt, bevor Zeit und Geld in die vollständige Umsetzung fließen.

In der IT-Sicherheit hat der Begriff eine eigene Bedeutung. Dort bezeichnet ein PoC häufig Beispielcode, der eine Schwachstelle ausnutzt und damit belegt, dass sie real und ausnutzbar ist. Bekannte Sicherheitslücken wie Heartbleed (CVE-2014-0160) wurden durch öffentlich verfügbare PoC-Exploits für Verteidiger wie Angreifer greifbar.

PoC vs. Prototyp vs. MVP: die Unterschiede

Proof of Concept, Prototyp und Minimum Viable Product (MVP) fallen oft in einem Atemzug, prüfen aber drei verschiedene Risiken. Der PoC fragt nach der Machbarkeit, der Prototyp nach der Bedienbarkeit, das MVP nach dem Markt. Die Tabelle stellt die drei Formate nebeneinander.

Zwei Definitionen helfen bei der Einordnung. Eric Ries, der das MVP mit der Lean-Startup-Methode bekannt gemacht hat, beschreibt es als die Version eines neuen Produkts, mit der ein Team mit möglichst wenig Aufwand möglichst viel gesichertes Wissen über seine Kunden sammelt. Die Nielsen Norman Group nennt einen Prototyp der Benutzeroberfläche eine Hypothese: einen Lösungskandidaten für ein bestimmtes Gestaltungsproblem. Wie ein MVP Schritt für Schritt entsteht, zeigt der Leitfaden zur MVP-Entwicklung.

Ein vierter Begriff wird oft mit dem MVP verwechselt: der Pilot. Er prüft, ob eine Lösung im echten Betrieb mit ausgewählten Anwendern funktioniert, etwa an einem Standort oder mit einer Kundengruppe. Ein Pilot ist produktionsnah und endet mit dem Rollout oder einer Korrektur. In manchen Teams heißt ein PoC außerdem „technischer Prototyp“. Entscheidend ist die Frage, die der Versuch beantworten soll, das Etikett ist zweitrangig.

Die Abgrenzung ist wichtig, weil die Begriffe unterschiedliche Erwartungen wecken. Wird ein PoC als MVP behandelt, gerät hastig geschriebener Testcode in die Produktion. Wird ein MVP als PoC verkauft, unterschätzen Beteiligte den Aufwand für Qualität, Sicherheit und Betrieb.

Kurz gesagt: Der PoC beweist, dass es geht. Der Prototyp zeigt, wie es sich anfühlt. Das MVP zeigt, ob es jemand will.

Wann PoC, wann Prototyp, wann MVP?

Welches Format passt, entscheidet die größte offene Frage im Vorhaben. Drei Prüffragen sortieren das:

1. Ist unklar, ob es technisch funktioniert? Dann zuerst ein PoC. Typische Auslöser sind eine neue Plattform, eine kritische Schnittstelle, erwartete Lastspitzen oder eine KI-Komponente, deren Ergebnisqualität niemand vorhersagen kann.
2. Ist unklar, ob Nutzer die Lösung verstehen und annehmen? Dann ein Prototyp. Ein klickbarer Prototyp zeigt in Tests mit künftigen Nutzern, wo der Ablauf hakt, bevor die erste Zeile Produktivcode entsteht.
3. Ist unklar, ob Kunden das Angebot nutzen oder dafür bezahlen? Dann ein MVP. Diese Frage beantwortet nur ein Test am Markt, und dafür muss das Produkt echten Kunden standhalten.

Der PoC ist also das richtige Werkzeug, wenn ein konkretes technisches oder organisatorisches Risiko besteht, das sich mit begrenztem Aufwand isolieren und messen lässt. Fehlt dieses Risiko, ist er Beschäftigungstherapie mit Projektnamen. Ist die Technik ausgereift und in ähnlichen Umgebungen vielfach erprobt, genügt oft eine Referenzprüfung mit Gesprächen bei bestehenden Anwendern.

Die typische Reihenfolge

In Softwareprojekten folgen die Formate häufig aufeinander: Der PoC klärt die Technik, der Prototyp die Bedienung, das MVP den Markt, und ein Pilot prüft zum Schluss den Betrieb. Zwingend ist diese Kette nicht. Liegt das größte Risiko in der Nutzerführung, etwa bei einem Kundenportal für Händler, kommt der Prototyp zuerst.

PoC und Prototyp können auch parallel laufen, weil sie unterschiedliche Fragen beantworten und oft von unterschiedlichen Leuten gebaut werden: der PoC von Entwicklern, der Prototyp von UX-Designern. Wichtig ist, dass jede Stufe mit einer bewussten Entscheidung endet. Wer vom Prototyp ohne Auswertung ins MVP rutscht, verschenkt den Vorteil, für den die Stufen da sind.

Ablauf eines Proof of Concept in sechs Schritten

Ein PoC ohne klare Frage wird zum Bastelprojekt. Die folgenden Schritte haben sich für technische Bewertungen bewährt.

1. Hypothese formulieren. Nicht „Wir testen Framework X“, sondern „Framework X kann unsere Preislogik mit kundenspezifischen Staffeln abbilden und dabei 200 Anfragen pro Sekunde bedienen.“ Eine überprüfbare Aussage ist die Voraussetzung für ein klares Ergebnis.
2. Erfolgskriterien vorab festlegen. Was gilt als bestanden, was als gescheitert? Messbare Kriterien verhindern, dass das Ergebnis nachträglich schöngeredet wird. Sie leiten sich aus den Anforderungen ab. Liegen die noch nicht schriftlich vor, lohnt es sich, zuerst ein Lastenheft erstellen zu lassen.
3. Umfang begrenzen. Nur die Risiken testen, nicht das Gesamtsystem. Die größten Unbekannten kommen zuerst, Standardfunktionen bleiben außen vor.
4. Zeitrahmen setzen. Ein PoC ohne Frist läuft aus dem Ruder. Für technische Evaluierungen sind einige Wochen üblich, für kleinere Fragestellungen genügen Tage.
5. Realistische Bedingungen schaffen. Echte Datenmengen, echte Schnittstellen, echte Randfälle. Ein PoC mit Spielzeugdaten beweist wenig.
6. Ergebnis dokumentieren und entscheiden. Am Ende steht eine klare Empfehlung mit Begründung: weiter, anpassen oder stoppen. Auch ein gescheiterter PoC ist ein Erfolg, wenn er eine teure Fehlentscheidung verhindert.

Im agilen Alltag: der Spike

In agilen Teams heißt ein sehr kleiner, technischer PoC oft Spike. Bekannt wurde der Begriff durch Extreme Programming. Gemeint ist ein möglichst einfaches Programm, das nur das untersuchte Problem angeht und alles andere ausblendet. Die XP-Regel empfiehlt, dafür ein Entwicklerpaar ein bis zwei Wochen abzustellen, und rechnet offen damit, dass der Code danach weggeworfen wird. Ein PoC für eine Plattformwahl ist größer, folgt aber derselben Logik.

Typische Fragen, die ein PoC im E-Commerce klärt

• Lässt sich unsere Preis- und Rabattlogik in der Zielplattform ohne Sonderlösungen abbilden?
• Wie robust ist die Anbindung an ERP und PIM bei realen Datenmengen und Fehlerfällen?
• Hält die Architektur den erwarteten Spitzenlasten stand, etwa in Aktionszeiträumen?
• Wie hoch ist der Aufwand für die Migration von Produkt- und Kundendaten?
• Können die Teams die neue Technik tatsächlich betreiben und erweitern?

Ein Beispiel: Plattformwahl im Mittelstand

Ein häufiger Anwendungsfall ist die Entscheidung für ein Commerce-Framework. Bei einem modularen, code-lastigen System wie MedusaJS liegt der Wert eines PoC darin, dass sich viele Eigenschaften erst im eigenen Kontext zeigen. Ein solcher PoC läuft üblicherweise über vier bis acht Wochen und hat einen festen Umfang: eine Standard-Storefront, ein Payment-Provider, eine ERP-Anbindung und ein klar definierter Anwendungsfall.

Das Ziel ist nicht der fertige Shop, sondern eine belastbare Antwort darauf, ob das Framework unter den tatsächlichen Anforderungen wie versprochen funktioniert. Die Einordnung findest du im Beitrag zu MedusaJS.

Dabei zeigen sich häufig Punkte, die in Datenblättern fehlen: Lizenzgrenzen für Funktionen wie Rechteverwaltung oder Firmenanmeldung, der Aufwand für individuelle Preislogik, die Reife der Integrationen oder die Häufigkeit von Breaking Changes zwischen Releases. Ein PoC, der diese Punkte bewusst als Testfälle enthält, liefert Entscheidern mehr Substanz als jede Präsentation.

Ergebnisse auswerten und dokumentieren

Der Wert eines PoC entsteht erst durch die Auswertung. Sinnvoll ist ein kurzer Ergebnisbericht mit festem Aufbau: Ausgangsfrage, Vorgehen, Messwerte, beobachtete Probleme, Bewertung gegen die vorab festgelegten Kriterien und eine Empfehlung.

Wichtig ist die Trennung von Beobachtung und Interpretation. „Der Import von 40.000 Artikeln dauerte 35 Minuten“ ist eine Beobachtung. „Das ist für unseren Nachtlauf ausreichend“ ist eine Bewertung, die sich an einem vorher definierten Fenster messen lassen muss.

Ebenso gehören offene Risiken in den Bericht. Kein PoC deckt alles ab. Was nicht getestet wurde, sollte ausdrücklich als ungetestet benannt werden, damit Entscheider den Restrisiko-Rahmen kennen.

Bewährt hat sich eine einfache Ampellogik pro Hypothese: bestätigt, teilweise bestätigt, widerlegt. Bei teilweise bestätigten Hypothesen steht dabei, was für die Bestätigung noch fehlt und mit welchem Aufwand sich das prüfen lässt.

Kosten und Nutzen abwägen

Ein PoC kostet Zeit und Geld, und auch das gehört in die Rechnung. Als Orientierung hilft der Vergleich mit dem Risiko, das er abdeckt. Bindet eine Plattformentscheidung über mehrere Jahre ein großes Budget, ist ein PoC, der nur einen kleinen Teil davon kostet, eine günstige Versicherung. Bei kleinen, leicht umkehrbaren Entscheidungen lohnt der Aufwand dagegen selten. Die Faustregel: Je teurer und schwerer umkehrbar die Entscheidung, desto eher lohnt sich ein PoC.

Wichtig ist außerdem, wer die Kosten trägt. Bei externen Dienstleistern sollte der PoC als eigenständiges, klar beschriebenes Paket beauftragt werden, mit festem Umfang und festem Ende. Das schützt beide Seiten davor, dass aus einem Test unbemerkt ein Projekt wird.

Häufige Fehler

Der PoC wird zum Produkt. Der klassische Fehler: Der Test läuft gut, der Termindruck ist hoch, und der Code geht in die Produktion. Später zeigt sich, dass Architektur, Tests und Sicherheit nie vorgesehen waren, und das Projekt startet mit technischer Schuld. Die Regel lautet: Was als PoC entstanden ist, wird neu gebaut oder zumindest gründlich überarbeitet.

Kein definiertes Ende. Ohne Erfolgskriterien und Frist ist jeder PoC ein Dauerprojekt. Er verbraucht Ressourcen, ohne zu einer Entscheidung zu führen.

Falsche Fragen. Getestet wird, was leicht ist, nicht was riskant ist. Ein PoC, der nur den Happy Path zeigt, bestätigt lediglich, was ohnehin klar war.

Voreingenommenheit. Wird der PoC von Fürsprechern einer Lösung durchgeführt, fällt das Ergebnis oft freundlicher aus als die Realität. Kritische Fragen sollten von jemandem gestellt werden, der die Entscheidung nicht schon getroffen hat.

Überspringen des PoC. Der umgekehrte Fehler ist verbreitet. Wer direkt mit einem MVP beginnt, baut Architekturentscheidungen ein, die später nur schwer zu revidieren sind. Ein kurzer, fokussierter PoC ist in aller Regel günstiger als die Korrektur einer falschen Plattformwahl.

Das falsche Format. Mit einem PoC soll geklärt werden, ob Nutzer mit einem Bestellprozess zurechtkommen, oder ein Klickmodell soll belegen, dass die ERP-Schnittstelle Last aushält. Keines der beiden Formate kann diese Frage beantworten. Erst die Frage klären, dann das Format wählen.

PoC, Discovery und Ausschreibung

In größeren Vorhaben steht der PoC nicht allein. Er ist Teil einer Abfolge aus Anforderungsklärung, Evaluierung, Entscheidung und Umsetzung. In der Vorphase klärt eine Discovery-Phase, was das System leisten muss. Der PoC prüft danach die riskantesten Annahmen.

In öffentlichen Ausschreibungen oder Auswahlverfahren mit mehreren Bietern wird der PoC gelegentlich als Bewertungsstufe genutzt: Die Anbieter bauen einen definierten Ausschnitt, und die Ergebnisse werden anhand gleicher Kriterien verglichen. Das erhöht die Vergleichbarkeit, verursacht aber Aufwand auf beiden Seiten und sollte angemessen vergütet werden.

Bei KI-Vorhaben ist der PoC besonders verbreitet, weil die Ergebnisqualität schwer vorherzusagen ist. Ob ein Sprachmodell Produkttexte in der geforderten Qualität liefert oder Kundenanfragen zuverlässig klassifiziert, lässt sich am besten mit echten Daten testen.

Auch hier gilt die Regel, dass ein erfolgreicher PoC noch kein produktionsreifes System bedeutet. Die Lücke zwischen Demo und Betrieb, mit Monitoring, Datenschutz und Fehlerbehandlung, wird regelmäßig unterschätzt.

Ausblick

Generative Werkzeuge verkürzen den Weg zu einem lauffähigen Versuchsaufbau erheblich. Mit KI-Codeassistenten und Vibe Coding entsteht, was früher Wochen dauerte, heute teilweise in Tagen. Das verändert nicht die Logik des PoC, verschärft aber ein Risiko: Wenn ein Ergebnis schnell und ansehnlich entsteht, wächst die Versuchung, es für mehr zu halten, als es ist.

Die Disziplin, vorab Hypothese und Erfolgskriterien festzulegen und das Ergebnis nüchtern zu bewerten, wird dadurch wichtiger, nicht unwichtiger. Für Entscheider bleibt die Regel stabil: Ein PoC ist eine Investition in Information. Er sollte klein sein, eine klare Frage beantworten und am Ende eine Entscheidung ermöglichen, egal in welche Richtung.

Häufige Fragen zum Proof of Concept

Was ist ein Proof of Concept?

Ein Proof of Concept (PoC) ist ein Machbarkeitsnachweis: ein kleiner, zeitlich begrenzter Test, der mit möglichst realistischen Daten zeigt, ob eine Idee oder Technik unter echten Bedingungen funktioniert. Am Ende steht eine Entscheidung über das weitere Vorgehen.

Was bedeutet PoC?

PoC ist die Abkürzung für Proof of Concept, wörtlich „Nachweis des Konzepts“, im Deutschen meist Machbarkeitsnachweis. In der IT-Sicherheit steht PoC außerdem für Beispielcode, der belegt, dass eine Schwachstelle tatsächlich ausnutzbar ist.

Was ist der Unterschied zwischen PoC und MVP?

Ein PoC beantwortet die Frage nach der technischen Machbarkeit und ist meist nur intern sichtbar. Ein MVP ist ein produktionsreifes Minimalprodukt, das mit echten Kunden zeigt, ob sich das Angebot am Markt trägt.

Was ist der Unterschied zwischen PoC und Prototyp?

Der PoC prüft, ob etwas technisch funktioniert, und kommt oft ohne Oberfläche aus. Der Prototyp zeigt, wie sich eine Lösung bedienen lässt, und funktioniert dahinter häufig nur zum Schein. Der PoC richtet sich an das Projektteam, der Prototyp an künftige Nutzer.

Wie lange sollte ein PoC dauern?

So kurz wie möglich. Für technische Plattformbewertungen sind vier bis acht Wochen üblich, für einzelne Fragestellungen reichen oft Tage.

Wer sollte einen PoC durchführen?

Ein Team mit ausreichender technischer Tiefe, das nicht allein von einem bestimmten Ergebnis profitiert. Häufig wird er gemeinsam von internen Fachleuten und externen Partnern erarbeitet.

Wird der PoC-Code später weiterverwendet?

In der Regel nicht. Erkenntnisse und Architekturentscheidungen fließen in die Umsetzung ein, der Code selbst wird neu geschrieben oder gründlich überarbeitet.

Weiterführende Quellen

Einen allgemeinen Überblick bietet der Wikipedia-Artikel zum Proof of Concept, die Begriffsgeschichte seit den 1960er-Jahren der englischsprachige Artikel. Die genannte Sicherheitslücke ist im National Vulnerability Database-Eintrag zu CVE-2014-0160 dokumentiert.

Die MVP-Definition stammt aus Eric Ries’ Beitrag „Minimum Viable Product: a guide“ von 2009, die Beschreibung des Prototyps als Hypothese aus dem Artikel „UX Prototypes: Low Fidelity vs. High Fidelity“ der Nielsen Norman Group.