Hay una fantasía muy extendida en la industria del software: el lanzamiento como línea de llegada. El equipo hace el merge, el pipeline pasa, el producto sale a producción, y alguien abre una botella de algo. Misión cumplida.
Lo que nadie dice en voz alta es que ese momento —el deploy a producción— es precisamente cuando el riesgo real empieza. No termina. Empieza. Todo lo anterior era, en el mejor de los casos, una hipótesis bien construida. A partir del lanzamiento, esa hipótesis toca el mundo real, con usuarios reales, cargas reales, fallos que ningún entorno de staging puede predecir y decisiones de deuda técnica que ahora tienen consecuencias inmediatas.
El problema no es que los equipos no lo sepan en teoría. Es que el sistema de incentivos —plazos, demos, roadmaps trimestrales— está construido para premiar el lanzamiento y olvidar todo lo que viene después. Y ese olvido tiene un coste que se paga, siempre, con intereses.
La mayoría de los fallos críticos en producción no son bugs de código: son consecuencias de decisiones de diseño que nadie revisitó una vez que el sistema estuvo bajo carga real.
El mantenimiento no es una fase del proyecto; es la fase más larga, más cara y menos planificada de cualquier producto digital.
Un producto que no está diseñado para ser mantenido es un producto diseñado para acumular deuda a velocidad exponencial.
El Lanzamiento: Un Contrato que Acabas de Firmar
Cuando un producto sale a producción, el equipo no ha terminado un trabajo. Ha firmado un contrato de larga duración con todos los usuarios que acaban de depositar su confianza en él. Esa confianza no se otorga en el momento del registro; se construye —o se destruye— en cada interacción posterior.
El problema es que la mayoría de los equipos planifican el lanzamiento como si fuera el final del proyecto, cuando en realidad es el final del periodo de ensayo. Lo que viene después —parcheo de vulnerabilidades, actualizaciones de dependencias, respuesta a incidentes, compatibilidad con cambios en sistemas de terceros, soporte a usuarios reales con comportamientos que el QA nunca anticipó— es el trabajo real. Y no está en el roadmap de nadie.
Un ejemplo concreto: en 2021, la librería Log4j reveló una vulnerabilidad crítica (Log4Shell) que afectó a miles de sistemas en producción. La mayoría de los equipos que tuvieron que parchear en días tenían una cosa en común: no sabían exactamente qué versiones de Log4j estaban usando ni en qué partes de su stack. No porque fueran negligentes, sino porque nadie había construido visibilidad sobre las dependencias una vez que el código estaba desplegado. El lanzamiento había cerrado la conversación sobre ese tema.
Un producto en producción es un sistema vivo. Ignorarlo después del deploy no lo hace más estable; lo hace más frágil, silenciosamente.
Esto conecta directamente con algo que escribimos sobre arquitectura y propósito: las decisiones que se toman al principio, sin entender bien el problema, son las que más duelen cuando el sistema está bajo presión real. El lanzamiento es el momento en que esas decisiones dejan de ser teóricas.
Mantenimiento: El Trabajo que No Cabe en el Sprint
Hay una ilusión contable en cómo las organizaciones presupuestan el software: se asignan recursos al desarrollo (el periodo emocionante, con wireframes y kits de prensa) y se infravalora sistemáticamente el mantenimiento. El ratio estándar en la industria es conocido desde hace décadas: entre el 60% y el 80% del coste total de un sistema de software se gasta después del lanzamiento, en mantenimiento y evolución. No en construirlo. En sostenerlo.
Y sin embargo, en la mayoría de las empresas medianas con las que trabajamos, el mantenimiento no tiene su propio presupuesto. Vive parasitariamente en los sprints de desarrollo, compitiendo con nuevas features, siempre perdiendo. El resultado es predecible: se acumula deuda técnica de forma silenciosa hasta que algo se rompe en el peor momento posible.
Los tres tipos de mantenimiento que nadie planifica
No todo el mantenimiento es igual. Confundirlos lleva a priorizar mal:
Mantenimiento correctivo es el que todos reconocen: arreglar lo que está roto. Es el más visible y el que genera más urgencia. Pero si es el único tipo que existe en tu organización, significa que estás operando en modo reactivo permanente, apagando fuegos en lugar de construir sistemas que no se incendien.
Mantenimiento adaptativo es el que pocos planifican: actualizar dependencias, adaptar el sistema a cambios en APIs de terceros, garantizar compatibilidad con nuevas versiones de plataforma. Una app móvil que no actualiza sus dependencias de seguridad cada trimestre acaba con versiones de librerías con CVEs conocidas. Una app que no prueba su comportamiento en las últimas versiones de iOS o Android acaba con reseñas de una estrella en el momento más inoportuno.
Mantenimiento perfectivo es el que genera más valor a largo plazo y el que más se cancela: mejorar la arquitectura interna, reducir la deuda técnica, refactorizar módulos que han crecido más allá de lo manejable. No añade features visibles. No tiene fecha en el roadmap. Pero es lo que separa un sistema que puede evolucionar a cinco años de uno que hay que reescribir a los dos.
En Room 714 hemos visto esta dinámica repetirse: equipos que acumulan deuda técnica de forma acelerada, convencidos de que "ya lo refactorizaremos cuando tengamos tiempo". Ese tiempo nunca llega si no se reserva explícitamente.
Observabilidad: Ver el Sistema que Pusiste en Producción
Hay una pregunta que hacemos sistemáticamente cuando auditamos un producto en producción: ¿sabes exactamente qué está haciendo tu sistema ahora mismo? No en staging. No en local. En producción, con los usuarios reales que lo están usando ahora.
La respuesta honesta, en la mayoría de los casos, es no.
La observabilidad —la capacidad de entender el estado interno de un sistema a partir de sus salidas externas— no es una característica premium que añades cuando tienes presupuesto. Es la infraestructura básica que te permite gestionar un sistema vivo. Sin ella, el mantenimiento es arqueología: encuentras los problemas excavando, después de que alguien se haya quejado.
Los tres pilares clásicos son logs, métricas y trazas. Pero la observabilidad real va más allá: se trata de que, ante un incidente en producción, el equipo pueda responder en minutos a preguntas concretas. ¿Qué cambió? ¿Cuándo empezó? ¿A qué porcentaje de usuarios afecta? ¿Qué ruta de código está implicada?
Datadog, Grafana, OpenTelemetry, Sentry —hay herramientas para todos los presupuestos y stacks. El problema nunca es de herramientas. Es de voluntad organizacional para invertir en visibilidad antes de que ocurra el primer incidente grave.
La observabilidad no es para cuando algo se rompe. Es para saber que todavía no se ha roto.
El error de confundir uptime con salud
Un sistema puede tener un uptime del 99,9% y estar en estado crítico. Si las respuestas tardan el doble de lo normal, si el porcentaje de errores silenciosos ha subido un 15% en las últimas dos semanas, si una funcionalidad clave está siendo abandonada por el 40% de los usuarios a mitad del flujo —ninguna de estas señales aparece en el panel de uptime. Todas son visibles con una observabilidad bien configurada.
Confundir "el sistema no está caído" con "el sistema está sano" es uno de los errores más comunes que vemos. Y es el que convierte problemas manejables en crisis cuando finalmente se manifiestan de forma visible. Algo que también está en la raíz de lo que ocurre cuando escalas antes de entender: los síntomas se amplifican y el origen se pierde.
Estrategia: Diseñar para el Día Siguiente al Lanzamiento
La solución no es filosófica. Es estructural. Los equipos que gestionan bien el post-lanzamiento no tienen menos problemas que los demás: tienen sistemas para detectarlos antes, procesos para resolverlos más rápido y presupuesto para prevenirlos de forma continua.
Algunas decisiones concretas que marcan la diferencia:
Runbooks de incidentes antes del primer incidente. Un documento que describa los pasos exactos para responder a los fallos más probables. No hace falta que sea exhaustivo; hace falta que exista y que el equipo lo conozca.
Feature flags como infraestructura, no como truco. La capacidad de activar y desactivar funcionalidades en producción sin deploy reduce el riesgo de cada lanzamiento y permite responder a problemas en segundos en lugar de horas.
Presupuesto explícito de mantenimiento. Si el mantenimiento compite con las features en el mismo sprint, siempre pierde. Necesita su propio tiempo, su propio presupuesto, su propia visibilidad en el roadmap.
Revisión de dependencias en calendario. Mensual o trimestral según el ritmo del stack. No reactiva —no cuando ya hay un CVE crítico— sino proactiva, como revisión de inventario.
Postmortems sin culpables. Cuando algo falla en producción, el objetivo no es encontrar a quién culpar. Es entender qué condición del sistema permitió que ese fallo ocurriera, y cómo eliminamos esa condición.
Ninguna de estas prácticas es nueva. La mayoría llevan décadas en los manuales de ingeniería. El problema no es ignorarlas —es saber que existen y no tener el mandato organizacional para implementarlas, porque el roadmap siempre tiene algo más urgente.
Ese "algo más urgente" es, casi siempre, la feature que debería haberse aplazado para tener tiempo de hacer las cosas bien.
Si estás en ese punto —un producto en producción que has construido para llegar, no para mantenerse— la auditoría técnica es el primer paso. No para juzgar lo que se hizo, sino para entender exactamente qué deuda existe, qué riesgo representa y qué orden de prioridad tiene. Ese mapa es lo que permite tomar decisiones reales, en lugar de sobrevivir de sprint en sprint. Es el trabajo que hacemos en Room 714.
