Feature flags hardcodeados: la decisión aburrida que salva a tu startup

El mercado del feature flagging te quiere vender algo que probablemente no necesitás

Un feature flag (o toggle) es un interruptor que controla si una funcionalidad está activa o no en producción. Desde hace unos años, varias plataformas — LaunchDarkly, Split, Statsig, GrowthBook — convirtieron esa idea en un producto empresarial con dashboard, segmentación por usuario, kill switches y análisis. Mendhak, ingeniero con años en grandes equipos, escribió en su blog un argumento incómodo: para la mayoría de equipos, lo más sensato es hardcodear los flags en un archivo JSON y leerlo al iniciar la aplicación. Suena a herejía en 2026, y por eso vale la pena analizarlo.

La razón es sencilla: cada pieza de software que añadís a tu stack es una superficie nueva de ataque, un proveedor que monitorear, una factura que pagar y un comportamiento que debuggear cuando algo se rompe en producción. La complejidad accidental no se justifica hasta que tenés un problema real que la complejidad resuelve.

Por qué los feature flag managers se venden tan bien (y por qué eso es una señal, no una garantía)

El artículo original describe con ironía cómo se presenta la necesidad: «vamos a necesitar escalar a miles de feature flags, cambiarlos en runtime, sin deploy, sin reinicio, sin flush de caché, sin migración, sin review, sin tests — porque el negocio está en llamas y la única manera de apagarlo es cambiar el color del botón de la home».

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Esa narrativa apela a un caso extremo (incidente en producción) para justificar una arquitectura que vas a mantener durante años. Según explica el glosario de phoenixNAP, hardcodear valores es un anti-pattern en sistemas grandes y dinámicos — pero también reconoce que es perfectamente válido en scripts pequeños, herramientas internas y valores estables. La clave está en qué tipo de sistema estás construyendo, no en cuál es la moda del momento.

Como founders, el instinto correcto no es «comprar la herramienta más completa», sino preguntarte qué problema concreto te resuelve hoy y si lo podés resolver con lo que ya tenés.

El problema oculto: feature flags de larga vida como deuda técnica

Hay un consenso creciente en la industria sobre un riesgo poco discutido: los flags que nunca se eliminan. La Wikipedia recoge el problema genérico del hardcoding en términos de «números mágicos» repetidos por el código que se desactualizan. Con los feature flags pasa algo parecido, pero al revés: el flag se queda, el código que controlaba se queda, y dos años después nadie se acuerda para qué servía.

El artículo de Mendhak lo describe bien desde la perspectiva del ciclo de desarrollo:

Comportamiento no determinista. El mismo código produce resultados distintos según flags, entornos y combinaciones. Razonar sobre los logs se vuelve más caro.
Deuda que se osifica. Cada flag es una rama condicional permanente. Si los清理 mal, el codebase se vuelve un campo minado.
Superficie de ataque ampliada. Cada sistema externo que controla tu producción es un vector más para un atacante o un bug.

Hardcodear el flag en un JSON no elimina estos riesgos al 100%, pero los hace visibles en el code review y los ata al proceso normal de deploy. Eso ya es una mejora enorme para equipos de 2 a 20 personas.

Cómo hardcodear feature flags sin que se te vaya de las manos

La receta que propone el post original es deliberadamente aburrida, y por eso funciona:

Un archivo JSON versionado junto al código. Algo tan simple como {"new_checkout": true, "ai_recommendations": false} en config/flags.json.
Lectura al arrancar la aplicación. Sin servicios externos, sin SDKs que mantener actualizados, sin webhooks que recibir.
Cambio via el proceso normal de desarrollo. Pull request, revisión, test, deploy. Si el cambio es urgente, se hace un hotfix como cualquier otro cambio.
Regla de los 30 días (o lo que sea). Si un flag lleva más de un mes en el código, hay dos opciones: o el flag se convierte en el comportamiento por defecto y se elimina la rama, o se justifica con nombre claro por qué sigue vivo.
Centralización y búsqueda periódica. Un único archivo (o un directorio pequeño) hace que grep "flags.json" o tu IDE te diga en segundos qué flags están activos.

Para equipos chicos, esta aproximación cubre el 90% de los casos: rollout gradual por ambiente, A/B tests simples, dark launches y kill switches manuales vía revert.

¿Cuándo SÍ vale la pena un sistema de gestión real?

Ser aburrido no significa ser dogmático. Hay señales claras de que tu JSON ya no te alcanza y necesitás algo más serio:

Segmentación por usuario en tiempo real. Quieres mostrar feature X solo al 5% de usuarios, o solo a cuentas enterprise, y necesitas cambiar el segmento sin redeploy.
Cambios ultra frecuentes. Tu equipo de producto lanza 3-4 features por semana y cada una pasa por 4-5 estados (interno, beta, canary, GA, deprecated).
Cumplimiento y auditoría. Necesitas un registro inmutable de quién cambió qué y cuándo — algo que un PR en GitHub cubre en parte, pero que en banca, salud o govtech no es suficiente.
Equipos múltiples sobre el mismo servicio. Si cinco squads tocan el mismo monolito, los flags manuales empiezan a colisionar y los merges se vuelven un infierno.

Cuando llegues a ese punto, lo vas a saber. Como dice Mendhak: «al igual que el state management en SPAs, vas a saber que lo necesitás». Y entonces sí, evaluá LaunchDarkly, Statsig o el equivalente open source que prefieras.

Qué significa esto para tu startup

Si estás pre-PMF o recién lanzando el MVP, la decisión de feature flags debería ser la más barata posible. Plataformas como LaunchDarkly tienen planes gratuitos generosos precisamente para atraer equipos temprano — y eso no es un regalo, es una trampa de lock-in. Cuando tu producto crezca y quieras migrar, vas a tener cientos de flags dispersos entre SDKs, dashboards y reglas de segmentación. Empezar con JSON te da opcionalidad.

Dos acciones concretas para esta semana:

Auditoría de 30 minutos. Abrí tu codebase y buscá cuántos feature flags activos tenés hoy. Si la respuesta es más de cinco o no recordás qué hace cada uno, tenés un problema — con o sin LaunchDarkly.
Política escrita en el README de ingeniería. Una línea basta: «Los feature flags viven en config/flags.json. Cualquier flag con más de 30 días requiere justificación en el PR o se elimina». Pegala hoy, antes de que el siguiente flag se cuele sin dueño.

La mejor arquitectura SaaS no es la más sofisticada, es la que tu equipo actual puede operar sin quemarse. Lo aburrido escala; lo complejo solo escala con presupuesto y gente que ya no tenés.