Feature flags explicados:lanza con un interruptor

Feature flags explicados: un feature flag es un interruptor de encendido/apagado guardado en tu base de datos en lugar de en tu código: la funcionalidad llega a producción a oscuras (desplegada pero invisible) y la lanzas más tarde activando el interruptor para un cliente beta, el 10 % de los usuarios o todo el mundo. Sin redespliegue, sin cambios de código, sin pánico el día del lanzamiento.

Para un fundador en solitario, los flags son la diferencia entre que "lanzar" sea un despliegue aterrador y que "lanzar" sea una decisión que tomas con un café. Aquí tienes cómo funcionan, las cuatro formas en que los usarás de verdad y los errores que hacen que se vuelvan en tu contra.

Feature flags explicados: qué es realmente un feature flag

Sin flags, controlar quién ve una funcionalidad significa editar código. El truco clásico es así: "si el email del usuario termina en el dominio del cliente beta, muestra la nueva funcionalidad". Cada cambio de esa regla es un cambio de código, y cada cambio de código es un despliegue. La configuración vive en cinco sitios distintos, nada tiene registro de auditoría y la persona que puede accionar el interruptor es quien sepa dónde vive el truco.

Un feature flag mueve esa decisión a los datos. El flag es un interruptor con nombre ("new_dashboard: off") guardado en tu sistema de ajustes junto a cosas como la zona horaria y el tema. Tu código hace una sola pregunta: ¿está este flag activado para este usuario? Cambia la respuesta en un panel y el producto cambia de comportamiento al instante, sin desplegar nada. Los flags se sitúan en la misma jerarquía que el resto de tus ajustes: un valor global por defecto, anulable por organización, anulable por usuario.

Despliega a oscuras, lanza con un interruptor

El gran desbloqueo mental es que desplegar y lanzar son dos eventos distintos, y los flags son lo que los separa.

Desplegar significa que tu código llegó al servidor. Lanzar significa que los usuarios pueden verlo. Sin flags, son el mismo momento, y por eso los lanzamientos parecen peligrosos y los fundadores se sientan sobre trabajo terminado durante semanas esperando el día "adecuado". Con flags, despliegas la funcionalidad a medio hacer, a oscuras, diez veces si quieres. Viaja con cada versión, probada en producción, visible solo para ti. Cuando está lista, lanzar es un interruptor, y si desplegar todavía te da miedo, este es el patrón que elimina la mayor parte.

También cambia tu marketing. Cuando lanzar no cuesta nada, dejas de apostarlo todo a un único gran día y empiezas a publicar un flujo de pequeñas versiones controladas por flags: el motor de los micro-lanzamientos.

Las cuatro formas en que los fundadores usan realmente los flags

Fíjate en que son herramientas de producto y de marketing tanto como de ingeniería. El acceso beta es una conversación de ventas ("¿quieres acceso anticipado?"). El despliegue gradual es gestión de riesgos. Las pruebas A/B son optimización de la página de precios. El interruptor de emergencia es un seguro para dormir.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

El argumento de las 2:47 de la madrugada a favor de los flags

Una historia real de mi propio sistema en producción: 2:47 de la madrugada, mi móvil vibra con una alerta de tasa de errores. Un endpoint falla, usuarios afectados. Dos opciones: depurar medio dormido o volver a la versión anterior en dos clics. Volví atrás. Arreglado en 90 segundos, de vuelta a dormir, y lo depuré bien por la mañana.

Un rollback es un instrumento tosco: revierte todo lo de esa versión, la funcionalidad rota y las tres buenas que salieron con ella. Un feature flag es quirúrgico. Si lo roto está tras un flag, apagas solo esa funcionalidad y dejas el resto de la versión funcionando. En el mejor caso, nunca llegas a enfrentarte a la decisión de las 2:47: el despliegue gradual hizo que solo el 10 % de los usuarios viera el fallo, el flag se apagó y la mayoría de tus clientes ni se enteró de que pasó algo.

Los errores que hacen que los flags se vuelvan en tu contra

• Sin valor por defecto. Añades un flag nuevo pero nunca defines qué significa para los usuarios existentes: reciben una respuesta indefinida y la app se porta mal de formas que no puedes reproducir. Todo flag se lanza con un valor por defecto explícito.
• Sin registro de auditoría. El producto de pronto se comporta distinto y nadie sabe quién cambió qué ni cuándo. Cada cambio de flag debería registrar quién, qué, valor anterior, valor nuevo y marca de tiempo: los flags sin historial son una pesadilla de depuración.
• Cualquiera puede cambiar cualquier cosa. Los flags son controles de producción. Cambiar un flag a nivel de organización debería exigir permisos de administrador, igual que cambiar la facturación de la organización.
• Comprobar el flag con una consulta a la base de datos en cada petición. Las comprobaciones de flags ocurren constantemente; deben salir de una caché que se refresca cuando el flag cambia, no de una consulta nueva cada vez que se carga una página.

¿Necesitas flags desde el primer día?

Antes de lo que crees. No necesitas un producto de flags sofisticado: una tabla de flags en tu propia base de datos, gestionada desde una pantalla de administración sencilla, es el patrón que sostiene esto a cualquier escala. Forma parte de tu sistema de ajustes, que la IA construye rápido a partir de una buena especificación; la maquinaria de los flags son unas pocas horas de trabajo, no un proyecto.

La recompensa empieza con tu primera funcionalidad que da miedo. La primera vez que publiques algo a oscuras un martes, lo pruebes en producción toda la semana y lo "lances" el lunes accionando un interruptor, te preguntarás cómo puede alguien construir en solitario sin esto.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

Preguntas frecuentes

¿Cuál es la diferencia entre un feature flag y un ajuste?

Un ajuste guarda una preferencia: zona horaria, tema, moneda. Un feature flag guarda una decisión sobre disponibilidad: ¿está activada esta funcionalidad y para quién? Viven en el mismo sistema jerárquico (valor global por defecto → anulación por organización → anulación por usuario), por eso la maquinaria de flags suele construirse como parte de tu sistema de ajustes.

¿Cuál es la diferencia entre un feature flag y un rollback?

Un rollback revierte todo tu despliegue a la versión anterior: es eficaz, pero se lleva por delante los cambios buenos junto con los malos. Un flag apaga una funcionalidad concreta y deja todo lo demás funcionando. Quieres ambos: el rollback como freno de emergencia, los flags como control de precisión al que recurres primero.

¿Ralentizan los feature flags la aplicación?

No si están en caché. La comprobación del flag se ejecuta constantemente, así que la respuesta debe salir de una caché que se refresca cuando un flag cambia, nunca de una consulta nueva a la base de datos en cada carga de página. Bien hecho, el coste es prácticamente cero.

¿Puede un fundador no técnico gestionar los feature flags?

Ese es precisamente el objetivo. Los flags sacan las decisiones de lanzamiento del código y las llevan a un panel: tú decides quién ve qué y cuándo, sin tocar un despliegue. Diriges el despliegue (10 % hoy, todos el lunes) igual que programarías una newsletter.