Ein Proof of Concept beweist, dass die Technologie funktioniert, ein Prototyp beweist, dass Menschen die Idee verstehen, und ein MVP beweist, dass jemand sie im echten Arbeitsablauf nutzt. Die richtige Wahl ist das günstigste Artefakt, das Ihre riskanteste Annahme testet.
Gründerinnen und Gründer zahlen jeden Monat MVP-Preise für Prototyp-Fragen, und die Lücke zwischen diesen beiden Rechnungen liegt im fünfstelligen Bereich. Die drei Begriffe verschwimmen in Agentur-Calls, und jeder Anbieter hat einen Anreiz, die größte Variante zu verkaufen.
Dieser Leitfaden trennt die drei Begriffe nach der Annahme, die jeder von ihnen widerlegt. Sie erhalten eine Vergleichstabelle mit Zahlen aus 2026, zwei anonymisierte Projektgeschichten aus webvises eigenem Lieferprotokoll und eine Entscheidungsregel, die sich in fünf Minuten anwenden lässt.
- Ein Proof of Concept beantwortet eine Frage: Lässt sich das überhaupt bauen. Er dauert Stunden bis eine Woche, und der Code ist Wegwerfcode.
- Ein klickbarer Prototyp beantwortet: Verstehen Menschen das Angebot und den Ablauf. Er dauert 2 bis 5 Tage und benötigt kein Backend.
- Ein fokussiertes MVP beantwortet: Schließt ein echter Nutzer den Kernworkflow mit echten Daten ab. Es dauert 3 bis 5 Wochen und kostet 5.000 € bis 25.000 € zu KI-gestützten Agentursätzen.
- Wählen Sie das günstigste Artefakt, das Ihre riskanteste Annahme testet. Ein MVP zu kaufen, um eine Prototyp-Frage zu beantworten, verbrennt einen fünfstelligen Betrag.
- Ein zahlender manueller Prozess zählt als Validierung. Ist die Nachfrage bereits belegt, überspringen Sie den Prototyp und bauen Sie das MVP direkt in Produktionsqualität.
Was jedes Artefakt beweist
Die drei Artefakte liegen auf einer Achse: wie viel Realität sie zulassen. Ein Proof of Concept kommt mit keinem Nutzer in Kontakt. Ein Prototyp trifft Nutzer in Interviews, verarbeitet aber keine echten Daten. Ein MVP läuft in Produktion, mit echten Konten, echten Daten und echten Konsequenzen.
| Artefakt | Frage, die es klärt | Zeitrahmen | Kosten (2026) | Wer es sieht |
|---|---|---|---|---|
| Proof of Concept | Lässt sich das mit heutiger Technik bauen? | Stunden bis 1 Woche | Interner Aufwand, meist unter 2.000 € | Das Team, sonst niemand |
| Klickbarer Prototyp | Verstehen Menschen das Angebot und den Ablauf? | 2 bis 5 Tage | 1.500 € bis 5.000 € | Interviewte Nutzer, Demo-Publikum, Investoren |
| Fokussiertes MVP | Schließt ein Nutzer den Kernworkflow mit echten Daten ab? | 3 bis 5 Wochen | 5.000 € bis 25.000 € | Echte Nutzer, in Produktion |
Die Zeilen zum Zeitrahmen entsprechen der Umfangstabelle in wie lange der Bau eines MVPs dauert, die das Fenster von 3 bis 5 Wochen in einen Wochenplan aufschlüsselt. Die Kostenbänder stammen aus webvises eigener Preisspanne für KI-gestützte Builds.
Geht es um die MVP-Frage, liefert webvises MVP-Entwicklungsservice eine fokussierte erste Version in 3 bis 5 Wochen, produktionsreif ab dem ersten Commit.
Wählen Sie nach Ihrer riskantesten Annahme
Schreiben Sie die eine Annahme auf, die das Projekt scheitern lässt, wenn sie sich als falsch erweist. Dieser Satz wählt das Artefakt für Sie. Es ist derselbe Satz, der die MVP-Anforderungsdokument-Vorlage verankert, die webvise als Lernvertrag nutzt.
- Machbarkeitsrisiko klingt so: Das Modell kann Rechnungspositionen aus gescannten Belegen mit 95 % Genauigkeit extrahieren. Bauen Sie einen Proof of Concept. Ein Skript gegen 50 Beispieldokumente beantwortet das in zwei Tagen.
- Verständnisrisiko klingt so: Ein Einkäufer im Bauwesen versteht ergebnisbasierte Preisgestaltung beim ersten Kontakt. Bauen Sie einen klickbaren Prototyp und beobachten Sie die Reaktion von fünf Personen darauf.
- Verhaltensrisiko klingt so: Vertreter laden wöchentlich Dokumente hoch, ohne erinnert zu werden. Bauen Sie ein MVP, denn nur Verhalten in Produktion beantwortet eine Verhaltensfrage.
Die meisten Projekte tragen alle drei Risiken zugleich, und die Reihenfolge zählt: Klären Sie zuerst das günstigste Risiko. Fünf Wochen in ein MVP zu stecken, während darunter eine Machbarkeitsfrage unbeantwortet bleibt, bedeutet, den gesamten Build auf etwas zu setzen, das ein zweitägiges Skript hätte testen können.
Mini-Story: Der einwöchige Prototyp, der die Frage beantwortete
Im Juni 2026 baute webvise ein Delivery-Engine-Konzept für ein Berliner Team, das an KI-nativen Serviceabläufen arbeitet. Die Idee: Dienstleistungsunternehmen verkaufen fertige Ergebnisse, Agenten führen die Workflows aus, Menschen genehmigen die riskanten Übergänge, und jeder Durchlauf zeigt seine Marge. Die riskanteste Annahme war, ob Betreiber diesen Betriebskreislauf überhaupt verstehen und ihm vertrauen würden. Die Machbarkeit konnte warten.
Das Artefakt war eine Landingpage plus ein Konzept für ein Betreiber-Dashboard: eine Workflow-Bibliothek mit Preisen und Zielmargen, ein Delivery-Board, Durchlauf-Zeitleisten mit angehängten Nachweisen und eine Margenansicht. Kein Produktions-Backend, keine laufenden Agenten. Die Lieferung dauerte eine Woche.
Ein MVP für dieselbe Idee hätte Agenten-Orchestrierung, Connector-Integrationen und Review-Gates bedeutet: Monate an Arbeit und ein Budget im mittleren fünfstelligen Bereich. Das einwöchige Konzept brachte dieselbe Geschichte für einen Bruchteil davon vor die Betreiber, und deren Reaktionen entscheiden jetzt, was gebaut wird.
Wo Gründer zu viel zahlen
Der teure Fehler passiert in beide Richtungen. Richtung eins: MVP-Preise für eine Prototyp-Frage zahlen. Traditionelle Agenturen kalkulieren 60.000 € bis 150.000 € für MVPs, die ihre ersten zwei Monate in Workshops und Mockups verbringen, also Prototyp-Arbeit zum 20-fachen Preis. Die Preisstufen in MVP-Entwicklungskosten 2026 zeigen, woher diese Angebote kommen.
Richtung zwei: einen Prototyp ausliefern und ihn MVP nennen. Vibe-codierte Builds wirken in der Demo überzeugend und brechen zusammen, sobald echte Konten, echte Daten und Randfälle eintreffen. Dieses Fehlerbild hat einen eigenen Beitrag: die Technical-Debt-Falle beim Vibe-Coding von MVPs.
Der Test ist unbestechlich. Kann sich kein echter Nutzer eigenständig anmelden und den Kernworkflow abschließen, handelt es sich um einen Prototyp, egal was auf der Rechnung steht. Übersteht es keine zweite Nutzerrolle oder fehlerhafte Eingabe, ist es ein Prototyp mit einer Produktions-URL.
Mini-Story: Als das Überspringen des Prototyps richtig war
Im Februar 2026 baute webvise eine Plattform für Finanzierungszertifikate für einen Berliner Immobiliendienst. Käufer weisen damit ihre Kreditwürdigkeit gegenüber Maklern und Verkäufern nach, und der Service verspricht ein verbindliches Zertifikat innerhalb von 24 Stunden. Die Nachfrage war bereits auf dem teuren Weg belegt: Das Team stellte Zertifikate manuell aus, und Kunden zahlten dafür.
Mit geklärter Nachfrage lag das offene Risiko im Betrieb. Konnten ein 10-stufiges Finanzierungsformular, die automatisierte PDF-Zertifikatserstellung und ein Vergleich über mehr als 550 Partnerbanken ohne den manuellen Engpass laufen? Nur die Produktion beantwortet das, also sprang das Projekt direkt zu einem 6-wöchigen Full-Stack-MVP.
Die Plattform ging mit einem Admin-Dashboard live, das den gesamten Anfragezyklus abdeckt, einem Lighthouse-Performance-Score von 96 und Ladezeiten unter 1,2 Sekunden. Eine Prototyp-Phase hätte die Antwort nur verzögert und nichts getestet, was der manuelle Prozess nicht bereits getestet hatte.
Das ist die Regel hinter beiden Geschichten. Ein zahlender manueller Prozess ist eine abgeschlossene Validierungsphase. Eine unbewiesene Betriebsgeschichte in einer neuen Kategorie verdient zuerst einen Prototyp.
Der Upgrade-Pfad: Was jeden Schritt übersteht
Die drei Artefakte bilden eine Leiter, aber das Material wandert nicht automatisch nach oben. Wer weiß, was übersteht, zahlt nicht zweimal für dasselbe.
- Vom Proof of Concept: Die Erkenntnis überlebt, der Code stirbt. Ein PoC-Skript, das die Extraktionsgenauigkeit belegt hat, wird zu einer Anforderungszeile, nie zu einem Fundament.
- Vom Prototyp: Ablauf und Screens gehen in den MVP-Build über, dahinter kommt die Produktionsanbindung hinzu. Die Abkürzungen des Prototyps bleiben zurück.
- Vom MVP: Alles überlebt, das ist der Sinn. webvise baut MVPs von Tag eins an mit TypeScript, einem echten Datenbankschema, CI/CD und Monitoring, sodass die Codebasis in das Produkt hineinwächst, statt neu geschrieben zu werden.
Der umgekehrte Weg ist die Falle. Wird ein Prototyp in die Produktion befördert, bleiben seine Abkürzungen unter echter Last erhalten, und die Bereinigung kostet meist mehr, als ein von Anfang an sauber geplantes MVP gekostet hätte.
Die Fünf-Minuten-Version: Schreiben Sie Ihre riskanteste Annahme in einem Satz auf und kaufen Sie dann das günstigste Artefakt, das sie widerlegt. webvise klärt genau das in einem kurzen Gespräch und baut MVPs und Prototypen in 1 bis 5 Wochen. Schicken Sie Ihre Ein-Satz-Annahme über das Kontaktformular, und Sie erfahren, welches Artefakt gebraucht wird.