Ein Proof of Concept in der Softwareentwicklung ist ein kleiner, zeitlich begrenzter Test, der eine einzige Frage beantwortet: Lässt sich das überhaupt bauen? Er prüft eine einzelne riskante Idee, etwa eine neue Technologie oder eine heikle Verbindung zwischen zwei Systemen, bevor Sie für das vollständige Produkt bezahlen. Das Ergebnis ist eine klare Entscheidung, nicht etwas, das Kunden nutzen.
Diese frühe Prüfung gehört fest zu unseren Leistungen in der Entdeckungsphase, in der wir bestätigen, dass eine Idee funktionieren kann, bevor sich jemand zum Bau verpflichtet. Dieser Schritt wiegt schwerer, als er klingt. Gartner stellte fest, dass bis Ende 2025 mindestens 50% der generativen KI-Projekte nach dem Proof of Concept aufgegeben wurden, wegen mangelhafter Datenqualität, schwacher Risikokontrollen, steigender Kosten oder unklarem Geschäftsnutzen. Das sind viele eingestellte Projekte, doch ein Projekt beim Proof of Concept zu beenden ist die günstige Art zu scheitern. Die teure Variante besteht darin, dasselbe Problem nach einem Jahr Entwicklung zu entdecken.
Dieser Leitfaden erklärt, was ein Proof of Concept ist, wie er sich von einem Prototyp und einem Minimum Viable Product (MVP) unterscheidet und wann Sie ihn wirklich brauchen. Er zeigt außerdem, wie Sie einen aufsetzen und an welcher Stelle im Projekt er steht.
Was ist ein Proof of Concept in der Softwareentwicklung?
Stellen Sie sich einen Proof of Concept, kurz PoC, als kleines Experiment vor. Bevor ein Team Monate in ein Produkt steckt, isoliert es den einen Teil, bei dem sich niemand sicher ist, und prüft, ob er funktioniert. Das kann eine neue Technologie sein, eine ungewöhnliche Berechnung oder eine Verbindung zur Software eines anderen Unternehmens. Alles Übrige wartet, bis die Antwort vorliegt.
Fachleute nennen das eine Machbarkeitsprüfung, was schlicht bedeutet: nachsehen, ob sich etwas mit den Werkzeugen, der Zeit und dem Budget umsetzen lässt, die Ihnen zur Verfügung stehen. Ein PoC fragt nicht, ob Kunden das Produkt mögen werden oder ob die Bildschirme einfach zu bedienen sind. Er stellt eine einzige technische Frage und beantwortet sie mit funktionierenden Belegen statt mit Meinungen.
Drei Merkmale unterscheiden einen PoC von anderer Vorarbeit:
- Er ist eng gefasst. Er prüft eine riskante Annahme, nicht das gesamte Produkt.
- Er ist zeitlich begrenzt. Er läuft über einen festen, kurzen Zeitraum, oft Tage oder wenige Wochen, damit er nicht unbemerkt zu einem eigenen Projekt anwächst.
- Er endet mit einer Entscheidung. Das Ergebnis lautet weitermachen, umsteuern oder abbrechen.
Was ein PoC hervorbringt, ist meist grob und zum Wegwerfen gedacht. Es kann ein kurzes Skript sein, ein nackter Bildschirm ohne Gestaltung oder ein Test, der zwei Systeme verbindet und das Ergebnis ausgibt. Niemand außerhalb des Teams soll es zu sehen bekommen. Sein Wert liegt in der Antwort, die er liefert, und genau das macht einen Proof of Concept in der Softwareentwicklung die geringen Kosten wert.
PoC, MVP und Prototyp: Was jeder davon prüft
Diese drei Begriffe werden ständig verwechselt, da jeder von ihnen eine frühe, unfertige Fassung eines Produkts ist. Stellen Sie sich jemanden vor, der ein Restaurant plant. Vor der Unterschrift unter den Mietvertrag prüft er, ob seine Küche das Signature-Gericht zubereiten kann. Danach skizziert er den Gastraum und führt ein paar Freunde durch eine Entwurfskarte. Erst dann serviert er zahlenden Gästen an einigen Abenden pro Woche eine kurze Speisenauswahl, um zu sehen, wer wiederkommt. Die folgende Tabelle zeigt die Software-Entsprechung jedes Schritts.
Beantwortete Frage
Können wir das bauen?
Werden Menschen verstehen, wie man es bedient?
Wollen Menschen es genug, um es zu nutzen oder dafür zu zahlen?
Was geprüft wird
Technische Machbarkeit
Gestaltung und Nutzererlebnis
Marktnachfrage
Wer es sieht
Das Projektteam
Entscheider und Testnutzer
Echte Kunden
Funktioniert die Software?
Nur der geprüfte Teil
Oft nicht, da es nur klickbare Bildschirme sein können
Ja, mit einem kleinen Satz Kernfunktionen
Übliche Dauer
Tage bis wenige Wochen
Einige Wochen
Meist einige Monate
Was am Ende herauskommt
Eine Entscheidung: weitermachen, anpassen oder abbrechen
Rückmeldungen zur Gestaltung
Echte Nutzungsdaten und erste Kunden
Ein Prototyp ist ein Modell davon, wie das Produkt aussehen und wie sich Menschen darin bewegen werden. Oft besteht er aus klickbaren Bildschirmen, hinter denen nichts läuft, und das ist in Ordnung, denn seine Aufgabe ist es, verwirrende Abläufe sichtbar zu machen, bevor Code geschrieben wird.
Ein MVP hingegen ist echte Software. Es ist die kleinste Fassung des Produkts, die Kunden nutzen können, gebaut, um zu lernen, ob der Markt sie will. Unser Leitfaden dazu, wie man ein MVP erstellt, behandelt diese Phase im Detail, von der Auswahl der Funktionen bis zur Messung der Ergebnisse.
Die Reihenfolge lautet meist PoC, dann Prototyp, dann MVP, wobei nicht jedes Projekt alle drei braucht. Bewährte Technologie erlaubt es, den PoC zu überspringen, und eine einfache Gestaltung benötigt womöglich nur einen schnellen Prototyp. Entscheidend ist, dass jede Frage beantwortet ist, bevor Sie ernsthaft Geld in die nächste Stufe stecken.
Wann brauchen Sie wirklich einen PoC?
Nicht jedes Projekt braucht einen PoC, denn viele setzen auf vertraute Technologie, mit der bereits ähnliche Produkte entstanden sind. Der Proof of Concept verdient seinen Platz, wenn Sie etwas Unerprobtes einsetzen wollen, meist in drei Situationen:
- Unerprobte Technologie: Ihr Plan stützt sich auf ein Werkzeug oder eine Plattform, die Ihr Team noch nicht eingesetzt hat oder die neu am Markt ist.
- Ein neuer oder ungewöhnlicher Ansatz: Das Projekt hängt an Logik, die so noch niemand geschrieben hat. Ein Beispiel: Ein Kunde bat uns, seine manuelle Suche nach Sportturnieren zu automatisieren, und unsere Recherche für diesen Sportevent-Crawler zeigte, dass das Auslesen beliebig strukturierter Webseiten aufwendig und teuer würde. Also nutzten wir einen festen Satz an Quellen, der deutlich einfacher zu bauen und zu pflegen war.
- Eine Verbindung zur Software Dritter: Viele Produkte stützen sich auf Plugins oder Zahlungsdienste und tauschen Daten mit ihnen über eine API aus, ein Regelwerk, das ein Programm anbietet, damit andere mit ihm sprechen können. Die Dokumentation verrät Ihnen nicht immer, ob sie in der Praxis trägt. Als wir einen Onlineshop für Breukelen Cellars bauten, eine Weinhandlung in Brooklyn, häuften sich beim populärsten WordPress-E-Commerce-Plugin Nutzerbeschwerden über Fehler. Vor der Festlegung führte das Team einen kleinen Test als PoC durch, um die technische Machbarkeit zu prüfen: ob die Plugins die Aufgabe erfüllen, und welches davon besteht.
KI zu einem bestehenden Produkt hinzuzufügen passt ebenfalls in dieses Muster, und genau darum geht es in Gartners Befund. Ein Modell, das in der Demo überzeugt, kann mit Ihren echten Daten straucheln. Unser Leitfaden dazu, wie KI die Entdeckungsphase verändert, beschreibt, wie Teams solche Projekte heute zuschneiden.
Um herauszufinden, ob Ihr eigenes Projekt einen PoC braucht, stellen Sie Ihrem Team eine Frage: “Wenn dieser Teil nicht funktioniert, scheitert dann das ganze Projekt?” Lautet die Antwort ja und kann niemand belegen, dass es funktionieren wird, dann führen Sie zuerst einen PoC durch.
Einen PoC in fünf Schritten aufsetzen
Das Schwierigste an einem PoC ist nicht das Schreiben des Codes, sondern den Test eng zu führen, damit er Ihre Frage beantwortet und nicht in vorgezogene Produktentwicklung abgleitet. Diese fünf Schritte zeigen, wie ein PoC entsteht, der in einer belastbaren Entscheidung mündet.
- Legen Sie die Frage fest, die der PoC beantworten muss. Formulieren Sie sie so, dass nur ja oder nein möglich ist, zum Beispiel: “Kann unsere App aktuelle Lagerbestände von unserem Lieferanten abrufen?” Haben Sie drei Fragen, planen Sie drei kleine Tests.
- Einigen Sie sich darauf, wie Erfolg aussieht. Setzen Sie messbare Ziele, bevor jemand beginnt, etwa eine Antwortzeit, eine Trefferquote oder Kosten pro Transaktion.
- Setzen Sie ein Zeit- und ein Budgetlimit. Legen Sie beides vorab fest, zum Beispiel zwei Wochen und einen Entwickler, und beenden Sie den Test, sobald eines davon aufgebraucht ist.
- Bauen Sie nur, was der Test braucht. Lassen Sie Gestaltung, Anmeldebildschirm und alles weg, was nicht an der Frage hängt. Nutzen Sie Beispieldaten, falls echte Daten nicht bereitstehen, aber sagen Sie das beim Berichten der Ergebnisse deutlich.
- Halten Sie das Ergebnis fest und entscheiden Sie. Schreiben Sie kurz auf, was funktionierte, was nicht und was das Team überrascht hat. Wählen Sie dann einen von drei Wegen: weitermachen, den Plan ändern oder abbrechen. Abbrechen ist kein Scheitern, denn genau dafür wurde der PoC geschaffen.
Auch ein bestandener Test hat Grenzen. Er belegt, dass die Idee unter kontrollierten Bedingungen funktioniert, nicht dass sie Tausenden Nutzern standhält. Der Weg vom erfolgreichen Test zum Produktivsystem ist eine eigene Arbeitsphase. Was dafür nötig ist, beschreiben wir für KI-Werkzeuge in vom Claude-Proof-of-Concept in den Produktivbetrieb. Es ist auch der Grund, warum viele KI-Einführungen in der Pilotphase stecken bleiben, selbst nach vielversprechendem Start.
Wo steht ein PoC im Entwicklungsprozess?
Ein PoC steht ganz am Anfang, bevor sich das Team auf einen Plan festlegt. Solange das Team nicht weiß, dass die riskanten Teile tragen, kann es weder die Anforderungen festzurren, eine detaillierte Liste dessen, was die Software leisten muss, noch die Architektur, den Bauplan dafür, wie ihre Teile zusammenspielen.
In der Praxis geschieht diese Vorarbeit während der Entdeckungsphase, dem Planungsabschnitt, in dem ein Team Idee, Nutzer und technische Risiken untersucht, bevor die Entwicklung startet. Ein PoC beantwortet die Frage “Können wir es bauen?”. Der Rest der Entdeckungsphase macht aus dieser Antwort einen Plan. Die Erkenntnisse prägen anschließend die schriftliche Spezifikation, das Dokument, nach dem Entwickler arbeiten. Dafür sind unsere Leistungen zur funktionalen Spezifikation da.
Unser eigenes Projekt Tingl zeigt, warum die riskanteste Technologie vor allem anderen geklärt sein muss. Tingl ist eine auf Privatsphäre ausgerichtete Messaging-App, die Redwerk erdacht und von Grund auf gebaut hat. Um dieses Versprechen einzulösen, entwickelten unsere Blockchain-Entwickler BAMM, ein eigenes Verfahren zur Nachrichtenübertragung, das sowohl den Inhalt als auch den Absender anonym hält. Das Privatsphäreversprechen der App ruht auf dieser Schicht, also genau die Art Baustein, bei dem ein Team sicher sein muss, bevor es darum herum entwirft. Außerdem wählten wir Flutter, ein für schnelles Prototyping bekanntes Framework, um das MVP zügig zu bauen. Nach dem Beta-Start auf Product Hunt mit starken Bewertungen wurde Tingl übernommen. Unser Artikel über Ergebnisse der Entdeckungsphase zeigt, wie diese frühe Planung dem Produkt zu einem pünktlichen Start verhalf.
Ein PoC setzt keine fertige Spezifikation voraus. Viele Projekte starten mit einer groben Idee und einigen offenen technischen Fragen. Das ist normal und oft ein guter Zeitpunkt zum Testen, denn früh umzusteuern kostet meist weniger als später.
Lohnt sich ein Proof of Concept für Ihr Projekt?
Ein Proof of Concept in der Softwareentwicklung ist eine günstige Versicherung dagegen, auf einer Annahme zu bauen, die sich als falsch erweist. Er kostet Tage oder Wochen statt Monate und ersetzt eine hoffnungsvolle Vermutung durch Belege. Verzichten Sie darauf, wenn die Technologie erprobt ist und Ihr Team Ähnliches schon gemacht hat. Führen Sie einen durch, wenn eine einzige Unbekannte das ganze Projekt versenken kann.
Entscheidend ist, ihn klein zu halten und mit einer Entscheidung zu beenden. Eine Frage, klare Erfolgskriterien und ein festes Zeitlimit sagen Ihnen mehr, als es ein großer, offener Bau je könnte.
Genau so ist unsere Entdeckungsarbeit angelegt: Wir prüfen zuerst die riskanten Teile und planen den vollständigen Bau dann um das Gelernte herum. Offene Fragen zu Beginn halten uns nicht auf, denn sie zu beantworten ist der Zweck dieser Phase. Wenn Ihre Idee von etwas abhängt, das noch niemand belegt hat, buchen Sie ein Gespräch. Stellen wir es gemeinsam auf die Probe.
Häufige Fragen
Was ist ein Proof of Concept in der Softwareentwicklung?
Ein Proof of Concept in der Softwareentwicklung ist ein schneller, kostengünstiger Weg herauszufinden, ob eine zentrale technische Idee trägt, bevor Sie das gesamte Produkt finanzieren. Das Team baut nur den unsicheren Teil, etwa eine neue Zahlungsanbindung, und misst ihn an vereinbarten Zielen. Das Ergebnis entscheidet, ob das Projekt weiterläuft, die Richtung wechselt oder endet.
Was ist der Unterschied zwischen einem PoC und einem MVP?
Ein PoC kommt vor einem MVP und beantwortet eine engere Frage. Der PoC prüft, ob sich ein riskanter Teil bauen lässt, und sein Code wird selten behalten. Ein MVP ist die erste Fassung, die bleiben soll: funktionierende Software mit wenigen Kernfunktionen, die echte Kunden nutzen, damit das Team sie anhand der Reaktionen weiterentwickeln kann.
Wie lange dauert ein Proof of Concept?
Die meisten Proofs of Concept dauern einige Tage bis einige Wochen. Die Dauer hängt davon ab, wie komplex die Frage ist und ob das Team gegen echte Daten und Systeme testen kann. Erreicht ein PoC seine Frist ohne Antwort, werten Sie auch das als Erkenntnis, denn es bedeutet oft, dass das Problem schwerer ist als gedacht, und der vollständige Bau womöglich ebenso.
Brauche ich immer einen Proof of Concept?
Nein, ein Proof of Concept lohnt sich nur, wenn ein Teil des Projekts so noch nie gemacht wurde. Hat Ihr Team oder Ihr Dienstleister Ähnliches schon gebaut, belegt diese Erfahrung bereits die Machbarkeit. Schlägt ein Dienstleister einen PoC vor, fragen Sie, welche Frage er beantworten soll und welches Ergebnis den Plan ändern würde. Eine klare Antwort zeigt, dass der Test sein Geld wert ist.
Was passiert nach einem erfolgreichen Proof of Concept?
Nach einem erfolgreichen Proof of Concept geht das Projekt in die vollständige Planung über. Das Team teilt seine Erkenntnisse und bestätigt die Entscheidung weiterzumachen. Anschließend schreibt es die Anforderungen und plant die Architektur um das herum, was der Test belegt hat. Danach baut das Team einen Prototyp, um die Gestaltung zu prüfen, oder geht direkt zum MVP über, wenn die Bildschirme einfach sind.
Erfahren Sie, wie wir einen anonymen Web3-Messenger mit unübertroffener Chat-Privatsphäre entwickelt haben, der innerhalb weniger Monate übernommen wurde
