We begonnen zoals de meeste teams: met een kant-en-klare tool voor demovideo's waar we voor betaalden. Toen telden we de combinaties op: twee thema's, zeven talen en een interface die bijna elke week verandert. De rekensom klopte niet. Dus bouwden we onze eigen Demo Studio — en dat een team van twee dat in een paar dagen voor elkaar kreeg, is een groter verhaal dan de tool zelf.
Het probleem: een demo is niet één video, maar veertien
promptShield is er in een licht en een donker thema en in zeven talen — Engels, Frans, Duits, Spaans, Italiaans, Nederlands en Portugees. Eén enkele productdemo — "zo maakt u een contract onleesbaar" — is dus niet één clip. Het zijn twee thema's × zeven talen = veertien renders, die elk exact dezelfde handelingen tonen in een interface die er in die taal uit moet zien alsof hij daar thuishoort en in dat thema moet kloppen.
Vermenigvuldig dat nu met elke demo op de marketingsite, en bedenk vervolgens dat de app eronder een bewegend doelwit is. We passen lay-outs aan, hernoemen knoppen, verkleinen tussenruimtes en voegen wekelijks functies toe. Elk van die wijzigingen maakt geruisloos de opnames ongeldig die op de oude schermen waren gemaakt.
Waarom de SaaS-aanpak vastliep
Tools uit de categorie Arcade / Storylane / Supademo / Trupeer zijn uitstekend in wat ze doen: u klikt door uw app heen, zij leggen het scherm vast, en u krijgt een verzorgde rondleiding. Maar ze delen allemaal één aanname — dat een demo een vastgelegd artefact van pixels is. En juist die aanname houdt op onze schaal geen stand:
- De combinatorische explosie is handwerk. Veertien varianten van een demo betekenen veertien handmatig opgenomen takes. Niemand neemt dezelfde flow veertien keer achter elkaar op zonder afwijkingen, en de Duitse donkere-modusversie zes weken later opnieuw opnemen zodat hij bij de rest past — daar knapt niemand van op.
- UI-drift maakt alles in één klap wees. Verplaats een knop en elke opname die hem raakte, klopt nu subtiel niet meer. Omdat de opname uit pixels bestaat, is er geen manier om hem "opnieuw af te spelen" — u neemt opnieuw op, met de hand, veertien keer, voor elke demo die de wijziging raakt.
- Lokalisatie is een tweede baan. De SaaS neemt op wat er toevallig op het scherm stond. Zeven taalversies van een dozijn demo's synchroon met het product houden is een fulltime contentfunctie die we niet hebben en niet willen.
De eerlijke conclusie was dat dit soort tool gebouwd is voor een wereld waarin u een demo één keer maakt en die maandenlang blijft kloppen. Onze wereld is het tegenovergestelde: de demo moet voortdurend opnieuw worden gegenereerd, in elk thema en elke taal, vanuit een product dat nooit stilzit.
De troef die we al hadden
Dit is het stuk dat het bouwen van onze eigen tool realistisch maakte in plaats van roekeloos. Onze openbare /demo-pagina doet de app niet na — hij laadt de echte desktop-frontend in de browser, dezelfde React-componenten, dezelfde CSS, dezelfde i18n, alleen met de backend-aanroepen vervangen door mocks. Elke UI-wijziging die we in de desktop-app maken, stroomt al automatisch door naar de demo, want de demo is de app.
Dat betekende dat we geen tool nodig hadden om onze app vast te leggen. We hadden een tool nodig om hem te besturen — en omdat de app al in de browser draait en zichzelf al in elk thema en elke taal weet weer te geven, kregen we de assen thema en taal er praktisch gratis bij.
Wat we bouwden
Intern noemen we het Demo Studio. De verschuiving in denken is klein en verandert alles: we nemen een script van handelingen op, geen video van pixels.
Opnemen door voordoen
U zet de opnamemodus aan en klikt de flow één keer door, in één taal, één thema. De Studio neemt niet het scherm op. Hij legt vast wat u deed — een lijst van semantische gebeurtenissen: "klik op dit element", "scroll hierheen", "open dit paneel" — elk gekoppeld aan een herleidbare selector, de voorwaarden die daarvoor nodig zijn, en een tijdstempel. Bij het afspelen knippert het aangeklikte element zodat kijkers de handeling kunnen volgen, zonder het schokkerige cursorvolgen waar schermrecorders mee worstelen.
Eén script, veertien renders
Dat ene script wordt vervolgens doorgegeven aan een headless browser die het afspeelt en het resultaat vastlegt — één keer per thema, één keer per taal. Eén opnamesessie levert alle veertien WebM-video's en bijpassende stilstaande beelden op, deterministisch, want het is hetzelfde script dat telkens dezelfde echte app aanstuurt, met thema en taal steeds vooraf ingesteld. De Duitse donkere-modusversie en de Engelse lichte-modusversie tonen gegarandeerd identieke handelingen, want ze komen uit hetzelfde script.
Een effecten-timeline — en een AI die ze voorstelt
Bovenop de kale replay ligt een timeline voor de finishing touch die een goede demo nodig heeft: inzoomen op een gebied, een besturingselement laten pulseren, een tekstoverlay tonen. Er is ook een "Ask Claude"-stap die een effectenspoor voor een script voorstelt, zodat de eerste aanzet van "waar moeten we inzoomen?" voor u wordt opgesteld in plaats van beeld voor beeld te worden bijgeschoven.
Slots die zichzelf eerlijk houden
Elke plek waar een demo op de site verschijnt, is een <DemoMedia slot="..."/> in de code. De Studio scant de hele codebase daarop en laat u in één oogopslag zien welke slots voor elk thema en elke taal volledig zijn opgenomen, welke een render missen, en welke mediamappen wees zijn geworden omdat het slot waar ze bij hoorden, is verwijderd. De tool vertelt u wat verouderd is, in plaats van dat u het van een klant hoort.
De economie keerde geruisloos om
Het punt van dit alles zijn niet de functies. Het is wat er met de kostencurve gebeurde. Bij de SaaS waren de marginale kosten van een UI-wijziging "neem elke geraakte demo opnieuw op, veertien keer per stuk, met de hand". Met Demo Studio zijn de marginale kosten van een UI-wijziging op 'opnieuw renderen' drukken. Het script is nog steeds geldig — het beschrijft handelingen, en de handelingen bestaan nog steeds — dus de correctie is machinetijd, geen mensentijd.
Een nieuwe taal toevoegen betekende vroeger elke demo erin opnieuw opnemen. Nu is het één extra waarde op de taal-as. Een thema toevoegen was hetzelfde verhaal. Het werk dat vroeger lineair meegroeide met (thema's × talen × demo's × releaseritme) groeit nu mee met het aantal afzonderlijke flows, en de rest is renderen.
Het grotere waar dit een symptoom van is
Decennialang was het standaardantwoord op "we hebben een tool voor X nodig": "huur hem". Zelf een tool bouwen was duur, traag en een afleiding van je eigenlijke product, dus groeide er een hele industrie die smalle tools verkocht, per seat gefactureerd, die elk voor iedereen één taak redelijk deden. De grens tussen zelf bouwen en huren lag ver aan de "huren"-kant, en de meeste interne tooling leefde aan de verkeerde kant van bouwkosten die niemand kon rechtvaardigen.
Die grens is verschoven. Met een AI-codeeragent aan boord kan een klein team nu een op maat gemaakte interne tool bouwen — een die is gevormd naar zijn exacte probleem, niet naar het gemiddelde van de problemen van duizend klanten — in de tijd die het vroeger kostte om leveranciers te beoordelen. Demo Studio was geen project van een kwartaal. Het was een handvol gerichte dagen, en het past beter bij onze werkelijkheid van twee thema's, zeven talen en constante beweging dan enig algemeen inzetbaar product ooit had gekund, want het is precies daarvoor gebouwd en voor niets anders.
Dit is het deel dat de moeite waard is om even bij stil te staan. Een groot deel van het software-as-a-service-ecosysteem is gebouwd op de oude economie van zelf bouwen versus huren — op de aanname dat je eigen versie van een smalle tool bouwen onrendabel is, dus dat je voor altijd per seat blijft betalen. Wanneer de kosten om het maatwerk te bouwen instorten, houdt die aanname op te gelden. De tools die het meest kwetsbaar zijn, zijn niet de diepe, moeilijk te repliceren platforms; het zijn de dunne — de "wij doen één schone workflow en rekenen elke gebruiker ervoor aan"-producten die een bekwaam team nu in eigen huis kan opzetten, precies passend gemaakt op zijn eigen vorm, in een middag.
We hebben geen Demo Studio gebouwd omdat we in de demo-toolingbusiness wilden zitten. We bouwden hem omdat het ineens goedkoper was om het juiste ding te bouwen dan te blijven vechten met het gehuurde. Die berekening zal de komende jaren in stilte in veel bedrijven worden gemaakt — en telkens wanneer dat gebeurt, wordt weer een beetje van wat ooit een abonnement was, een weekend aan code die u volledig zelf bezit.
Hoe dit samenhangt met wat we doen
Het is hetzelfde instinct dat promptShield zelf aandrijft. Het gangbare antwoord op "laat AI met uw documenten helpen" is uw bestanden aan een clouddienst geven en op de gebruiksvoorwaarden vertrouwen. Wij denken dat het betere antwoord, zodra de tool goedkoop genoeg is om goed te bouwen, is om de data op uw machine te houden en de AI alleen te sturen wat hij nodig heeft. Demo Studio is datzelfde instinct naar binnen gericht: wanneer maatwerk bouwen goedkoop wordt, stop dan met het compromis te huren.
