Feature flags sin dueño: la deuda técnica que nadie ve venir
Imagina que lanzas una nueva funcionalidad en tu sistema. Para reducir el riesgo, usas un feature flag: activas la nueva versión para el 80% de tus usuarios y dejas al 20% restante en el camino anterior, mientras monitoreas. Hasta ahí, todo bien. El problema empieza cuando ese 20% no termina de migrar.
Alguien anota la excepción como "temporal" en una hoja de cálculo. Pasan seis meses. Nadie sabe quién aprobó esa excepción, si hay un contrato que la obliga, cuántos usuarios reales siguen ahí, ni cuánto cuesta mantener dos rutas de código en paralelo. El flag dejó de ser una herramienta de despliegue seguro y se convirtió en la fundación invisible de dos productos distintos.
Este es uno de los problemas más frecuentes —y menos visibles— en equipos de desarrollo que escalan. Un artículo publicado el 23 de julio de 2026 en Dev.to propone una solución concreta: tratar cada excepción de feature flag como una decisión formal con costo documentado, dueño asignado y fecha de vencimiento. En este artículo exploramos esa propuesta y cómo aplicarla en equipos de software en Perú y Latinoamérica.
El ledger de excepciones: documentar para decidir
La propuesta central del artículo es reemplazar la hoja de cálculo informal por un registro estructurado de decisiones (un "ledger"). Cada excepción activa debe tener como mínimo: un nombre claro, el dueño responsable, la población afectada, la fecha de creación, la fecha de vencimiento, la razón documentada, evidencia observable y el costo estimado de remoción.
La diferencia con lo que hacen la mayoría de equipos es sutil pero poderosa. No se trata de burocracia, sino de convertir una decisión implícita en una decisión explícita. "Seguimos necesitando esto" no es evidencia. "El cliente A validará el 8 de agosto y removemos después de siete días limpios" sí lo es.
Este enfoque obliga a que alguien sea responsable de cada excepción en cada ciclo de revisión. Si nadie puede nombrar al dueño actual y mostrar datos de uso recientes, la renovación queda bloqueada. Es un mecanismo de presión positiva: hace que mantener una excepción viva sea más costoso en información que en ceremonia administrativa.
Ponerle precio a la excepción: el modelo de costo
El aspecto más valioso del enfoque es la estimación de costo mensual de cada excepción activa. El artículo propone una fórmula simple: el costo total es la suma de horas de cobertura de regresión duplicada, diagnóstico de soporte adicional, coordinación de releases y trabajo esperado en incidentes, multiplicado por la tarifa cargada de cada rol.
En el ejemplo ilustrativo del artículo, una sola excepción para dos clientes genera aproximadamente $1,550 dólares al mes en carga operativa real. Con ese número visible, la decisión cambia de naturaleza. Migrar a esos dos clientes cuesta $4,500 una sola vez. El punto de equilibrio simple es menos de tres meses.
Lo importante aquí no es la exactitud del número, sino lo que revela. El modelo no elige por el equipo, pero deja en evidencia qué supuesto cambia la respuesta. Si el costo mensual real es $800 en lugar de $1,550, el break-even se extiende a 5.6 meses. Si es $2,400, baja a 1.9 meses. Esa sensibilidad es la información que necesita un líder técnico para tomar una decisión fundamentada.
Antes de hacer ese cálculo, el artículo propone verificar cuatro compuertas no negociables: seguridad (¿remover la excepción puede causar pérdida de datos?), contrato (¿hay un compromiso legal vigente?), observabilidad (¿el equipo puede identificar cada request afectado?) y reversibilidad (¿existe un rollback probado?). Una compuerta fallida bloquea la eliminación. No hay aritmética que la supere.
Cómo aplica esto en equipos de software en Perú y Latinoamérica
En proyectos de software en la región, este problema tiene una forma muy reconocible. Un cliente enterprise pide una excepción para no migrar todavía. El equipo la acepta porque el cliente es importante. Se anota en algún lado y se olvida. Seis meses después, ese cliente sigue en el camino viejo, el código se ha bifurcado en dos versiones y cada nuevo feature hay que probarlo dos veces.
Lo que hace difícil resolver esto no es la tecnología, sino la visibilidad. Nadie tiene un número claro de cuánto cuesta esa excepción cada mes. Sin ese número, la conversación con el cliente o con la gerencia siempre termina igual: "por ahora lo dejamos así".
El ledger de excepciones resuelve exactamente eso. Cuando puedes decirle a un gerente de producto o a un cliente: "mantener esta excepción activa nos cuesta X dólares al mes en carga operativa, y migrarlos cuesta Y una sola vez", la conversación cambia. Ya no es una discusión técnica abstracta. Es una decisión de negocio con números reales.
Para equipos más pequeños, no hace falta una herramienta sofisticada. Un documento compartido con los campos mínimos —dueño, vencimiento, evidencia, costo estimado— y una revisión mensual es suficiente para empezar a hacer visible lo que hoy es invisible.
¿Cómo aplica esto en tu empresa?
Si tu equipo usa feature flags en producción, este es un buen momento para hacer una auditoría rápida. Revisa cuántas excepciones activas tienen más de 90 días sin revisión formal. Para cada una, pregunta: ¿quién es el dueño hoy? ¿Cuántos usuarios reales están en esa ruta? ¿Qué evento concreto dispararía su eliminación?
Si no puedes responder esas preguntas, tienes deuda técnica que no está en ningún backlog. El siguiente paso es estimar el costo mensual de cada excepción, aunque sea con números aproximados. Esa estimación, por imperfecta que sea, vale más que no tener ninguna.
Finalmente, establece una regla simple: ninguna excepción se renueva sin evidencia actualizada y sin un evento de remoción con fecha. No para agregar burocracia, sino para que cada decisión de mantener una excepción sea una decisión consciente, no un olvido.
Conclusión
Los feature flags son una herramienta poderosa para reducir riesgo en despliegues. Pero sin un proceso formal de gestión, las excepciones se acumulan silenciosamente hasta convertirse en la arquitectura real del sistema. La propuesta del ledger de excepciones es elegante porque no agrega complejidad: agrega visibilidad. Y con visibilidad, las decisiones mejoran solas.
La pregunta que propone el artículo es la correcta: no cuántos flags tienes, sino ¿cuál es el umbral observado que hace más barato remover esta excepción que renovarla?
Si estás trabajando en un proyecto de software y quieres revisar cómo están gestionando sus feature flags y deuda técnica, en Consultoría-Ti podemos ayudarte a hacer esa auditoría y definir un proceso que funcione para tu equipo. Contáctanos aquí y conversamos sin compromiso.
Fuentes y Referencias
Dev.to — Give Every Feature-Flag Exception an Owner, Expiry, and Removal Cost
✨ Contenido generado con ContentFlow — Consultoría-Ti