# ¿Qué es un feature flag? Guía sencilla para devs solitarios URL: https://whatshouldibuildnext.com/es/journal/que-es-un-feature-flag Type: blog Locale: es Published: 2026-10-31 Updated: 2026-11-01 --- > Un feature flag es un if que puedes cambiar sin desplegar. Te explicamos los cuatro tipos, lo que cuestan y cuándo un dev en solitario debería saltárselos. ¿Qué es un feature flag? Un `if` cuya respuesta vive fuera de tu código. Despliegas la nueva ruta de código apagada y la activas más tarde cambiando un valor en un archivo de configuración, una fila de la base de datos o un servicio de flags, sin volver a desplegar. Ese truco separa desplegar código de lanzar una funcionalidad, y por eso un flag es el rollback más barato que vas a tener. Aprendí la segunda mitad de esa frase por las malas. Mi primer flag era un booleano en una variable de entorno que activé un viernes por la noche, y me olvidé de que existía durante once meses. No se rompió nada. Y justo ese es el problema, al que vamos a llegar. ## ¿Cómo se ve un feature flag en el código? Mucho más pequeño de lo que sugieren las páginas de inicio de los proveedores. Quitando los paneles, un flag es una búsqueda y una bifurcación: `const flags = { newCheckout: false }; if (flags.newCheckout) { return renderNewCheckout(user); } return renderOldCheckout(user);`Todo lo demás es una pregunta: de dónde sale `flags` y quién puede cambiarlo. Una constante en el archivo es un flag que cambias desplegando, lo que anula el sentido. Una variable de entorno cambia al reiniciar. Una fila en tu base de datos cambia en segundos. Un servicio alojado también cambia en segundos, y además te da segmentación por usuario, una interfaz y un registro de auditoría. Lo que de verdad incomoda en la práctica: el código es trivial, el ciclo de vida no. Dos ramas en producción significan dos comportamientos que probar, dos caminos que depurar a las 2 de la madrugada, y uno de ellos destinado a pudrirse. ![Interruptor industrial de metal con un mando rojo sobre un panel de control de acero, un interruptor de emergencia](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/9ca39f-i1.webp) ## ¿Qué tipos de feature flag existen y cuál necesitas primero? La taxonomía de [Martin Fowler sobre los feature toggles](https://martinfowler.com/articles/feature-toggles.html) sigue siendo la forma más limpia de ordenarlos, y el eje útil es cuánto debe vivir cada tipo. **Los flags de release** ocultan trabajo sin terminar o arriesgado. Son transitorios: una o dos semanas y luego se borran. Es el que necesitas primero. **Los flags de ops** son interruptores de emergencia. Envuelves una funcionalidad pesada o frágil (un widget de recomendaciones, una llamada a un tercero) para apagarla bajo carga sin desplegar. La mayoría son de corta vida; algunos se quedan para siempre, y está bien. **Los flags de experimento** reparten a los usuarios en cohortes para pruebas A/B. Viven lo que tarde en llegar a un resultado estadísticamente significativo, de horas a semanas, y necesitan tráfico real para significar algo. **Los flags de permisos** limitan funcionalidades por plan o cuenta: el plan Pro, el grupo beta. Pueden vivir años, y en ese punto ya no son flags. Son derechos, y merecen un modelo de datos propio. Si eres un dev en solitario con 40 usuarios, necesitas flags de release y quizá un interruptor de emergencia. Los flags de experimento con 40 usuarios producen ruido, no datos. Espera a poder nombrar la métrica y el tamaño de muestra. ## ¿Qué problema resuelven los flags que las ramas y los despliegues no resuelven? Tres cosas, y solo tres merecen tu atención. **Enviar trabajo sin terminar sin riesgo.** Las ramas largas duelen porque fusionarlas es una pequeña guerra. Un flag te permite fusionar a main cada día con el código nuevo apagado. Es el motor del desarrollo basado en tronco (trunk-based development), donde todos confirman en una sola rama y los flags cargan con las partes sin terminar. **Despliegue gradual.** Actívalo para ti, luego para el 1% de los usuarios, luego para el 10%, luego para todos. Fowler describe elegir una cohorte canario de alrededor del 1% tomando el ID de usuario módulo 100. Si algo falla, el radio de impacto son unas pocas personas en lugar de toda tu base. **Deshacer rápido.** Revertir un despliegue implica una compilación, un pipeline y algo de nervio. Cambiar un flag es una sola edición. En un mal día, la diferencia son minutos de dolor frente a una hora. Nada de esto necesita un proveedor el primer día. Todo necesita disciplina. ## ¿Necesitas LaunchDarkly o basta con un archivo JSON? Un archivo JSON o una tabla de base de datos sirve hasta que se cumple alguna de estas condiciones: alguien que no es desarrollador necesita cambiar flags, necesitas despliegues por porcentaje o segmentación por usuario, necesitas un registro de quién cambió qué, o tienes más de un servicio leyendo los mismos flags. Esta es la escalera aproximada que subiría, en orden: - **Constantes y variables de entorno.** Coste cero. Válido para el primer flag de release de un proyecto personal. - **Una tabla `flags` o un archivo JSON que lees en tiempo de ejecución.** Diez líneas de código, cambios instantáneos, sin proveedor. Esto lleva un proyecto personal bastante lejos. - **Un servicio de flags de código abierto o alojado.** Cuando quieres reglas de segmentación, despliegues graduales y una interfaz que otra persona pueda usar. - **Una plataforma empresarial.** Cuando entran en juego el cumplimiento normativo, las aprobaciones y decenas de ingenieros. Los servicios alojados cubren los pasos 3 y 4. LaunchDarkly es el referente, con las funciones de segmentación y gobernanza más profundas y un precio que lo refleja. Statsig combina flags con experimentación y analítica de producto, lo que tiene sentido si piensas medir lo que hizo el flag y no solo encenderlo o apagarlo. Descarta ambos si tu equipo eres tú. Una tabla de tres columnas gana a un panel que abres dos veces al trimestre. Elige un servicio solo cuando la versión manual te haya costado algo concreto, como una edición nocturna en la configuración de producción de la que te arrepentiste. Un seguro que conviene conocer: [OpenFeature](https://openfeature.dev/docs/reference/intro) es un proyecto incubado en la CNCF que define una API neutral de proveedor para evaluar flags, con SDK para Node.js, Python, Go, Java, .NET y clientes web, entre otros. Programas contra la interfaz estándar y cambias el proveedor por debajo. Si sospechas que se te quedará pequeña tu primera configuración, pasar por OpenFeature convierte esa migración en un cambio de configuración. ![Cuaderno con casillas dibujadas a mano y flechas sobre un escritorio de desarrollo de noche](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/f90753-i2.webp) ## ¿Cómo añadir tu primer flag sin liarla? Empieza con un solo flag de release y unas pocas reglas básicas. Esta es la versión que me habría gustado seguir. **Ponle nombre según la funcionalidad, no según el mecanismo.** `new-checkout-flow` te dice qué se rompe si falla. `flag_47` no te dice nada dentro de seis meses. **Por defecto, apagado, y apagado debe significar el comportamiento antiguo.** La convención de que «apagado equivale a legacy, encendido equivale a nuevo» es lo que te permite razonar sobre el sistema bajo presión. Si la rompes, cada flag se convierte en un rompecabezas. **Evalúalo en un solo sitio.** Fowler llama a la solución inversión del toggle: en lugar de esparcir `if (flags.x)` por veinte archivos, decide una vez, cerca del borde del sistema, y pasa el resultado hacia dentro. Un único punto de decisión significa un solo lugar donde cambiar y un solo lugar donde probar. **Escribe el ticket de eliminación en el momento en que creas el flag.** Ponlo en el backlog con una fecha. Fowler también sugiere fechas de caducidad para los toggles de corta vida, e incluso tests que fallen cuando un flag supera su fecha. Un flag sin ticket de eliminación es un préstamo sin calendario de pago. **Registra cada evaluación que importe.** Cuando un usuario reporta un error, quieres saber en qué lado del flag estaba. Si no puedes responderlo, el flag es un pasivo. Aquí es donde la gente sobreingeniera. No necesitas probar cada combinación de flags, porque la mayoría no interactúan entre sí. Prueba la configuración que esperas en producción, prueba el fallback con el flag apagado y, opcionalmente, haz una pasada con todo encendido para detectar desviaciones. ## ¿Cuál es el coste real de los feature flags del que nadie habla? Cada flag duplica un camino de código. Diez flags independientes son, en teoría, mil veinticuatro combinaciones. Ya sé que nunca las probarás todas, pero aún puedes toparte en producción con una que nadie previó. El coste más doloroso son los flags muertos. El despliegue termina, todos están en el comportamiento nuevo, el flag se queda al 100% y la rama antigua sigue en el repo como código que nadie se atreve a borrar. Seis meses después, nadie recuerda si apagarlo es seguro. La versión famosa de esto es Knight Capital, en agosto de 2012. Un flag antiguo, que en su día había activado una función de trading ya retirada, se reutilizó para código nuevo. Uno de los ocho servidores se perdió el despliegue y siguió ejecutando el código viejo. En 45 minutos la firma perdió unos $440 millones según su informe trimestral, una cifra que informes posteriores sitúan más cerca de $460 millones. Es una empresa de trading con dinero real e ingenieros de verdad, así que no voy a afirmar que tu proyecto personal esté más a salvo. La lección se reduce bien: nunca reutilices el nombre de un flag, y borra los flags muertos antes de que se conviertan en arqueología. ![Hileras de llaves de latón colgadas de ganchos, unas oxidadas y otras brillantes, como flags viejos olvidados en el código](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/967554-i3.webp) La idea de Fowler es la que sigo: trata los flags como inventario con un coste de mantenimiento. Algunos equipos limitan el número de flags vivos y exigen eliminar uno antes de añadir otro. Para un dev en solitario, un techo fijo de cinco basta. ## ¿Cuándo conviene no usar feature flags? Con más frecuencia de la que admiten los proveedores. No los uses cuando la funcionalidad es pequeña, el cambio se revierte fácilmente en git y tu despliegue tarda dos minutos. Un flag añade una rama, una fuente de configuración y algo que olvidar. Si revertir es más rápido que alternar un flag, el flag es puro teatro. Tampoco cuando aún no tienes usuarios. Un despliegue gradual a cero personas es solo un retraso. Lanza, mira los logs, corrige. Tampoco para migraciones de base de datos que un interruptor no puede deshacer. Un flag puede ocultar una columna nueva en la interfaz, pero no puede devolverte una tabla eliminada. Los cambios de esquema necesitan su propio plan de expandir y contraer, con flags o sin ellos. Sí merecen la pena cuando el cambio toca pagos o autenticación, cuando quieres fusionar a diario trabajo sin terminar, o cuando una dependencia externa podría fallar y quieres un interruptor de emergencia. ## ¿Qué hay que vigilar una vez que el flag está activo? Un flag controla la exposición, y la exposición solo sirve si puedes ver qué pasa después. Activar una funcionalidad para el 10% de los usuarios sin vigilar errores ni latencia es tirar una moneda con pasos extra. Antes del primer despliegue gradual, asegúrate de poder responder tres preguntas en menos de un minuto: ¿han subido los errores en la cohorte afectada?, ¿ha empeorado la latencia?, ¿ha cambiado algo aguas abajo? La monitorización de disponibilidad y la búsqueda en logs cubren la mayoría de esto en un producto pequeño. Una herramienta como Better Stack reúne monitores, páginas de estado y logs en un solo sitio, con un plan gratuito. Esta es la regla que sigo ahora: un flag vale lo que la alarma que tiene asociada. Sin alarma, estás encendiendo cosas a oscuras. Y esto es lo que haría esta semana: elige una tarea sin terminar que te dé miedo fusionar. Ponla detrás de un booleano leído desde una tabla o un JSON, por defecto apagado, y fusiónala a main hoy. Escribe el ticket de eliminación antes de cerrar el editor, con una fecha a dos semanas vista. Luego actívala solo para ti y úsala durante un día. Si aguanta, amplíala. Si no, apágala y no habrás perdido más que un minuto. ¿Qué flag de tu código lleva al 100% más de un mes? Ese es tu primer borrado. ## FAQ ### ¿Qué es un feature flag en términos sencillos? Es una condición en tu código cuyo valor de activado o desactivado se guarda fuera del código, en un archivo de configuración, una base de datos o un servicio de flags. Puedes cambiarlo en tiempo de ejecución, así que una funcionalidad puede desplegarse oculta y lanzarse más tarde sin otro despliegue. ### ¿Son lo mismo feature flag y feature toggle? Sí. Feature flag, feature toggle, feature switch y release toggle describen la misma técnica. Cada equipo elige un término por costumbre, y las herramientas los usan indistintamente. ### ¿Cuáles son los tipos principales de feature flags? Se usan cuatro tipos habitualmente: flags de release para ocultar trabajo sin terminar, flags de ops (interruptores de emergencia) para apagar funcionalidades arriesgadas, flags de experimento para pruebas A/B y flags de permisos para limitar funcionalidades por plan o cuenta. ### ¿Necesito una herramienta de pago para feature flags en un proyecto personal? Normalmente no. Una constante, una variable de entorno, un archivo JSON o una tabla de base de datos cubren un proyecto en solitario. Pasa a un servicio alojado cuando alguien que no es desarrollador necesite cambiar flags, o cuando necesites despliegues por porcentaje, segmentación y un registro de auditoría. ### ¿Cuánto tiempo debe vivir un feature flag? Los flags de release deberían vivir una o dos semanas, y después borrarse junto con la ruta de código antigua. Los interruptores de emergencia pueden durar más. Los flags de permisos pueden durar años, pero en realidad son derechos y merecen un modelo de datos propio. ### ¿Cuál es el mayor riesgo de usar feature flags? Los flags obsoletos. Cada flag añade una ruta de código que hay que probar, y un flag dejado al 100% deja código muerto que nadie se atreve a borrar. La pérdida de Knight Capital en 2012, de unos $440 millones, implicó un flag antiguo reutilizado. Escribe el ticket de eliminación en el momento de crear el flag.