El problema de los releases grandes
Durante años, nuestro enfoque fue agrupar funcionalidades en releases grandes. Diseñar, construir, QA, deploy — todo en un solo lote. Parecía productivo, pero era una trampa. Releases grandes significan grandes riesgos, ciclos de feedback largos y rollbacks dolorosos.
Entran los feature flags
Los feature flags permiten deployar código sin exponerlo a los usuarios. El código está en producción, pero oculto detrás de un toggle. Este concepto simple cambió todo.
Separar el deploy del release
El mayor cambio fue mental. Deployar código ya no significaba lanzar una feature. Los ingenieros podían mergear a main todos los días sin preocuparse por trabajo incompleto llegando a los usuarios.
Rollouts progresivos
En vez de lanzamientos todo-o-nada, empezamos a hacer rollout al 5% de los usuarios, luego 20%, luego 50%. Esto nos dio datos reales de uso antes de la exposición total.
Kill switches para la tranquilidad
Cuando una feature causa problemas en producción, la solución más rápida es apagarla. Los feature flags nos dieron rollback instantáneo sin deployments ni hotfixes.
Cómo los implementamos
Usamos un enfoque simple: un servicio de configuración que mapea nombres de flags a valores booleanos por entorno. Nada complejo — sin SaaS de terceros, sin reglas de targeting elaboradas.
El impacto en producto
Los feature flags cambiaron nuestra cultura de "shipear cuando es perfecto" a "shipear cuando es seguro aprender." El resultado: shipenmos 3x más frecuentemente con menos incidentes.
