Feature flags: por qué los necesitas y cómo implementarlos en Next.js

Un feature flag (o feature toggle) es una decisión que toma tu app en tiempo de ejecución: "¿esta parte del producto está activa para este usuario, en este entorno, ahora mismo?" No reemplaza un buen diseño ni los tests, pero cambia qué tan seguro y gradual puedes mover código a producción.

Por qué los uso en cada feature nuevo

Cuando desarrollo algo nuevo, lo envuelvo en un flag salvo que sea trivial y reversible en segundos. Los motivos son prácticos:

1. Rollback sin redeploy: si algo sale mal en producción, apagas el flag y vuelves al comportamiento anterior sin esperar un pipeline completo. El fix puede llegar después, con calma.
2. Rollout por audiencia: puedes mostrar un cambio solo a un cliente, a un porcentaje de usuarios, a un país, o a beta testers, mientras el resto sigue en la versión estable.
3. Menos miedo al merge: el código llega a main detrás del flag, lo que reduce ramas largas y conflictos grandes.

Dicho eso, los flags acumulan deuda: cuando el comportamiento nuevo es el estándar, hay que retirarlos. Un repositorio lleno de flags viejos es un laberinto de condiciones difícil de mantener.

Cómo encajan en Next.js

El reto con Next.js es coordinar servidor y cliente. El HTML que genera el servidor y lo que hidrata React deben contar la misma historia si el flag afecta UI visible o datos importantes.

Algunas pautas prácticas:

• Server Components / RSC: evalúa el flag en el servidor cuando el resultado debe influir en el HTML inicial o en datos sensibles. Ten en cuenta que un flag "por usuario" implica contenido dinámico — no puedes usar caché estático para eso.
• Client Components: útil para UI que cambia después de hidratar o para detalles que no afectan el primer render. Evita que servidor y cliente divergan en lo que muestran.
• Middleware: encaja para redirecciones tempranas o experimentos de enrutamiento. No es el lugar para lógica de negocio compleja.
• Identidad del usuario: para segmentación ("solo para este cliente"), necesitas un identificador estable — cuenta, tenant, cookie firmada. Sin identidad, solo puedes hacer porcentajes anónimos o reglas por entorno.

LaunchDarkly: experiencia real

He trabajado bastante con LaunchDarkly y la integración con React ha sido muy buena: los hooks y componentes encajan bien con el modelo mental de "leer estado remoto y re-renderizar". Su soporte para backend (Node, otros runtimes) también es sólido, lo que permite tomar la misma decisión de flag en API routes y servicios.

Lo que más uso en el día a día:

• Encender y apagar un cambio desde el panel, sin tocar código.
• Variantes y A/B testing: no solo booleanos — útil cuando quieres medir el impacto de un cambio, no solo ocultarlo.
• Tests E2E con Playwright: en CI puedes forzar flags a valores conocidos para que las rutas críticas no dependan de un experimento aleatorio. Esto elimina flakiness — esos fallos que aparecen y desaparecen sin razón clara.

Lo importante más allá de la herramienta: documentar qué flags existen, quién es el responsable de cada uno y cuándo deben eliminarse.

Otras opciones

No hace falta usar un solo proveedor. Según tu presupuesto, si prefieres self-hosting o qué tan acoplado quieres estar a tu plataforma, hay buenas alternativas:

• Vercel Flags SDK: integración nativa con Next.js, soporta precompute para páginas estáticas y es compatible con múltiples proveedores. Documentación.
• Statsig: buenas herramientas para rollouts y experimentación en Next.js. Guía.
• ConfigCat: tutorial paso a paso con SSR. Tutorial.
• Flagsmith: open source, con guías para App Router. Ejemplo en DEV.
• GrowthBook, Unleash, Flipt: otras opciones open source con diferentes niveles de complejidad.
• Variables de entorno: para casos simples donde el flag no cambia en tiempo de ejecución, a veces es suficiente.

Lo importante no es la herramienta — es tener un contrato claro: quién evalúa el flag, con qué identidad, y cómo se observa el impacto en logs o analytics.

Resumen

Los feature flags son una palanca operativa: despliegues más seguros, rollbacks rápidos, pruebas con audiencias reales y tests E2E estables cuando controlas los valores en CI. LaunchDarkly ha sido una opción sólida en mi experiencia, pero el ecosistema es amplio — elige según el tamaño de tu equipo, tus requisitos de compliance y cómo quieres monitorear el impacto en producción.