METODOLOGÍA

Listo para Producción

Software que puedes poner delante de usuarios reales sin que te despierten a las 3 de la madrugada: autorización en cada endpoint, input validado, sin secretos en el cliente, manejo de errores, una suite de regresión, observabilidad, rollbacks. Un demo que funciona no es estar listo para producción.

Última revisión: porChristof Jori wiki ↗

Listo para producción es la diferencia entre software que funciona cuando lo demostras y software que funciona cuando estás dormido y un extraño lo usa mal. No es una sensación ni un hito que declaras. Es una checklist concreta, y el hueco entre un demo y estar listo para producción es exactamente la lista de cosas que no tienen recompensa visible hasta el momento en que fallan.

La checklist, dicha sin rodeos: autorización en cada endpoint, no solo autenticación en el login; validación de input en todo lo que cruza una frontera de confianza; ningún secreto en el bundle del cliente ni en el repo; manejo de errores que falla de forma segura en vez de filtrar un stack trace; una suite de regresión que corre en cada cambio para que el siguiente arreglo no reabra un bug viejo; observabilidad para enterarte por un dashboard, no por un cliente furioso; y un camino de rollback medido en minutos. Si falta cualquiera de estos, tienes un demo disfrazado de producción.

Ejemplo. Dos versiones de la misma app de reservas se ven idénticas en un demo. La versión A devuelve una reserva por ID tras comprobar solo que estás logueado. La versión B comprueba que el usuario logueado de verdad sea dueño de esa reserva, valida el formato del ID, registra el acceso y alerta si una cuenta empieza a enumerar IDs. Mismas pantallas, mismo happy path, mismo demo. La versión A es una brecha esperando a alguien curioso; la versión B está lista para producción. El producto visible para el usuario es idéntico, que es justo por qué “funciona en el demo” no te dice nada sobre estar listo para producción.

El trade-off honesto: llegar a estar listo para producción cuesta tiempo real, y la mayor parte de ese tiempo no compra nada que un cliente vaya a ver o a agradecerte jamás. Eso es genuinamente frustrante cuando un demo ya parece terminado, y es la única razón por la que los equipos lanzan antes de tiempo. El trato no es opcional para nada que guarde datos de usuarios, pero es honesto admitir que la factura se siente como puro overhead, hasta que el aviso de las 3 de la madrugada o la carta de RGPD la convierten en el dinero más barato que gastaste nunca. Para un prototipo de verdad desechable, saltárselo es la decisión correcta.

El pase de production-readiness de Wavect es el puente de un prototipo vibe-coded o generado por IA a algo por lo que puedes cobrar, bajo Software Quality Assurance. Trabajamos la checklist en orden de radio de impacto: autorización primero, porque ahí viven los peores bugs, luego validación, secretos, manejo de errores, y después la suite de regresión con TDD y el gate de CI/CD que la mantiene en verde. El objetivo no es la perfección. El objetivo es que nadie te despierte a las 3 de la madrugada por algo que podrías haber leído antes de lanzar.

// FAQ

Preguntas frecuentes

En concreto: autorización en cada endpoint, input validado, sin secretos en el cliente, manejo de errores que falla seguro, una suite de regresión que corre en cada cambio, observabilidad y un camino de rollback rápido. Es una checklist, no una sensación. Un demo que funciona no prueba que ninguna de estas exista.
Un demo solo ejercita el happy path que recorres. Producción ejercita el camino hostil, el usuario descuidado, el usuario curioso que cambia un ID en la URL, el input inesperado, la carga concurrente. Estar listo para producción es precisamente el trabajo que el demo del happy path nunca toca ni revela como faltante.
Depende de cómo se construyó el prototipo, pero como los huecos del código generado por IA son sistemáticos, el pase suele ser más rápido de lo que se teme. Trabajamos en orden de radio de impacto (autorización, luego validación, secretos, manejo de errores, y después tests y el gate de CI) para que los huecos más arriesgados se cierren primero aunque el presupuesto se quede corto.