Wir haben angefangen wie die meisten Teams: mit einem fertigen Tool für Demo-Videos, für das wir bezahlt haben. Dann haben wir die Kombinationen gezählt — zwei Designs, sieben Sprachen und eine Oberfläche, die sich fast jede Woche ändert. Die Rechnung ging nicht auf. Also haben wir uns stattdessen ein eigenes Demo Studio gebaut — und dass ein Zweierteam das binnen Tagen schafft, ist die eigentlich größere Geschichte, nicht das Tool selbst.
Das Problem: Eine Demo ist nicht ein Video, sondern vierzehn
promptShield gibt es in einem hellen und einem dunklen Design und in sieben Sprachen — Englisch, Französisch, Deutsch, Spanisch, Italienisch, Niederländisch und Portugiesisch. Eine einzige Produktdemo — „So schwärzen Sie einen Vertrag“ — ist deshalb eben nicht ein Clip. Es sind zwei Designs × sieben Sprachen = vierzehn Renderings, die alle exakt dieselben Handlungen zeigen, vor einer Oberfläche, die in der jeweiligen Sprache natürlich wirken und im jeweiligen Design korrekt aussehen muss.
Und jetzt multiplizieren Sie das mit jeder einzelnen Demo auf der Marketing-Website — und vergessen Sie nicht, dass die App darunter ein bewegliches Ziel ist. Wir ändern Layouts, benennen Schaltflächen um, ziehen Abstände enger und liefern im Wochentakt neue Funktionen. Jede dieser Änderungen macht klammheimlich Aufnahmen ungültig, die noch gegen die alten Bildschirme entstanden sind.
Warum der SaaS-Ansatz scheiterte
Tools der Klasse Arcade / Storylane / Supademo / Trupeer sind hervorragend in dem, was sie tun: Sie klicken sich durch Ihre App, das Tool nimmt den Bildschirm auf, und heraus kommt ein sauber gestalteter Rundgang. Doch sie alle teilen eine Grundannahme — dass eine Demo ein aufgenommenes Artefakt aus Pixeln ist. Und genau diese Annahme zerbricht in unserem Maßstab:
- Die kombinatorische Explosion ist Handarbeit. Vierzehn Varianten einer Demo bedeuten vierzehn von Hand aufgenommene Durchläufe. Niemand nimmt denselben Ablauf vierzehnmal hintereinander ohne Abweichungen auf, und die deutsche Dark-Mode-Version sechs Wochen später neu zu drehen, damit sie zu den anderen passt, ist eine Aufgabe, mit der wirklich niemand gern einen Nachmittag verbringt.
- UI-Drift entwertet alles auf einen Schlag. Verschieben Sie eine Schaltfläche, und jede Aufnahme, die sie berührte, ist nun auf subtile Weise falsch. Weil die Aufnahme aus Pixeln besteht, gibt es keine Möglichkeit, sie „erneut abzuspielen“ — Sie drehen neu, von Hand, vierzehnmal, für jede Demo, die die Änderung betrifft.
- Lokalisierung ist ein zweiter Vollzeitjob. Das SaaS-Tool nimmt einfach die Sprache auf, die gerade auf dem Bildschirm steht. Sieben Sprachversionen eines Dutzends Demos synchron mit dem Produkt zu halten, ist eine Vollzeitstelle im Content-Bereich, die wir nicht haben und nicht haben wollen.
Die ehrliche Schlussfolgerung war: Diese Kategorie von Tools ist für eine Welt gebaut, in der man eine Demo einmal erstellt und sie monatelang gültig bleibt. Unsere Welt ist das Gegenteil: Die Demo muss ständig neu erzeugt werden, in jedem Design und jeder Sprache, aus einem Produkt, das nie stillsteht.
Der Hebel, den wir bereits hatten
Und hier kommt der Punkt, der den Bau eines eigenen Tools realistisch statt leichtsinnig machte. Unsere öffentliche /demo-Seite täuscht die App nicht vor — sie lädt das echte Desktop-Frontend im Browser: dieselben React-Komponenten, dasselbe CSS, dasselbe i18n, nur mit Mocks anstelle der Backend-Aufrufe. Jede Änderung, die wir an der Oberfläche der Desktop-App vornehmen, fließt bereits automatisch in die Demo ein — weil die Demo die App ist.
Das hieß: Wir brauchten kein Tool, um unsere App „aufzunehmen“. Wir brauchten ein Tool, das sie steuert — und da die App ohnehin schon im Browser läuft und bereits weiß, wie sie sich in jedem Design und jeder Sprache darstellt, waren die Achsen Design und Sprache praktisch gratis dabei.
Was wir gebaut haben
Intern nennen wir es Demo Studio. Der Perspektivwechsel ist klein und ändert dennoch alles: Wir zeichnen ein Skript aus Handlungen auf, kein Video aus Pixeln.
Aufzeichnen durch Vormachen
Sie schalten den Aufnahmemodus ein und klicken sich einmal durch den Ablauf, in einer Sprache, einem Design. Das Studio nimmt nicht den Bildschirm auf. Es zeichnet auf, was Sie getan haben — eine Liste semantischer Ereignisse: „dieses Element anklicken“, „hierhin scrollen“, „dieses Panel öffnen“ — jeweils verknüpft mit einem auflösbaren Selektor, den benötigten Voraussetzungen und einem Zeitstempel. Beim Abspielen leuchtet das angeklickte Element kurz auf, damit die Zuschauer der Handlung folgen können — ganz ohne das zappelige Cursor-Tracking, mit dem Bildschirmrekorder zu kämpfen haben.
Ein Skript, vierzehn Renderings
Dieses eine Skript wird dann einem Headless-Browser übergeben, der es abspielt und das Ergebnis aufnimmt — einmal pro Design, einmal pro Sprache. Eine einzige Aufnahmesitzung erzeugt alle vierzehn WebM-Videos und die passenden Standbilder, und zwar deterministisch, weil dasselbe Skript dieselbe echte App steuert, mit jeweils passend eingestelltem Design und passender Sprache. Die deutsche Dark-Mode-Version und die englische Light-Mode-Version zeigen garantiert dieselben Handlungen, weil sie aus demselben Skript stammen.
Eine Effekt-Timeline — und eine KI, die Effekte vorschlägt
Über der rohen Wiedergabe liegt eine Timeline für den Feinschliff, den eine gute Demo braucht: in einen Bereich hineinzoomen, ein Bedienelement pulsieren lassen, eine Overlay-Bildunterschrift einblenden. Es gibt außerdem einen „Ask Claude“-Schritt, der eine Effektspur für ein Skript vorschlägt, sodass der erste Entwurf von „Wo sollten wir zoomen?“ für Sie vorgezeichnet wird, statt ihn Bild für Bild von Hand zurechtzurücken.
Slots, die sich selbst im Blick behalten
Jede Stelle, an der eine Demo auf der Website erscheint, ist im Code ein <DemoMedia slot="..."/>. Das Studio durchsucht die gesamte Codebasis danach und zeigt Ihnen auf einen Blick, welche Slots über jedes Design und jede Sprache hinweg vollständig aufgenommen sind, welchen ein Rendering fehlt und welche Medienverzeichnisse verwaist sind, weil der zugehörige Slot gelöscht wurde. Das Tool sagt Ihnen, was veraltet ist, statt dass Sie es von einem Kunden erfahren.
Die Wirtschaftlichkeit hat sich still und leise umgekehrt
Der Sinn des Ganzen sind nicht die Funktionen. Es ist das, was mit der Kostenkurve passiert ist. Beim SaaS-Tool lauteten die Grenzkosten einer UI-Änderung: „jede betroffene Demo neu aufnehmen, jeweils vierzehnmal, von Hand“. Mit Demo Studio lauten die Grenzkosten einer UI-Änderung: auf „Neu rendern“ drücken. Das Skript ist weiterhin gültig — es beschreibt Handlungen, und die Handlungen existieren noch — also ist die Behebung Maschinenzeit, keine Menschenzeit.
Eine neue Sprache hinzuzufügen, bedeutete früher, jede Demo darin neu zu drehen. Heute ist es ein weiterer Wert auf der Sprachachse. Bei einem neuen Design war es genau dasselbe. Die Arbeit, die früher linear mit (Designs × Sprachen × Demos × Release-Takt) skalierte, skaliert nun mit der Zahl der eigenständigen Abläufe — und der Rest ist Rendering.
Das größere Muster, das sich darin zeigt
Jahrzehntelang lautete die Standardantwort auf „Wir brauchen ein Tool für X“: „Mieten.“ Etwas selbst zu bauen war teuer, langsam und eine Ablenkung vom eigentlichen Produkt — und so entstand eine ganze Branche, die schmale Tools pro Arbeitsplatz verkaufte, von denen jedes für alle eine Aufgabe passabel erledigte. Die Grenze zwischen selber machen und mieten lag weit auf der „mieten“-Seite, und die meisten internen Werkzeuge lebten auf der falschen Seite von Baukosten, die niemand rechtfertigen konnte.
Diese Grenze hat sich verschoben. Mit einem KI-Coding-Agenten an Bord kann ein kleines Team heute ein maßgeschneidertes internes Tool bauen — eines, das auf sein exaktes Problem zugeschnitten ist, nicht auf den Durchschnitt der Probleme von tausend Kunden — in der Zeit, die früher allein die Anbieterbewertung verschlang. Demo Studio war kein Projekt über ein Quartal. Es war eine Handvoll fokussierter Tage, und es passt zu unserer Realität aus zwei Designs, sieben Sprachen und ständiger Bewegung besser, als es je ein Allzweckprodukt könnte — weil es genau dafür gebaut wurde und für nichts anderes.
Das ist der Teil, bei dem es sich lohnt zu verweilen. Ein großer Teil des Software-as-a-Service-Ökosystems fußt auf der alten Ökonomie von selber machen gegen mieten — auf der Annahme, dass es unwirtschaftlich ist, eine eigene Version eines schmalen Tools zu bauen, sodass Sie für immer pro Arbeitsplatz zahlen werden. Wenn die Kosten, das maßgeschneiderte Ding zu bauen, in sich zusammenfallen, hält diese Annahme nicht mehr. Am stärksten ausgesetzt sind nicht die tiefen, schwer nachzubauenden Plattformen; es sind die dünnen — die „Wir machen einen sauberen Workflow und stellen ihn jedem Nutzer in Rechnung“-Produkte, die ein fähiges Team heute an einem Nachmittag im eigenen Haus aufsetzen kann, exakt auf den eigenen Bedarf zugeschnitten.
Wir haben ein Demo Studio nicht gebaut, weil wir ins Demo-Tooling-Geschäft einsteigen wollten. Wir haben es gebaut, weil es plötzlich billiger war, das Richtige zu bauen, als weiter gegen das gemietete zu kämpfen. Diese Rechnung wird in den kommenden Jahren still und leise in vielen Unternehmen aufgemacht werden — und jedes Mal, wenn das geschieht, wird aus einem Stück ehemaligen Abonnements ein Wochenende voller Code, der Ihnen ganz allein gehört.
Was das mit dem zu tun hat, was wir tun
Es ist derselbe Instinkt, der promptShield selbst antreibt. Die gängige Antwort auf „Lassen Sie die KI bei Ihren Dokumenten helfen“ ist, einem Cloud-Dienst die eigenen Dateien anzuvertrauen und auf die Nutzungsbedingungen zu vertrauen. Wir finden: Die bessere Antwort — wenn das Werkzeug billig genug ist, um es richtig zu bauen — ist, die Daten auf dem eigenen Rechner zu behalten und der KI nur das zu schicken, was sie wirklich braucht. Demo Studio ist genau dieser Instinkt, nach innen gerichtet: Wenn das maßgeschneiderte Ding billig zu bauen wird, hören Sie auf, den Kompromiss zu mieten.
