Proof of Concept, Prototyp oder MVP? Begriffe und wann was passt

Kaum ein Bereich sorgt für so viele Missverständnisse zwischen Auftraggeber und Agentur wie die Begriffe rund um frühe Projektartefakte. Der eine meint mit Prototyp einen anklickbaren Entwurf, der andere ein technisches Testprogramm; ein MVP wird mal als billige Sparversion, mal als vollwertiges Produkt verstanden. Diese Unschärfe kostet Geld, weil Sie am Ende womöglich etwas anderes bekommen als erwartet. Dieser Leitfaden schafft Begriffsklarheit: Er definiert Proof of Concept, Prototyp, Wireframe/Mockup, MVP und Pilot, grenzt sie sauber voneinander ab und gibt Ihnen eine Entscheidungshilfe, welches Artefakt zu welchem Ziel passt. Den inhaltlichen Tiefgang zum MVP – wie man es zuschneidet und entwickeln lässt – behandelt gesondert unser Leitfaden zum MVP entwickeln lassen; hier geht es um die Einordnung der Begriffe.

Die Begriffe klar definiert

Proof of Concept (PoC)

Ein Proof of Concept beantwortet eine einzige Frage: Geht das technisch überhaupt? Er dient dem Nachweis der Machbarkeit einer kritischen technischen Annahme – etwa ob sich zwei Systeme über eine Schnittstelle verbinden lassen, ob ein Algorithmus die nötige Genauigkeit erreicht oder ob eine bestimmte Technologie das erwartete Datenvolumen bewältigt. Ein PoC ist bewusst wegwerfbar. Er ist nicht schön, nicht vollständig und nicht für Endnutzer gedacht. Sein Wert liegt darin, ein technisches Risiko früh und günstig auszuschließen, bevor Sie in die vollständige Umsetzung investieren. Klassische Anwendungsfälle sind neue oder ungewohnte Technologien, anspruchsvolle Integrationen in bestehende Systeme oder Leistungsanforderungen, bei denen unklar ist, ob sie sich überhaupt erreichen lassen. Fällt der PoC negativ aus, ist das kein Scheitern, sondern eine wertvolle, günstig gewonnene Erkenntnis, die Sie vor einer teuren Sackgasse bewahrt.

Wireframe und Mockup

Wireframes und Mockups sind visuelle Entwürfe der Benutzeroberfläche – noch ohne Funktion. Ein Wireframe ist eine schematische Skizze im Graustufen-Look: Er zeigt, welche Elemente wo auf einer Seite liegen, ohne Farben, Bilder oder finale Texte. Ein Mockup ist die ausgestaltete, statische Variante mit Farben, Typografie und Bildsprache – es sieht aus wie das fertige Produkt, ist aber nicht bedienbar. Beide dienen dazu, Aufbau und Aussehen früh abzustimmen, bevor teure Entwicklung beginnt. Sie sind ein Kernwerkzeug im UI/UX-Design.

Prototyp

Ein Prototyp ist ein bedienbarer Entwurf, mit dem man Abläufe durchspielen kann, ohne dass eine echte Software dahintersteht. Typisch ist der Klickprototyp: verlinkte Mockups, durch die man klickt wie durch die spätere Anwendung. Der Prototyp beantwortet die Frage: Funktioniert die Idee aus Nutzersicht? Er eignet sich hervorragend, um Nutzerfeedback einzuholen, Bedienabläufe zu testen und Stakeholder abzuholen – lange bevor echte Funktionalität programmiert ist. Anders als der PoC geht es nicht um technische Machbarkeit, sondern um Bedienung und Nutzererlebnis. Auch ein Prototyp ist meist nicht dazu gedacht, weiterverwendet zu werden.

Minimum Viable Product (MVP)

Das MVP ist der erste Schritt weg vom Wegwerf-Artefakt hin zu echtem Code. Es ist eine funktionsfähige, echte Software mit dem kleinsten sinnvollen Funktionsumfang, die einem echten Nutzer einen echten Mehrwert liefert. Das Ziel: mit minimalem Aufwand herausfinden, ob das Produkt am Markt trägt, und aus dem Verhalten realer Nutzer lernen. Wichtig ist das Wort „viable": Ein MVP ist keine kaputte Sparversion, sondern ein kleines, aber vollständig funktionierendes Produkt. Es wird typischerweise iterativ weiterentwickelt – der Scrum Guide beschreibt genau dieses Vorgehen, bei dem am Ende jedes Sprints ein potenziell nutzbares Inkrement steht, das man ausliefern und aus dem man lernen kann. Den vollständigen Zuschnitt eines MVP behandelt unser Leitfaden zum MVP entwickeln lassen.

Pilot

Ein Pilot ist der begrenzte Praxiseinsatz einer bereits weitgehend fertigen Software mit einer ausgewählten Nutzergruppe unter realen Bedingungen. Anders als das MVP, das die grundsätzliche Tragfähigkeit prüft, testet der Pilot den Betrieb im Alltag: Läuft alles stabil, akzeptieren die Nutzer die Anwendung, funktionieren die Prozesse rund um die Software? Der Pilot ist die letzte Stufe vor dem breiten Rollout und dient dazu, Betriebs- und Akzeptanzrisiken zu senken, bevor alle Nutzer umsteigen.

Entscheidungshilfe: Ziel bestimmt Artefakt

Statt zu fragen „Sollen wir einen Prototyp oder ein MVP bauen?", fragen Sie besser: „Welche Unsicherheit wollen wir gerade beseitigen?" Das Ziel bestimmt das passende Artefakt:

• Sie zweifeln an der technischen Machbarkeit einer kritischen Komponente? → Proof of Concept.
• Sie wollen Aufbau und Aussehen der Oberfläche abstimmen, bevor entwickelt wird? → Wireframe oder Mockup.
• Sie wollen Bedienabläufe und Nutzerakzeptanz testen, ohne echte Software zu bauen? → Prototyp.
• Sie wollen wissen, ob das Produkt am Markt trägt, und aus echten Nutzern lernen? → MVP.
• Sie haben ein fertiges Produkt und wollen den Alltagsbetrieb absichern, bevor alle es nutzen? → Pilot.

Oft folgen mehrere Artefakte aufeinander: erst ein PoC für das technische Risiko, dann Mockups und ein Prototyp für die Nutzersicht, dann ein MVP als erstes echtes Produkt, schließlich ein Pilot vor dem Rollout. Nicht jedes Projekt braucht alle Stufen – wählen Sie gezielt die, die Ihre größte offene Frage beantworten.

Ein durchgehendes Beispiel: der Online-Konfigurator eines Möbelherstellers

Wie die Artefakte zusammenspielen, wird an einem durchgehenden Beispiel am greifbarsten. Ein mittelständischer Möbelhersteller möchte Kunden erlauben, Regale online in 3D zu konfigurieren und direkt zu bestellen. Drei Unsicherheiten stehen im Raum: Läuft die 3D-Darstellung technisch flüssig genug im Browser? Verstehen Kunden die Bedienung? Und kaufen sie am Ende tatsächlich individuell konfigurierte Möbel? Jede dieser Fragen wird von einem anderen Artefakt beantwortet.

Der Proof of Concept klärt die erste, technische Frage. Das Team baut ein nacktes Testprogramm, das ein einziges Regalmodell in 3D rendert, und misst, ob es auf typischen Geräten ruckelfrei läuft. Kein Design, keine Bestellfunktion, bewusst wegwerfbar. Das Ergebnis: Auf Desktop-Rechnern läuft es flüssig, auf älteren Smartphones stockt die Darstellung. Eine wertvolle Erkenntnis für wenige Tausend Euro – der Funktionsumfang wird früh angepasst, statt das Problem erst nach Monaten teuer zu entdecken.

Wireframes und ein Mockup beantworten, wie der Konfigurator aufgebaut ist und aussieht. Zuerst skizzieren die Designer die Bildschirme in Graustufen, dann entsteht eine farbige, statische Ausgestaltung. Die Fachabteilung stimmt Aufbau und Anmutung ab, bevor ein einziger Entwicklertag investiert wird.

Der Prototyp nimmt die Nutzersicht in den Blick. Die Mockups werden zu einem Klickprototyp verknüpft, durch den Testkunden die Konfiguration durchspielen. Dabei zeigt sich: Viele finden die Auswahl der Materialien nicht, weil sie an einer unerwarteten Stelle sitzt. Der Bedienablauf wird korrigiert, bevor er programmiert wird – eine Änderung, die im fertigen Code ein Vielfaches gekostet hätte.

Das MVP ist die erste echte Software: ein voll funktionierender Konfigurator für eine einzige Produktlinie mit wenigen Optionen und angebundener Bestellung, live für echte Kunden. Es ist bewusst schmal, aber nicht kaputt – die vorhandenen Funktionen laufen vollständig. Jetzt lässt sich die entscheidende Marktfrage beantworten: Bestellen Kunden überhaupt konfigurierte Regale? Aus dem realen Nutzerverhalten lernt der Hersteller, welche Optionen gefragt sind und welche niemand nutzt.

Der Pilot folgt später, wenn der Konfigurator um weitere Produktlinien gewachsen ist. Vor dem bundesweiten Start wird er in einigen ausgewählten Filialen unter realen Bedingungen betrieben, um Stabilität, Abläufe und Akzeptanz abzusichern. Dasselbe Vorhaben, fünf Artefakte – und jedes hat genau eine offene Frage an der günstigsten Stelle beantwortet.

Welches Artefakt bei welchem Ziel

Übersetzt man das Beispiel in typische Ausgangslagen, wird die Zuordnung schnell konkret:

• „Ich will eine neue oder ungewohnte Technologie einführen und weiß nicht, ob sie hält, was sie verspricht." → Proof of Concept, der genau diese Technologie unter realistischen Bedingungen testet.
• „Ich muss interne Entscheider oder Investoren von einer Idee überzeugen, bevor Budget freigegeben wird." → Ein Klickprototyp macht die Idee erlebbar, ohne dass echte Entwicklung nötig ist.
• „Ich habe eine Produktidee, aber kein Budget für die Vollentwicklung, und will erst den Markt prüfen." → MVP mit dem kleinsten sinnvollen Funktionsumfang.
• „Ich will die Oberfläche mit der Fachabteilung abstimmen, bevor programmiert wird." → Wireframe und Mockup.
• „Meine Software ist fertig, aber ich traue dem breiten Rollout noch nicht." → Pilot mit einer begrenzten Nutzergruppe.

Die Ausgangsfrage entscheidet – nicht die Vorliebe für ein bestimmtes Vorgehen.

Die Aufwands- und Kostenleiter

Die Artefakte unterscheiden sich stark im Aufwand. Die folgende Tabelle ordnet sie von gering nach hoch ein. Die Angaben sind eine grobe Orientierung – der konkrete Aufwand hängt stark vom Einzelfall ab. Als Kalkulationsbasis liegen Tagessätze qualifizierter Teams im DACH-Raum bei rund 90 € pro Stunde und darüber; belastbare Marktzahlen liefert der Freelancer-Kompass.

Artefakt	Beantwortet	Echter Code?	Relativer Aufwand
Wireframe	Wie ist die Oberfläche aufgebaut?	Nein	Sehr gering
Mockup	Wie sieht es aus?	Nein	Gering
Prototyp (Klick)	Funktioniert die Bedienung?	Nein	Gering bis mittel
Proof of Concept	Ist es technisch machbar?	Ja, wegwerfbar	Mittel
MVP	Trägt das Produkt am Markt?	Ja, produktiv	Mittel bis hoch
Pilot	Funktioniert der Betrieb im Alltag?	Ja, produktiv	Hoch

Die Leiter zeigt die Logik dahinter: Je früher und günstiger Sie ein Risiko ausräumen, desto weniger teures Nachbessern droht später. Ein wegwerfbarer Prototyp für ein paar Tausend Euro kann eine Fehlinvestition in ein voll ausgebautes Produkt verhindern. Wenn Sie technische Grundsatzentscheidungen absichern wollen, kann eine unabhängige IT-Beratung helfen, das passende Vorgehen zu wählen.

Warum die Begriffsschärfe im Angebot zählt

Die Unschärfe der Begriffe ist nicht nur akademisch – sie schlägt sich direkt in Angeboten und Verträgen nieder. Steht im Angebot „Wir liefern einen Prototyp", sollten Sie klären, ob damit ein anklickbarer Entwurf ohne Funktion oder ein erstes lauffähiges Stück Software gemeint ist. Der Preisunterschied zwischen beiden ist erheblich, und das Missverständnis führt zu Enttäuschung auf beiden Seiten. Nutzen Sie die hier definierten Begriffe daher aktiv in der Kommunikation mit Anbietern: Fragen Sie explizit, welche Frage das vorgeschlagene Artefakt beantwortet, ob echter, weiterverwendbarer Code entsteht und was danach damit passiert. Eine gute Agentur wird diese Fragen präzise beantworten – schwammige Antworten sind ein Warnsignal. So wird aus der Begriffsklarheit ein praktisches Werkzeug, das Sie vor teuren Fehlerwartungen schützt.

Artefakte sinnvoll kombinieren

Das Beispiel zeigt das Grundprinzip: Die Artefakte stehen in der Praxis selten allein, sondern bauen aufeinander auf – und ihre Reihenfolge folgt einer klaren Logik. Geordnet wird nicht nach Gewohnheit, sondern nach Risiko und Aufwand: Zuerst räumen Sie die Unsicherheiten mit dem größten Risiko und dem geringsten Aufwand aus, erst danach investieren Sie in echten, produktiven Code. Nicht jedes Projekt durchläuft alle Stufen – ist die Technik erprobt, entfällt der Proof of Concept; ist die Oberfläche trivial, sparen Sie sich aufwändige Prototypen. Entscheidend ist, an jeder Stelle bewusst zu wählen, statt reflexartig alle Artefakte abzuarbeiten. Diese schrittweise Risikoreduktion ist der eigentliche Grund, warum es sich lohnt, die Begriffe sauber auseinanderzuhalten – sie sind Werkzeuge, um Geld dort zu sparen, wo Ungewissheit am teuersten wäre.

Häufige Fragen

Kann ein Prototyp später zur fertigen Software ausgebaut werden?

In der Regel nein – und das ist beabsichtigt. Klickprototypen bestehen aus verknüpften Entwürfen ohne echte Programmierung; darauf lässt sich kein Produkt aufbauen. Auch ein technischer PoC ist auf schnellen Erkenntnisgewinn optimiert, nicht auf Wartbarkeit. Versucht man solche Artefakte weiterzuverwenden, entsteht oft fragiler Code. Ein MVP hingegen ist von Anfang an echter, produktiver Code, der weiterentwickelt werden soll.

Ist ein MVP dasselbe wie eine abgespeckte Billigversion?

Nein. Der entscheidende Unterschied liegt im Wort „viable", also brauchbar. Ein MVP hat wenige Funktionen, aber die vorhandenen funktionieren vollständig und liefern echten Nutzen. Eine kaputte oder halbfertige Software ist kein MVP, sondern schlicht ein schlechtes Produkt, das falsche Rückschlüsse zulässt.

Brauche ich für jedes Projekt alle Stufen?

Nein. Welche Artefakte sinnvoll sind, hängt von Ihren Unsicherheiten ab. Ist die Technik erprobt und die Oberfläche simpel, können Sie PoC und aufwändige Prototypen überspringen und direkt ein MVP bauen. Steckt das Risiko dagegen in einer heiklen technischen Machbarkeit, ist ein PoC vorab bares Geld wert. Wählen Sie gezielt.

Wer entscheidet, welches Artefakt passt?

Idealerweise gemeinsam mit der Agentur, oft schon im Discovery-Workshop. Sie bringen die fachlichen und geschäftlichen Ziele ein, die Agentur die technische und methodische Einschätzung. Eine gute Agentur fragt zuerst nach Ihrer offenen Frage und schlägt dann das passende Artefakt vor – nicht umgekehrt.

Was ist der Unterschied zwischen MVP und Pilot?

Ein MVP prüft, ob ein Produkt grundsätzlich trägt, und richtet sich meist an frühe, offene Nutzer. Ein Pilot testet ein bereits weitgehend fertiges Produkt im echten Alltagsbetrieb einer begrenzten, konkreten Nutzergruppe – als letzte Absicherung vor dem breiten Rollout. Das MVP steht am Anfang, der Pilot kurz vor dem Ende.

Worin unterscheidet sich ein Proof of Concept von einem Prototyp?

Beide werden oft verwechselt, beantworten aber gegensätzliche Fragen. Ein Proof of Concept prüft die technische Machbarkeit – er ist ein nacktes Testprogramm, das etwa eine Schnittstelle oder einen Algorithmus erprobt, und interessiert sich weder für Aussehen noch für Bedienung. Ein Prototyp prüft die Nutzersicht – er ist ein bedienbarer, meist anklickbarer Entwurf ohne echte Technik dahinter, mit dem sich Abläufe und Akzeptanz testen lassen. Kurz: Der PoC fragt „Geht das technisch?", der Prototyp fragt „Funktioniert die Bedienung?". Beide sind bewusst wegwerfbar und nicht zur Weiterverwendung gedacht.

Passende Agentur finden: Über Deine-Agenturen.com vergleichen Sie neutral geprüfte Softwareagenturen aus der DACH-Region und finden einen Partner, der mit Ihnen das richtige Artefakt für Ihre offene Frage wählt – statt vorschnell in die Vollentwicklung zu starten.