Empezamos pagando por una herramienta de vídeos de demostración ya hecha, como hace la mayoría de los equipos. Luego echamos cuentas de las combinaciones: dos temas, siete idiomas y una interfaz que cambia casi cada semana. Los números no cuadraban. Así que construimos nuestro propio estudio de demostraciones — y el hecho de que un equipo de dos personas pudiera hacerlo, en cuestión de días, dice más que la propia herramienta.
El problema: una demo no es un vídeo, son catorce
promptShield se distribuye con tema claro y oscuro y en siete idiomas — inglés, francés, alemán, español, italiano, neerlandés y portugués. Por eso, una sola demo del producto — «así se oculta un contrato» — no es un único clip. Son dos temas × siete idiomas = catorce renderizados, y cada uno muestra exactamente las mismas acciones sobre una interfaz que tiene que verse nativa en ese idioma y correcta en ese tema.
Ahora multiplique eso por cada demo del sitio de marketing y, encima, recuerde que la aplicación que hay debajo es un blanco móvil. Cambiamos diseños, renombramos botones, afinamos el espaciado y añadimos funciones con una cadencia semanal. Cada uno de esos cambios invalida sin avisar las grabaciones hechas sobre las pantallas antiguas.
Por qué el enfoque SaaS se vino abajo
Las herramientas del estilo de Arcade / Storylane / Supademo / Trupeer son excelentes en lo suyo: usted recorre su aplicación a base de clics, ellas capturan la pantalla y usted obtiene un recorrido pulido. Pero todas parten de una misma premisa — que una demo es un artefacto de píxeles capturados. Esa premisa es justo lo que se desmorona a nuestra escala:
- La explosión combinatoria es manual. Catorce variantes de una demo significan catorce tomas grabadas a mano. Nadie graba el mismo flujo catorce veces seguidas sin que se le vaya la mano, y volver a grabar la versión en alemán y modo oscuro seis semanas después para que cuadre con las demás no le apetece a nadie.
- La deriva de la interfaz lo deja todo huérfano de golpe. Mueva un botón y todas las grabaciones que lo tocaban quedan sutilmente mal. Como la grabación son píxeles, no hay manera de «volver a ejecutarla» — se regraba, a mano, catorce veces, por cada demo a la que afecte el cambio.
- La localización es un segundo trabajo. El SaaS graba el idioma que hubiera en pantalla en ese momento. Mantener siete versiones idiomáticas de una docena de demos perfectamente sincronizadas con el producto es un puesto de contenidos a jornada completa que ni tenemos ni queremos.
La conclusión sincera fue que esta categoría de herramientas está pensada para un mundo en el que uno hace una demo una vez y sigue siendo fiel durante meses. Nuestro mundo es el contrario: la demo hay que regenerarla constantemente, en todos los temas y todos los idiomas, a partir de un producto que nunca se queda quieto.
La pieza clave que ya teníamos
Esta es la parte que hizo que construir el nuestro fuera realista y no una temeridad. Nuestra página pública /demo no imita la aplicación — monta el frontend real de escritorio en el navegador, los mismos componentes de React, el mismo CSS, la misma i18n, con las llamadas al backend sustituidas por mocks. Cada cambio de interfaz que hacemos en la aplicación de escritorio ya se traslada a la demo automáticamente, porque la demo es la aplicación.
Eso significaba que no nos hacía falta una herramienta para «capturar» nuestra aplicación. Nos hacía falta una herramienta para manejarla — y como la aplicación ya se ejecuta en el navegador y ya sabe renderizarse en cualquier tema y cualquier idioma, los ejes de tema e idioma salían prácticamente gratis.
Lo que construimos
Internamente lo llamamos Demo Studio. El giro mental es pequeño y lo cambia todo: grabamos un guion de acciones, no un vídeo de píxeles.
Grabar por demostración
Usted activa el modo de captura y recorre el flujo una vez, en un idioma y un tema. El Studio no graba la pantalla. Graba lo que hizo — una lista de eventos semánticos: «haz clic en este elemento», «desplázate hasta aquí», «abre este panel» — cada uno vinculado a un selector localizable, las precondiciones que necesita y una marca de tiempo. Al reproducirlo, el elemento pulsado parpadea para que quien lo vea pueda seguir la acción, sin nada del tembloroso seguimiento del cursor contra el que luchan los grabadores de pantalla.
Un guion, catorce renderizados
Ese único guion se entrega después a un navegador headless que lo reproduce y captura el resultado — una vez por tema, una vez por idioma. Una sola sesión de grabación produce los catorce vídeos WebM y sus fotogramas fijos correspondientes, de forma determinista, porque es el mismo guion manejando la misma aplicación real con el tema y la configuración regional fijados en cada pasada. La versión en alemán y modo oscuro y la versión en inglés y modo claro tienen garantizado mostrar acciones idénticas, porque salieron del mismo guion.
Una línea de tiempo de efectos — y una IA que los sugiere
Sobre la reproducción en bruto se asienta una línea de tiempo para el acabado que necesita una buena demo: hacer zoom sobre una zona, resaltar un control, superponer un rótulo. También hay un paso «Ask Claude» que propone una pista de efectos para un guion, de modo que la primera pasada de «¿dónde hacemos zoom?» ya viene esbozada en lugar de tener que ajustarla fotograma a fotograma.
Slots que se mantienen fieles por sí solos
Cada sitio donde aparece una demo en la web es un <DemoMedia slot="..."/> en el código. El Studio rastrea toda la base de código en su busca y le muestra, de un vistazo, qué slots están completamente grabados en todos los temas e idiomas, a cuáles les falta un renderizado y qué directorios de medios se han quedado huérfanos porque se eliminó el slot al que pertenecían. La herramienta le dice qué está obsoleto en lugar de que se entere por un cliente.
La economía se invirtió sin hacer ruido
Lo importante de todo esto no son las funciones. Es lo que le ocurrió a la curva de costes. Con el SaaS, el coste marginal de un cambio de interfaz era «regrabar cada demo afectada, catorce veces cada una, a mano». Con Demo Studio, el coste marginal de un cambio de interfaz es pulsar «volver a renderizar». El guion sigue siendo válido — describe acciones, y las acciones siguen existiendo — así que el arreglo es tiempo de máquina, no de personas.
Añadir un idioma nuevo solía significar regrabar en él todas las demos. Ahora es un valor más en el eje de idioma. Añadir un tema era exactamente igual. El trabajo que antes escalaba de forma lineal con (temas × idiomas × demos × cadencia de versiones) ahora escala con el número de flujos distintos, y el resto es renderizado.
El asunto de fondo del que esto es un síntoma
Durante décadas, la respuesta por defecto a «necesitamos una herramienta para X» era «alquílela». Construir una versión propia salía caro, lento y era una distracción del producto de verdad, así que creció toda una industria vendiendo herramientas estrechas, facturadas por puesto, cada una capaz de hacer un único trabajo de forma pasable para todo el mundo. La frontera entre construir y alquilar estaba muy escorada hacia «alquilar», y la mayoría de las herramientas internas vivían en el lado equivocado de un coste de construcción que nadie podía justificar.
Esa frontera se ha movido. Con un agente de programación con IA de por medio, un equipo pequeño puede ahora construir una herramienta interna a medida — moldeada a su problema exacto, no al promedio de los problemas de mil clientes — en el tiempo que antes costaba evaluar proveedores. Demo Studio no fue un proyecto de un trimestre. Fue un puñado de días concentrados, y encaja con nuestra realidad de dos temas, siete idiomas y movimiento constante mejor de lo que jamás podría hacerlo cualquier producto de propósito general, porque se construyó exactamente para eso y nada más.
Esta es la parte en la que merece la pena detenerse. Buena parte del ecosistema del software como servicio está construida sobre la vieja economía de construir frente a alquilar — sobre la premisa de que construir su propia versión de una herramienta estrecha no es rentable, así que pagará por usuario indefinidamente. Cuando el coste de construir la cosa a medida se desploma, esa premisa deja de sostenerse. Las herramientas más expuestas no son las plataformas profundas y difíciles de replicar; son las finas — los productos del tipo «hacemos un flujo de trabajo limpio y le cobramos por él a cada usuario» que un equipo capaz puede ahora montar en casa, ajustado exactamente a su propia forma, en una tarde.
No construimos un estudio de demostraciones porque quisiéramos dedicarnos al negocio de las herramientas de demos. Lo construimos porque de repente salía más barato construir lo correcto que seguir peleándonos con lo alquilado. Ese cálculo se va a hacer, sin ruido, en muchas empresas a lo largo de los próximos años — y cada vez que se haga, un poco más de lo que antes era una suscripción se convierte en el equivalente a un fin de semana de código que usted posee por completo.
Cómo conecta esto con lo que hacemos
Es el mismo instinto que impulsa a promptShield. La respuesta habitual a «deje que la IA le eche una mano con sus documentos» es entregarle sus archivos a un servicio en la nube y fiarse de sus términos de uso. Nosotros creemos que la mejor respuesta, cuando la herramienta es lo bastante barata de construir bien, es mantener los datos en su ordenador y enviar a la IA solo lo que necesita. Demo Studio es ese mismo instinto apuntado hacia dentro: cuando construir lo hecho a medida se abarata, deje de alquilar el término medio.
