All'inizio pagavamo uno strumento preconfezionato per i video dimostrativi, come fa la maggior parte dei team. Poi abbiamo messo in fila le combinazioni: due temi, sette lingue e un'interfaccia che cambia quasi ogni settimana. I conti non tornavano. Così ci siamo costruiti il nostro Demo Studio — e il fatto che un team di due persone ci sia riuscito, in pochi giorni, è una storia più interessante dello strumento stesso.
Il problema: una demo non è un video, sono quattordici
promptShield viene distribuito in tema chiaro e tema scuro e in sette lingue — inglese, francese, tedesco, spagnolo, italiano, olandese e portoghese. Una singola demo del prodotto — "ecco come si oscura un contratto" — non è quindi un solo filmato. Sono due temi × sette lingue = quattordici rendering, ciascuno dei quali mostra esattamente le stesse azioni su un'interfaccia che deve sembrare nativa in quella lingua e corretta in quel tema.
Ora moltiplichiamo tutto questo per ogni demo presente sul sito di marketing, e ricordiamo che l'app sottostante è un bersaglio mobile. Cambiamo i layout, rinominiamo i pulsanti, stringiamo le spaziature e aggiungiamo funzionalità a cadenza settimanale. Ognuna di queste modifiche manda in soffitta, senza dare nell'occhio, le registrazioni girate sulle schermate vecchie.
Perché l'approccio SaaS ha smesso di reggere
Gli strumenti della categoria di Arcade / Storylane / Supademo / Trupeer sono eccellenti in quello che fanno: si clicca dentro l'app, loro catturano lo schermo e si ottiene una presentazione guidata rifinita. Ma condividono tutti uno stesso presupposto — che una demo sia un artefatto di pixel catturato. Ed è proprio questo presupposto a sgretolarsi alla nostra scala:
- L'esplosione combinatoria è manuale. Quattordici varianti di una demo significano quattordici riprese registrate a mano. Nessuno registra lo stesso flusso quattordici volte di fila senza qualche sbavatura, e rigirare la versione tedesca in tema scuro sei settimane dopo perché combaci con le altre non è certo il modo ideale di passare un pomeriggio.
- La deriva dell'interfaccia manda fuori gioco tutto in un colpo solo. Basta spostare un pulsante e ogni registrazione che lo toccava diventa sottilmente sbagliata. Dato che la registrazione è fatta di pixel, non c'è modo di "rieseguirla" — si rigira, a mano, quattordici volte, per ogni demo toccata dalla modifica.
- La localizzazione è un secondo lavoro. Il SaaS registra qualunque lingua capiti di avere sullo schermo. Tenere sette versioni linguistiche di una dozzina di demo perfettamente allineate al prodotto è un ruolo di gestione dei contenuti a tempo pieno che non abbiamo e non vogliamo.
La conclusione onesta è che questa categoria di strumenti è pensata per un mondo in cui una demo si realizza una volta e resta valida per mesi. Il nostro mondo è l'opposto: la demo va rigenerata di continuo, in ogni tema e in ogni lingua, a partire da un prodotto che non sta mai fermo.
La leva che avevamo già
Ecco il tassello che ha reso realistico — e non avventato — costruirci il nostro strumento. La nostra pagina pubblica /demo non simula l'app — monta il vero frontend desktop nel browser, gli stessi componenti React, lo stesso CSS, lo stesso i18n, con le chiamate al backend sostituite da mock. Ogni modifica all'interfaccia dell'app desktop confluisce già in automatico nella demo, perché la demo è l'app.
Questo significava che non ci serviva uno strumento per "catturare" la nostra app. Ci serviva uno strumento per pilotarla — e visto che l'app gira già nel browser e sa già come mostrarsi in qualsiasi tema e in qualsiasi lingua, gli assi del tema e della lingua venivano praticamente gratis.
Cosa abbiamo costruito
Internamente lo chiamiamo Demo Studio. Il cambio di prospettiva è minimo e cambia tutto: registriamo uno script di azioni, non un video di pixel.
Registrazione per dimostrazione
Si attiva la modalità di cattura e si percorre il flusso una volta, in una sola lingua e con un solo tema. Lo Studio non registra lo schermo. Registra ciò che si è fatto — un elenco di eventi semantici: "clicca questo elemento", "scorri fin qui", "apri questo pannello" — ognuno legato a un selettore risolvibile, alle precondizioni che gli servono e a un timestamp. In riproduzione, l'elemento cliccato lampeggia così chi guarda può seguire l'azione, senza i tremolii del cursore con cui si scontrano i registratori di schermo.
Uno script, quattordici rendering
Quel singolo script viene poi affidato a un browser headless che lo riproduce e ne cattura il risultato — una volta per tema, una volta per lingua. Una sola sessione di registrazione produce tutti e quattordici i video WebM e i fotogrammi corrispondenti, in modo deterministico, perché è lo stesso script a pilotare la stessa app reale con tema e lingua impostati di volta in volta. La versione tedesca in tema scuro e quella inglese in tema chiaro mostrano con certezza azioni identiche, perché nascono dallo stesso identico script.
Una timeline degli effetti — e un'IA che li suggerisce
Sopra la riproduzione grezza c'è una timeline per le rifiniture di cui ha bisogno una buona demo: fare zoom su una regione, far pulsare un controllo, sovrapporre una didascalia. C'è anche un passaggio "Ask Claude" che propone una traccia di effetti per uno script, così la prima bozza del "dove conviene zoomare?" arriva già pronta, invece di essere sistemata fotogramma per fotogramma.
Slot che si tengono onesti da soli
Ogni punto in cui una demo compare sul sito è un <DemoMedia slot="..."/> nel codice. Lo Studio scandaglia l'intero codebase in cerca di questi slot e mostra, a colpo d'occhio, quali sono registrati per intero in ogni tema e in ogni lingua, quali sono privi di un rendering e quali cartelle multimediali sono rimaste orfane perché lo slot a cui appartenevano è stato eliminato. È lo strumento a segnalare cosa è ormai vecchio, invece di scoprirlo da un cliente.
L'economia si è ribaltata in sordina
Il senso di tutto questo non sono le funzionalità. È ciò che è successo alla curva dei costi. Con il SaaS, il costo marginale di una modifica all'interfaccia era "rigira ogni demo interessata, quattordici volte ciascuna, a mano". Con Demo Studio, il costo marginale di una modifica all'interfaccia è premere «rigenera». Lo script è ancora valido — descrive azioni, e le azioni ci sono ancora — quindi la correzione è tempo macchina, non tempo umano.
Aggiungere una nuova lingua voleva dire rigirarci ogni demo. Ora è solo un valore in più sull'asse delle lingue. Aggiungere un tema era la stessa storia. Il lavoro che prima cresceva in modo lineare con (temi × lingue × demo × cadenza di rilascio) ora cresce con il numero di flussi distinti, e il resto è rendering.
Il fenomeno più ampio di cui questo è un sintomo
Per decenni la risposta di default a "ci serve uno strumento per X" è stata "affittalo". Costruirselo era costoso, lento e una distrazione dal prodotto vero e proprio, così è nata un'intera industria che vende strumenti ristretti, fatturati per postazione, ciascuno capace di svolgere un solo compito in modo dignitoso per tutti. Il confine tra fare e affittare stava ben spostato dal lato dell'"affitto", e gran parte degli strumenti interni viveva dal lato sbagliato di un costo di costruzione che nessuno riusciva a giustificare.
Quel confine si è spostato. Con un agente di coding basato sull'IA nel flusso di lavoro, oggi un piccolo team può costruire uno strumento interno su misura — modellato sul suo problema esatto, non sulla media dei problemi di mille clienti — nel tempo che prima serviva per valutare i fornitori. Demo Studio non è stato un progetto lungo un trimestre. È stata una manciata di giorni ben concentrati, e si adatta alla nostra realtà a due temi, sette lingue e in perenne movimento meglio di qualsiasi prodotto generalista, perché è nato esattamente per questo e per nient'altro.
Ecco la parte su cui vale la pena fermarsi. Buona parte dell'ecosistema del software-as-a-service si regge sulla vecchia economia del fare-contro-affittare — sul presupposto che costruirsi la propria versione di uno strumento ristretto sia antieconomico, e che quindi si pagherà per postazione per sempre. Quando il costo di costruire la cosa su misura crolla, quel presupposto smette di reggere. Gli strumenti più esposti non sono le piattaforme profonde e difficili da replicare; sono quelli sottili — i prodotti del tipo "facciamo un unico flusso di lavoro fatto bene e lo facciamo pagare a ogni utente" che oggi un team capace può mettere in piedi in casa, ritagliato esattamente sulla propria forma, in un pomeriggio.
Non abbiamo costruito un Demo Studio perché volessimo entrare nel mercato degli strumenti per le demo. L'abbiamo costruito perché di colpo è diventato più conveniente costruire la cosa giusta che continuare a combattere con quella affittata. Questo calcolo verrà fatto, in sordina, in molte aziende nei prossimi anni — e ogni volta che accadrà, un altro pezzo di quello che era un abbonamento diventerà un weekend di codice interamente di proprietà.
Come tutto questo si lega a ciò che facciamo
È lo stesso istinto che guida promptShield. La risposta più diffusa a "lascia che l'IA ti aiuti con i tuoi documenti" è affidare i propri file a un servizio cloud e fidarsi dei termini di servizio. Noi pensiamo che la risposta migliore, quando lo strumento costa abbastanza poco da farlo bene, sia tenere i dati sulla propria macchina e mandare all'IA solo ciò che le serve. Demo Studio è quello stesso istinto rivolto verso l'interno: quando costruire la cosa su misura costa poco, si smette di affittare il compromesso.
