La demo siempre sale bien. Siempre. Y no porque nadie engañe, sino porque una demo se hace en las mejores condiciones que existirán jamás.
La ejecuta quien construyó la cosa. Con datos que conoce. En un orden que ha repetido cinco veces. Sin nadie más usando el sistema a la vez. Sin la API de terceros teniendo un mal día. Sin el cliente que escribe su nombre en mayúsculas con un emoji al final.
Por eso “funciona” nunca me ha parecido un criterio de entrega. Es el punto de partida, no la meta. Lo que enseña una demo es que el camino feliz existe. Estupendo. El negocio no se rompe en el camino feliz.
Lo que la demo no puede enseñarte
Un sistema en producción vive rodeado de cosas que no controlas, y ahí es donde aparecen los problemas de verdad.
Falla lo de fuera. La pasarela de pago tarda ocho segundos en responder. El CRM devuelve un error de límite de peticiones justo el día del lanzamiento. Un servicio cambia un campo de su respuesta sin avisar a nadie.
Llegan datos raros. Un teléfono con prefijo internacional escrito de tres formas distintas. Un email con espacio al final. Un formulario enviado dos veces porque el usuario tenía mala cobertura y le dio otra vez al botón.
Y llegan a la vez. Lo que funciona con un registro por minuto no tiene por qué funcionar con trescientos en cinco minutos, que es exactamente lo que pasa cuando un vídeo funciona o se abre un carrito.
Ninguna de esas tres cosas aparece en una demo. Las tres aparecen en producción, normalmente el mismo día.
Las cuatro preguntas del día malo
No tengo una lista de cincuenta puntos. Tengo cuatro preguntas, y las hago siempre, sea un desarrollo a medida o una automatización de diez minutos. Si alguna se queda sin respuesta clara, para mí el trabajo no está terminado aunque la funcionalidad esté hecha.
¿Qué pasa si el sistema del que depende no responde? No “si falla”, que eso ya se contempla. Si no responde: si se queda colgado, si tarda veinte segundos, si devuelve un error raro. Necesito saber si el proceso reintenta, cuántas veces, con qué espera entre intentos, y qué hace cuando se rinde. Un flujo que se rinde en silencio es peor que uno que no existe, porque el que no existe al menos nadie cree que esté cubriéndole.
¿Qué pasa si el mismo evento llega dos veces? Los webhooks se repiten. Es normal y está en la documentación de casi todos los proveedores. La pregunta es si tu sistema lo sabe. Si el mismo aviso de pago crea dos accesos, dos contactos y dos emails, no tienes un sistema, tienes un generador de trabajo manual. El detalle de cómo se depuran estos casos lo cuento en webhook de n8n que no funciona.
¿Quién se entera si esto falla un domingo por la noche? Esta es la que más incomoda, y por eso la hago siempre. Si la respuesta es “lo veríamos el lunes”, vale, puede ser aceptable según lo que haga el proceso. Si la respuesta es “un cliente nos escribiría”, entonces tu sistema de monitorización son tus clientes enfadados. Eso lo desarrollo entero en automatizaciones que fallan en silencio.
¿Cómo se deshace si sale mal? Si un proceso da accesos, cobra o envía correos, quiero saber cómo se revierte antes de encenderlo. No después. Un botón, un script, un procedimiento escrito, me da igual el formato. Lo que no vale es descubrir el camino de vuelta en mitad del incidente.
Por qué esto no es perfeccionismo
Lo digo porque me lo han dicho: que así todo tarda más.
Sí, la entrega tarda más. Y el año siguiente cuesta mucho menos.
Una incidencia prevenida cuesta unas horas de trabajo tranquilo. La misma incidencia en caliente cuesta esas horas más el coste de tenerte a ti apagando el fuego, más los clientes afectados, más las decisiones improvisadas a las once de la noche que luego hay que deshacer. Nadie contabiliza esa diferencia porque una de las dos facturas no llega nunca, pero está ahí.
Y hay una parte menos medible que a mí me importa igual: poder dormir. Un sistema que puede fallar sin avisar te obliga a estar pendiente para siempre. Uno que avisa te devuelve la cabeza.
El listón que uso
No es “funciona”. Es “sé por qué funciona y sé qué hace cuando deje de funcionar”.
Esa segunda mitad es la que separa un entregable de un sistema. Y no depende de la tecnología ni de si lo has escrito tú o lo ha generado una herramienta: depende de si alguien se ha sentado a pensar en el día malo antes de que llegue.
Si estás a punto de aprobar algo, hazle las cuatro preguntas a quien te lo entrega. No hace falta que seas técnico para entender las respuestas. Y si alguna se responde con un “bueno, eso no debería pasar”, ya sabes exactamente por dónde se va a romper.
Preguntas frecuentes
¿Qué significa que una demo engaña?
Significa que una demo se ejecuta en las mejores condiciones posibles: la hace quien construyó el sistema, con datos que conoce, en un orden que ha ensayado y sin nadie más usándolo a la vez. Producción es justo lo contrario, así que una demo perfecta solo demuestra que el camino feliz existe, no que el sistema aguante.
¿Qué preguntas hago antes de aprobar un desarrollo?
Qué pasa si el servicio del que depende no responde, qué pasa si el mismo aviso llega dos veces, quién se entera si falla un domingo por la noche, y cómo se deshace si sale mal. Si alguna respuesta es un silencio, el trabajo no está terminado aunque la funcionalidad esté hecha.
¿Esto no encarece cada proyecto?
Encarece la entrega y abarata el año siguiente. Las incidencias que se resuelven en caliente cuestan más que las que se previenen, porque llegan en el peor momento, con clientes mirando y con alguien improvisando. El listón alto no es perfeccionismo, es dónde eliges pagar.
