En el desarrollo de software moderno, la capacidad de separar el despliegue técnico de la liberación de funcionalidades se ha convertido en una necesidad estratégica. Los equipos quieren fusionar código a medio terminar sin romper la experiencia del usuario, activar cambios arriesgados con un interruptor de emergencia o dar acceso a una nueva función solo a un cliente beta. La primera tentación suele ser recurrir a plataformas como LaunchDarkly, Flagsmith o Split. Pero para un equipo pequeño o un SaaS en etapa temprana, construir tus propios feature flags con unas cien líneas de código no es una concesión, sino una decisión de propiedad tecnológica que muchos fundadores deben evaluar. Q2BSTUDIO, como empresa especializada en desarrollo de aplicaciones a medida, entiende que cada pieza de infraestructura merece un análisis cuidadoso de construir versus comprar. En este artículo exploramos por qué un sistema casero de flags es suficiente para la mayoría de los casos iniciales, cuándo merece la pena externalizarlo y cómo implementarlo sin depender de servicios externos.
¿Qué aportan realmente los feature flags? Si quitamos el ruido de marketing, un flag es simplemente un interruptor en tiempo de ejecución que decide si un bloque de código se ejecuta o no, sin necesidad de redeploy. Esto habilita varios flujos de trabajo: desacoplar el despliegue de la liberación (subes código oscuro el martes, lo activas el jueves), interruptores de emergencia para cambios arriesgados (una nueva pasarela de pago envuelta en un flag se desactiva con una consulta SQL en lugar de un rollback completo), despliegues graduales por porcentaje (5%, 20%, 50%, 100% con muestras estables), segmentación por usuario o tenant (activas una función solo para un beta tester) y desarrollo basado en trunk (fusionas código incompleto a main porque está apagado por defecto). Nada de esto requiere inherentemente un proveedor externo.
Sin embargo, es habitual que los equipos jóvenes contraten un SaaS de flags desde el día uno. Los motivos en contra son concretos. Primero, el coste escala con lo que no debería: los planes se fijan por usuarios activos mensuales (MAU), justo lo que un producto en crecimiento quiere aumentar. Pagas más a medida que tienes éxito, por una funcionalidad que podrías expresar en una tabla de base de datos. Segundo, introduces una dependencia de red en la ruta crítica: cada evaluación de flag puede requerir una llamada remota o un SDK que debe inicializarse, actualizarse y sincronizarse. Si el proveedor tiene un mal día, necesitas lógica de fallback, y terminas escribiendo el mismo código que habrías escrito desde el principio. Tercero, la residencia de datos y privacidad: para segmentar por usuario, el servicio necesita conocer identificadores, atributos, a veces más. Para un producto con usuarios europeos, eso significa otro procesador en el diagrama de flujo, otro DPA que firmar, otra superficie que auditar. Mantener la evaluación dentro de tu propio Postgres evita todo eso. Por último, y más importante, la mayoría de las funciones premium —registros de auditoría, flujos de aprobación, experimentos multivariante, segmentación por doce atributos, una interfaz gráfica pulida— son excesivas para un equipo de tres personas cuyo 'UI de flags' puede ser un simple UPDATE feature_flags SET enabled = true WHERE key = 'nuevo_checkout';. Comprar antes de necesitar es como pagar por una suite ofimática cuando solo necesitas una libreta.
La solución minimalista que proponemos consta de cuatro elementos: una tabla en Postgres, una función de hash determinista, un evaluador de reglas y una caché en memoria. La tabla feature_flags tiene columnas como key (text, primary key), enabled (booleano, interruptor maestro), rollout_percentage (entero entre 0 y 100), enabled_tenants y disabled_tenants (arrays de texto para listas blancas/negras). El interruptor maestro es tu kill switch: si está a false, la función está apagada para todos, sin excepción. Las listas de tenants permiten forzar la activación o desactivación para clientes específicos, ignorando el porcentaje. El porcentaje se aplica de forma determinista: no con Math.random() —que haría que un mismo usuario vea la función encendida en una petición y apagada en la siguiente— sino con una función hash basada en FNV-1a que combina el nombre del flag y el identificador del usuario. Así, el mismo usuario, para el mismo flag, siempre obtiene el mismo resultado, hasta que cambies el porcentaje. Además, salamos el hash con la clave del flag para que un usuario no esté siempre en el mismo percentil en todos los flags: el cohorte desafortunado del primer rollout no será el mismo en el segundo. El evaluador aplica las reglas en orden: primero el interruptor maestro; luego las listas de exclusión (si el usuario está en disabled_tenants, se apaga); luego las listas de inclusión (si está en enabled_tenants, se enciende); y finalmente el porcentaje determinista. Si no hay identificador (usuario anónimo), solo se activa si el porcentaje es 100. Un flag desconocido devuelve false, nunca lanza excepción: un error tipográfico no debe tumbar una petición.
El rendimiento es clave: no podemos consultar Postgres en cada evaluación. Por eso cargamos todos los flags en un mapa en memoria al arrancar y lo refrescamos cada 30 segundos mediante un setInterval. La actualización es atómica: construimos el nuevo mapa y luego reemplazamos la referencia, de modo que un lector nunca ve un mapa a medio construir. Si falla la consulta, mantenemos la última instantánea válida. La consecuencia es que un cambio en la base de datos tarda hasta 30 segundos en propagarse a todas las instancias. Para un equipo pequeño, eso sigue siendo mucho más rápido que un despliegue de rollback. Si necesitas propagación subsegundo, entonces podrías considerar un sistema más complejo o comprar el SaaS, pero para la mayoría de los casos, 30 segundos es perfectamente aceptable. Este diseño encaja perfectamente en una arquitectura de SaaS multiinquilino, donde el identificador de tenant ya se usa en toda la aplicación. Q2BSTUDIO integra soluciones de cloud en AWS y Azure que permiten desplegar esta lógica con alta disponibilidad y escalado automático.
¿Cuándo deberías comprar LaunchDarkly? Cuando las necesidades superan lo que cien líneas pueden ofrecer. Por ejemplo: cuando personas no técnicas (product managers, marketing) necesitan cambiar flags sin escribir SQL; cuando necesitas un registro de auditoría rico con aprobaciones (industrias reguladas); cuando la segmentación se vuelve compleja (plan, país, fecha de registro, etc.); cuando necesitas propagación en tiempo real (menos de un segundo); o cuando empiezas a ejecutar experimentos A/B con significancia estadística. En esos casos, el SaaS vale cada euro. Pero para una startup que aún está buscando product-market fit, construir es la decisión inteligente. Recuerda que los feature flags son solo una pieza del ecosistema tecnológico: también necesitas IA para personalización, ciberseguridad para proteger los datos, BI y Power BI para analizar el comportamiento de los flags, y agentes IA para automatizar respuestas. Q2BSTUDIO ofrece servicios en todas estas áreas, desde inteligencia artificial hasta ciberseguridad y pentesting, ayudando a los equipos a construir sistemas robustos sin sobrecarga innecesaria.
En resumen: los feature flags son una herramienta poderosa que no requiere una suscripción mensual para equipos pequeños. Con alrededor de cien líneas de código, una tabla en Postgres, un hash determinista y una caché en memoria, obtienes kill switches, despliegues graduales y segmentación por tenant. Cuando tu organización crezca y necesites funciones avanzadas, siempre puedes migrar a un servicio especializado. Pero no pagues por adelantado por problemas que aún no tienes. La decisión de construir o comprar es estratégica, y en Q2BSTUDIO ayudamos a las empresas a tomar el camino correcto, ofreciendo tanto aplicaciones a medida como integraciones con plataformas cloud, IA y ciberseguridad. El conocimiento está en tus manos —y en tu base de datos.
