Ein Kunde kam mit einer vagen, aber überzeugenden Idee zu uns – eine neue Verwaltungsoberfläche für seine Online-Community. Keine klaren Anforderungen, keine Design-Spezifikationen, nur das Gefühl, dass die alte Website nicht mehr ausreichte. Am Ende des Tages hatten wir mit Payload CMS einen funktionierenden Prototyp gebaut, unter einer Live-URL bereitgestellt – und der Kunde hatte etwas Konkretes, worauf er reagieren konnte. Das Ganze dauerte einen Arbeitstag.
Das ist kein Glücksfall. Es ist ein wiederholbarer Workflow. Und in der Schweiz, wo erfahrene Entwicklerstunden teuer sind und die Erwartungen der Stakeholder hoch sind, lässt sich kaum bestreiten, dass es wirtschaftlich sinnvoll ist, schnell zu validieren, bevor man Budget freigibt.
Die eigentliche Frage ist nicht, ob deine Idee gut ist. Sie ist, ob sie in deiner Umgebung funktioniert – und das kannst du an einem Tag herausfinden.
Was ein Proof of Concept (PoC) eigentlich ist
Ein Proof of Concept (PoC) ist eine minimale, funktionsfähige Version mit einer einzigen Aufgabe: eine spezifische Frage zur technischen Machbarkeit zu beantworten. Kann das in unserer Umgebung, mit unseren Daten und in Verbindung mit unseren Systemen tatsächlich funktionieren?
Das Payload-CMS-Projekt ist ein gutes Beispiel. Die PoC-Frage lautete nicht: «Wird das toll aussehen?» Sondern: «Können wir auf Basis der bestehenden Struktur schnell genug eine funktionsfähige Content-Management-Oberfläche aufbauen, um dem Kunden noch heute etwas Konkretes zu zeigen?» Das war’s.
Bei what. bedeutet ein erfolgreicher eintägiger PoC, dass der Kern-Workflow durchgängig läuft, der Kunde damit interagieren kann und alle mit einem klaren Go/No-Go-Signal nach Hause gehen. Die Messlatte liegt nicht bei perfektem Code oder produktionsreifer Sicherheit. Es geht darum, ein Signal zu haben, das zeigt, ob die Idee weitere Investitionen verdient.
Warum KI einen Tag heute realistisch macht
Vor zwei Jahren wäre ein Prototyp für etwas wie eine massgeschneiderte CMS-Oberfläche am selben Tag noch unrealistisch gewesen. Du hättest den Vormittag damit verbracht, nur die Anforderungen zu besprechen, den Nachmittag damit, dich mit Boilerplate-Code herumzuschlagen, und die nächsten drei Tage damit, Tests zu schreiben und offensichtliche Bugs zu beheben.
KI-gestützte Entwicklung verändert das auf einige konkrete Arten. Die grösste Zeitersparnis liegt nicht dort, wo die meisten Leute sie erwarten. Es ist nicht die Codegenerierung selbst – es ist die Möglichkeit, eine bestehende Website oder ein Designsystem als direkte Eingabe zu nutzen. Wir haben die alte Website des Kunden in Claude eingegeben, damit die Architektur in Payload CMS aufgebaut und von dort aus iteriert. Es war kein Start mit einer leeren Datei oder ein Rätselraten bei der Inhaltsstruktur.
Der zweite Vorteil ist, dass du dank KI in der Prototyp-Phase auf das Schreiben richtiger Tests verzichten kannst, ohne völlig blind zu arbeiten. Du iterierst schnell, überprüfst Kern-Workflows manuell und nutzt KI-Tools, um Regressionen sofort zu erkennen. So würdest du keine Produktionssoftware entwickeln – aber für einen PoC ist das genau richtig.
Wichtig zu erwähnen: Viele «KI-Probleme», mit denen Kunden zu uns kommen, entpuppen sich als Integrationsprobleme, sobald wir uns näher damit befassen. Ein eintägiger PoC macht diesen Unterschied schnell deutlich. Wenn der Prototyp nicht funktioniert, weil zwei Systeme nicht miteinander kommunizieren können, ist das ein Problem der Tool-Integration, kein KI-Problem – und das am ersten Tag zu wissen, spart wochenlange vergebliche Anstrengungen.
Ebenfalls relevant: Wenn deine zugrunde liegenden Workflows nicht funktionieren, wird selbst ein erfolgreicher PoC sie nicht beheben. Lies unseren Beitrag zur Optimierung von Workflows, bevor du KI einsetzt.
Das Playbook für den eintägigen PoC
So läuft ein typischer Tag tatsächlich ab.
Vormittag: Erkundung und Umfang festlegen (1–2 Stunden)
Der wichtigste Schritt – und der, den die meisten Teams am liebsten überspringen würden. Bevor irgendetwas entwickelt wird, setzen wir uns mit dem Kunden zusammen und identifizieren die eine Frage, die der PoC beantworten muss. Wir legen auch fest, was wir heute ausdrücklich nicht entwickeln: Authentifizierungsabläufe, Fehlerbehandlung, mobile Responsivität, Admin-Berechtigungen. Alles, was nicht zum Kernablauf gehört, wird zurückgestellt.
Der Input spielt hier eine grosse Rolle. Im besten Fall gibt es eine bestehende Website, ein Designsystem oder auch nur einen gut strukturierten Markenleitfaden. Das gibt der KI eine konkrete Grundlage, an der sie arbeiten kann, anstatt ins Leere zu generieren.
Mittag: Entwicklung und Bereitstellung (3–4 Stunden)
Sobald der Umfang definiert ist, zerlegen wir den Prototyp in möglichst kleine Aufgaben. Das ist entscheidend – nicht weil es geordnet ist, sondern weil KI-Tools deutlich bessere Ergebnisse liefern, wenn sie an fokussierten, klar abgegrenzten Problemen arbeiten statt an vagen, weit gefassten Vorgaben. Jede Aufgabe wird implementiert, überprüft und iteriert, bevor wir zur nächsten übergehen.
Unser bevorzugter Stack für diese Art von Arbeit: Claude Code für die Umsetzung und Claude für Architekturentscheidungen. Für die Bereitstellung richten wir ein einfaches Digital Ocean Droplet ein – nichts Ausgefallenes, gerade genug, um es live und teilbar zu machen. Der Kunde bekommt eine echte URL, keine lokale Demo, die nur auf unserem Laptop funktioniert.
Später Nachmittag: Iterieren und Übergabe (1–2 Stunden)
Wir gehen die zentralen Workflows mit dem Kunden durch, beheben offensichtliche Probleme, die auftauchen, und dokumentieren, was im und was ausserhalb des Umfangs liegt. Die Übergabe ist nicht nur eine URL – sie ist ein klares Bild davon, was der PoC bewiesen hat, was nicht, und wie ein nächster Sprint aussehen würde.
Was unser KI-Experte sagt
Was unser KI-Experte sagt
Der grösste Fehler, den Kunden vor einem PoC machen, ist, ihn wie ein Produktbriefing zu behandeln. Ein PoC braucht eine Frage, nicht zehn Features – je begrenzter der Umfang, desto nützlicher das Ergebnis.
Was einen guten eintägigen PoC-Kandidaten ausmacht
Nicht jede Idee passt in dieses Format. Diejenigen, die gut funktionieren, haben einige Gemeinsamkeiten:
- Begrenzter Umfang mit klaren Eingaben und Ausgaben
- Zumindest etwas vorhandenes Material, auf dem man aufbauen kann (alte Website, Designsystem, Beispieldaten)
- Kernfunktionalität, die weitgehend standardisiert ist – Content-Management, Formularverarbeitung, grundlegende Datenanzeige
- Keine starke Abhängigkeit von komplexen Drittanbieter-Integrationen am ersten Tag
Schlechte Kandidaten sind alle Projekte, die eine tiefgreifende Integration in Altsysteme, Compliance-Prüfungen oder Datenflüsse zwischen mehreren Systemen erfordern, bevor das Grundkonzept überhaupt getestet werden kann. Diese benötigen zunächst einen richtigen Scoping-Sprint – keinen eintägigen Build.
| Gute PoC-Kandidaten | Schlechte PoC-Kandidaten |
|---|---|
| Internes Wissens-Q&A-Tool | Komplexe Integrationen in Altsystem-ERP |
| Chat-Demo für den Kundensupport | Compliance-Prüfung über mehrere Rechtsräume hinweg |
| Extraktion von Rechnungsdaten | Datenflüsse zwischen mehreren Systemen am ersten Tag |
| KI-generierte Berichtszusammenfassungen | Alles, was eine vorherige Datenmigration erfordert |
Schnell validieren, klug investieren
Die Unternehmen, die bei der KI-Transformation Geld verbrennen, wählen in der Regel nicht die falschen Ideen. Sie setzen das gesamte Budget für die Entwicklung ein, bevor sie die Kernannahme überprüft haben. Ein eintägiger KI-PoC dient dazu, genau diesen Fehler zu umgehen.
Eine Woche mit einer unbestätigten Annahme zu verbringen, ist teuer. Ein Nachmittag hingegen nicht.
Die Alternative – einen vollständig KI-gestützten Entwicklungszyklus durchlaufen, bevor getestet wird, ob das Ganze in deiner Umgebung tatsächlich funktioniert – ist eines der häufigsten Muster, die wir bei gescheiterten KI-Projekten beobachten. Mehr dazu haben wir in «5 Fehler, die du wahrscheinlich bei deiner KI-Transformation machst» geschrieben.
Wenn du auf einer Idee sitzt und dir nicht sicher bist, ob es sich lohnt, sie umzusetzen, ist das genau das Gespräch, das du führen solltest. Unser KI-Automatisierungsteam arbeitet mit Unternehmen zusammen, um schnell den Umfang zu definieren, zu entwickeln und zu validieren – damit du in das investierst, was funktioniert, und nicht in das, was bloss in einer Präsentation gut klingt.
