Feature flags en 2026: tipos, herramientas y pruebas A/B

Las feature flags (también llamadas feature toggles) son interruptores en tiempo de ejecución que separan el despliegue del código del lanzamiento de una funcionalidad. En 2026 son el mecanismo estándar para la entrega progresiva, los kill switches, los entitlements y las pruebas A/B, y OpenFeature ha hecho reversible la elección de proveedor. Esta guía cubre los cuatro tipos de flag, el despliegue, las pruebas A/B, las herramientas y la higiene.

Qué son las feature flags y los cuatro tipos de flag

Una feature flag es un condicional cuyo valor viene de la configuración, no del build. El código pregunta "¿está new-checkout habilitada para este usuario?" y responden reglas que puedes cambiar en tiempo de ejecución. La ruta de código llega a producción; la flag decide si alguien la alcanza.

Las flags se dividen en cuatro tipos con distintos tiempos de vida, perfiles de riesgo y responsables. Confundirlos es la causa raíz de la mayor parte de la deuda de flags.

Tipo	Propósito	Tiempo de vida típico	Frecuencia de cambio	Responsable
Flag de release	Llevar código inacabado o arriesgado a producción apagado y luego liberarlo gradualmente	Días a semanas	Rara vez, luego se elimina	Equipo de la funcionalidad
Flag de experimento	Asignar usuarios aleatoriamente a variantes para medir un efecto	Duración del experimento	Nunca durante la prueba	Producto + datos
Flag operativa / kill switch	Desactivar una dependencia, degradar con elegancia, limitar la carga	Permanente	Rara vez, durante incidentes	Plataforma / SRE
Flag de permisos	Entitlements: niveles de plan, cohortes beta, usuarios internos	Permanente	Cambios por cliente	Producto / soporte

Una flag de release que sigue en el código seis meses después es un bug; un kill switch que sigue ahí seis años después está haciendo su trabajo. Las flags de permisos son lógica de negocio que casualmente usa el SDK de flags y necesitan las mismas pruebas y el mismo registro de auditoría que cualquier regla de autorización.

Por debajo, un plano de control (dashboard, reglas, registro de auditoría) alimenta a los SDKs. Los SDKs de servidor descargan el conjunto completo de reglas y evalúan en el propio proceso, así que una comprobación cuesta microsegundos y sobrevive a una caída del plano de control. Los SDKs de cliente reciben valores ya evaluados, porque enviar las reglas a un navegador filtraría segmentos y criterios de segmentación.

Cómo las feature flags cambian tu estrategia de despliegue

Sin flags, despliegue y release son el mismo evento. Con flags, el despliegue se convierte en un no-evento: el binario llega a producción con la ruta nueva apagada, y el lanzamiento ocurre después, en un dashboard, una cohorte a la vez. Ese desacoplamiento es lo que hace viable el trunk-based development: el código inacabado se fusiona en main a diario porque está detrás de una flag.

Las flags complementan los enfoques a nivel de infraestructura de nuestro post sobre despliegues blue-green, canary y rolling. La diferencia es la granularidad:

• Un despliegue canary dirige un porcentaje del tráfico a un nuevo binario. Detecta caídas y regresiones de latencia en todo el build.
• Un rollout por flag expone un porcentaje de usuarios a una nueva ruta de código dentro del mismo binario. Aísla una funcionalidad y puede segmentar por atributo: primero el personal, luego una región, luego el 10% de todos.

Una secuencia práctica:

1. Despliega con la flag apagada. Confirma que la ruta nueva emite telemetría y no hace nada para los usuarios.
2. Habilítala para empleados y QA. Corrige lo que encuentren sin otro despliegue.
3. Aumenta por porcentaje con asignación fija (sticky), vigilando la tasa de errores, la latencia y la métrica de negocio de la funcionalidad en cada paso.
4. Llega al 100%, espera un ciclo de release, elimina la flag y la ruta antigua.

Revertir un despliegue lleva minutos y afecta a todos los cambios del build; cambiar una flag lleva segundos y afecta a una funcionalidad. En un pipeline de CI/CD, eso significa menos releases de emergencia.

Una flag solo es un rollback seguro si la ruta antigua sigue funcionando. Las migraciones de base de datos son la trampa habitual: aplícalas al estilo expand-and-contract para que ambas rutas funcionen sobre el mismo esquema. Nuestra guía de migraciones de bases de datos en producción cubre el patrón.

Feature flags vs pruebas A/B: dónde está la línea

Las flags y las pruebas A/B son capas, no competidoras. Una prueba A/B es una flag más tres cosas que las flags no ofrecen: aleatorización, medición y estadística.

Aspecto	Rollout por feature flag	Prueba A/B
Pregunta que responde	"¿Es seguro lanzar esto?"	"¿Es mejor que lo que teníamos?"
Asignación	Progresiva, por atributo o porcentaje	Aleatoria, fija durante toda la prueba
Cambios durante la ejecución	Aumentar o revertir libremente	No tocar la división
Métricas	Operativas: errores, latencia	De producto: conversión, retención, ingresos
Termina cuando	100% y limpieza	Se alcanza el tamaño de muestra acordado
Requiere estadística	No	Sí

La parte que el marketing de los proveedores se salta: la mayoría de los equipos no tiene tráfico para pruebas A/B en la mayoría de las funcionalidades. Detectar un cambio pequeño en una tasa de conversión requiere decenas de miles de usuarios por variante, a veces muchos más, y la muestra crece rápidamente a medida que el efecto se reduce. Un producto B2B con unos pocos miles de usuarios activos mensuales no puede ejecutar una prueba significativa sobre un ajuste del checkout; debería decidir con feedback cualitativo y un rollout por flag.

Si tienes el tráfico, las reglas son fáciles de enunciar y fáciles de romper:

• Fija la métrica principal, el efecto mínimo detectable y el tamaño de muestra antes de empezar; GrowthBook y PostHog incluyen calculadoras.
• No mires a mitad de camino ni pares antes de tiempo. Ejecuta hasta la muestra planificada o usa un método secuencial que la herramienta soporte explícitamente.
• Añade métricas de guardia (tasa de errores, tiempo de carga, tickets de soporte) para detectar una variante "ganadora" que rompe algo.
• Calcula la asignación con un hash de un ID de usuario estable, para que el usuario reciba la misma variante en todas las sesiones y dispositivos.
• Ejecuta un experimento por superficie a la vez, salvo que la herramienta gestione la exclusión mutua.

Si una herramienta ofrece "experimentación" sin orientación sobre el tamaño de muestra ni intervalos de confianza, trátala como una herramienta de rollout con un gráfico adjunto.

Herramientas de feature flags comparadas en 2026

El mercado se ha consolidado en torno a unas pocas plataformas comerciales, unos pocos proyectos open source sólidos y OpenFeature como capa de API neutral.

Herramienta	Modelo de alojamiento	Cobertura de SDK	Segmentación	Experimentación	Modelo de precios	Open source
LaunchDarkly	SaaS (relay proxy para evaluación on-prem)	La más amplia: servidor, cliente, móvil, edge	Segmentos ricos, contextos, cambios programados	Integrada, con motor estadístico	Por asiento más uso; orientado a enterprise	No
Unleash	Self-hosted (Docker/Helm) o nube gestionada	SDKs de servidor y cliente para los lenguajes principales	Estrategias, restricciones, segmentos	Variantes básicas; estadística con herramientas externas	Núcleo OSS gratuito; funciones enterprise y nube de pago	Sí
Flagsmith	Self-hosted o SaaS	Servidor, cliente, móvil, edge	Segmentos, identidades, overrides	Flags multivariantes; analítica mediante integraciones	Nivel gratuito; niveles por petición y por asiento	Sí
GrowthBook	Self-hosted o SaaS	Servidor, cliente, móvil	Segmentación por atributo, grupos guardados	La estadística OSS más sólida: frecuentista y bayesiana, pruebas secuenciales, nativa del data warehouse	OSS gratuito; nube y enterprise de pago	Sí
PostHog	SaaS o self-hosted	Servidor, cliente, móvil	Propiedades de persona, cohortes	Integrada con product analytics; estadística incluida	Por uso, por petición de flag	Sí
OpenFeature	No es un servicio: una especificación y SDKs	Todos los lenguajes principales; providers para las herramientas anteriores	Delegada al provider	Delegada al provider	Gratuito	Sí (CNCF)
Solución propia	Tu base de datos o archivo de configuración	Lo que escribas	Normalmente booleana o porcentaje	Ninguna	Tiempo de ingeniería	N/A

Cómo leerlo:

• LaunchDarkly es la referencia en escala, gobernanza y amplitud de SDKs, y la más cara; el coste escala con asientos y contextos mensuales.
• Unleash es la opción pragmática self-hosted para equipos que quieren las flags dentro de su propia red. La experimentación es limitada por diseño.
• Flagsmith es más ligera, con overrides por identidad que encajan en productos B2B que habilitan funcionalidades por cliente.
• GrowthBook es la elección cuando los experimentos importan más que las flags; lee métricas directamente de tu data warehouse.
• PostHog tiene sentido si además quieres product analytics y session replay de un único proveedor y aceptas facturación por uso.
• OpenFeature no es un competidor. Programa contra su API y cambiar de proveedor más adelante se convierte en un cambio de provider, no en una reescritura.
• Solución propia significa una tabla features y una página de administración. Funciona para una docena de flags sin segmentación; en cuanto alguien pide "el 10% de los usuarios en Alemania", estás reconstruyendo Unleash con menos pruebas.

Higiene de flags: cómo las feature flags se convierten en deuda técnica

Cada flag es una rama que hay que entender, probar y, en algún momento, eliminar. Los equipos sin un proceso de limpieza acaban con cientos, nadie sabe cuáles se pueden borrar con seguridad y el dashboard se convierte en fuente de incidentes. Estas son las prácticas que importan.

Cada flag tiene un responsable y una fecha de caducidad. Registra ambos al crearla, en los metadatos de la herramienta o en un manifiesto en el repositorio. Las flags de release caducan entre dos y cuatro semanas después del rollout completo planificado, las de experimento con el experimento, y las permanentes se marcan como permanentes para que un script de limpieza nunca las toque.

El nombre codifica la intención. release-new-checkout, exp-pricing-page-cta, ops-disable-recommendations, perm-advanced-reporting. Un revisor sabe por el nombre si la flag debería seguir existiendo.

La eliminación forma parte de la funcionalidad. Un PR que añade una flag de release no se fusiona sin un ticket para eliminarla.

Automatiza el recordatorio. LaunchDarkly, Unleash y GrowthBook informan de flags obsoletas; envía ese informe cada semana al equipo responsable. Un script que compara las claves de flag del código con las de la herramienta detecta el caso inverso: flags borradas en el dashboard pero todavía evaluadas en el código.

Mantén el recuento visible. Las flags caducadas van junto al lead time y la tasa de fallo de cambios. Si sube, la limpieza está perdiendo frente al trabajo de funcionalidades.

Elimina en lugar de conservar "por si acaso". Una vez que la ruta nueva ha estado al 100% durante un ciclo de release, la ruta antigua no es un plan de rollback. El control de versiones la tiene.

Pruebas con feature flags

Las flags multiplican las rutas de código, y las rutas sin probar llegan a producción. Tres niveles mantienen esto bajo control.

Las pruebas unitarias usan un provider en memoria. Nunca llames al servicio de flags real desde las pruebas. Con OpenFeature, InMemoryProvider permite que una prueba ejecute el código con new-checkout en true y luego en false. Ambas ramas quedan cubiertas explícitamente.

Las suites de integración y E2E se ejecutan contra los estados que existirán en producción. No todas las combinaciones; eso explota combinatoriamente. Muchos equipos ejecutan el E2E dos veces en CI: con el conjunto de flags por defecto y con todas las flags de release forzadas a activadas, el estado tras la siguiente liberación.

Prueba la configuración, no solo el código. Una regla de segmentación es un dato que puede estar mal. Gestiona las flags como código (Unleash, Flagsmith y LaunchDarkly tienen providers de Terraform) para que los cambios pasen por revisión, y comprueba en el pipeline que el valor por defecto de cada flag es el seguro: el comportamiento antiguo para las flags de release, "habilitado" para un kill switch que protege una dependencia que quieres activa. En un sistema distribuido, una flag mal configurada en un servicio se propaga en cascada.

Seguridad: las flags no son autorización

Una evaluación de flag en el cliente puede ser leída y modificada por el usuario; el payload del SDK es visible en DevTools. Eso está bien cuando la flag oculta una UI beta. Es una vulnerabilidad cuando la flag es lo único que hay entre un usuario y una funcionalidad de pago o los datos de otro tenant.

• Aplica el control en el servidor. El frontend usa la flag para mostrar el botón "Exportar informe"; la API comprueba la misma flag, o mejor el entitlement real, antes de devolver la exportación. Nunca confíes en la evaluación del lado del cliente para la autorización.
• Sin secretos ni datos personales en las reglas de flag. Los nombres de segmento y las claves de flag llegan a los SDKs de cliente.
• Restringe quién puede cambiar qué. Los kill switches y las flags de permisos necesitan un rol específico o un segundo aprobador, y un registro de auditoría consultable.
• Trata los cambios de flag como cambios en producción. Se saltan el CI. Una flag cambiada a las 17:55 de un viernes es un despliegue sin pipeline; la guardia debería verla junto a los despliegues y las alertas.

Los entitlements que dependen de contratos y facturación pertenecen a un modelo de autorización, no a una flag; nuestro post sobre autenticación moderna y zero trust cubre dónde viven esas comprobaciones.

Un ejemplo breve con OpenFeature

OpenFeature te da una única API independientemente del backend. Sustituir LaunchDarkly por Unleash más adelante significa cambiar solo el provider.

import { OpenFeature } from "@openfeature/server-sdk";
import { InMemoryProvider } from "@openfeature/server-sdk";
// En producción: importa un provider del proveedor, p. ej. @openfeature/launchdarkly-server-provider

const provider = new InMemoryProvider({
  "new-checkout": {
    disabled: false,
    variants: { on: true, off: false },
    defaultVariant: "off",
    contextEvaluator: (ctx) => (ctx.plan === "enterprise" ? "on" : "off"),
  },
});

await OpenFeature.setProviderAndWait(provider);
const client = OpenFeature.getClient();

export async function checkout(user: { id: string; plan: string }) {
  const useNewCheckout = await client.getBooleanValue(
    "new-checkout",
    false, // valor por defecto seguro cuando el provider no está disponible
    { targetingKey: user.id, plan: user.plan }
  );

  return useNewCheckout ? newCheckoutFlow(user) : legacyCheckoutFlow(user);
}

Tres detalles importan más que la sintaxis: el valor por defecto (false) es lo que se ejecuta si el provider está caído, así que debe ser la ruta segura; targetingKey es el ID estable que hace que los rollouts sean fijos por usuario; y el contexto lleva solo los atributos que las reglas necesitan.

Checklist de decisión

Elegir una herramienta

• ¿Segmentación más allá de on/off y porcentaje? Si no, un archivo de configuración o una tabla pequeña basta por ahora.
• ¿Pruebas A/B reales con tráfico suficiente para la significancia? Preselecciona GrowthBook, PostHog o LaunchDarkly. Si no, no pagues por experimentación.
• ¿Los datos de las flags deben quedarse en tu red? Unleash o Flagsmith self-hosted; LaunchDarkly con el relay proxy si el presupuesto lo permite.
• ¿Funcionalidades habilitadas por cliente (B2B)? Prioriza los overrides por identidad y una API que las herramientas de soporte puedan llamar.
• Programa contra OpenFeature desde el primer día; es el seguro contra el lock-in más barato que vas a comprar.
• Cuenta los asientos del dashboard. El precio por asiento se encarece cuando producto, soporte y QA necesitan acceso.

Añadir una flag

• ¿Cuál de los cuatro tipos es? Nómbrala en consecuencia.
• ¿Quién es el responsable y cuándo caduca?
• ¿Cuál es el valor por defecto seguro si el servicio de flags no está disponible?
• ¿La ruta de código antigua sigue funcionando tras cualquier cambio de esquema?
• ¿Hay una comprobación en el servidor si la flag controla el acceso y no solo la UI?
• ¿Hay un ticket para eliminarla?

Recomendación

Adopta feature flags primero para el control de releases, con responsable y caducidad desde el primer día; solo eso elimina la mayor parte de la ansiedad del despliegue y habilita el trunk-based development. Programa contra OpenFeature para que el proveedor sea reemplazable. Elige Unleash o Flagsmith si las flags deben quedarse self-hosted, LaunchDarkly si necesitas gobernanza enterprise y puedes pagarla, GrowthBook o PostHog si los experimentos son el objetivo. Ejecuta pruebas A/B solo donde el tráfico las haga significativas, y dilo cuando no sea el caso. Mantén la autorización en el servidor y elimina las flags con la misma deliberación con la que las añades. En Arvucore solemos recomendar empezar con una herramienta open source self-hosted detrás de OpenFeature y subir de nivel solo cuando una capacidad concreta lo justifique.