En el desenvolupament de programari modern, la capacitat de separar el desplegament tècnic de l'alliberament de funcionalitats s'ha convertit en una necessitat estratègica. Els equips volen fusionar codi a mig acabar sense trencar l'experiència d'usuari, activar canvis arriscats amb un interruptor d'emergència o donar accés a una nova funció només a un client beta. La primera temptació sol ser recórrer a plataformes com LaunchDarkly, Flagsmith o Split. Però per a un equip petit o un SaaS en etapa primerenca, construir els teus propis feature flags amb unes cent línies de codi no és una concessió, sinó una decisió de propietat tecnològica que molts fundadors han d'avaluar. Q2BSTUDIO, com a empresa especialitzada en desenvolupament d'aplicacions a mida, entén que cada peça d'infraestructura mereix una anàlisi acurada de construir versus comprar. En aquest article explorem per què un sistema casolà de flags és suficient per a la majoria dels casos inicials, quan val la pena externalitzar-lo i com implementar-lo sense dependre de serveis externs.
Què aporten realment els feature flags? Si traiem el soroll de màrqueting, un flag és simplement un interruptor en temps d'execució que decideix si un bloc de codi s'executa o no, sense necessitat de redeploy. Això habilita diversos fluxos de treball: desacoblar el desplegament de l'alliberament (puges codi fosc el dimarts, l'actives el dijous), interruptors d'emergència per a canvis arriscats (una nova passarel·la de pagament embolicada en un flag es desactiva amb una consulta SQL en lloc d'un rollback complet), desplegaments graduals per percentatge (5%, 20%, 50%, 100% amb mostres estables), segmentació per usuari o tenant (actives una funció només per a un beta tester) i desenvolupament basat en trunk (fusiones codi incomplet a main perquè està apagat per defecte). Res d'això requereix inherentment un proveïdor extern.
No obstant això, és habitual que els equips joves contractin un SaaS de flags des del primer dia. Els motius en contra són concrets. Primer, el cost escala amb allò que no hauria: els plans es fixen per usuaris actius mensuals (MAU), justament allò que un producte en creixement vol augmentar. Pagues més a mesura que tens èxit, per una funcionalitat que podries expressar en una taula de base de dades. Segon, introdueixes una dependència de xarxa en la ruta crítica: cada avaluació de flag pot requerir una crida remota o un SDK que s'ha d'inicialitzar, actualitzar i sincronitzar. Si el proveïdor té un mal dia, necessites lògica de fallback, i acabes escrivint el mateix codi que hauries escrit des del principi. Tercer, la residència de dades i privacitat: per segmentar per usuari, el servei necessita conèixer identificadors, atributs, de vegades més. Per a un producte amb usuaris europeus, això significa un altre processador en el diagrama de flux, un altre DPA per signar, una altra superfície per auditar. Mantenir l'avaluació dins del teu propi Postgres evita tot això. Finalment, i més important, la majoria de les funcions premium —registres d'auditoria, fluxos d'aprovació, experiments multivariants, segmentació per dotze atributs, una interfície gràfica polida— són excessives per a un equip de tres persones el 'UI de flags' del qual pot ser un simple UPDATE feature_flags SET enabled = true WHERE key = 'nou_checkout';. Comprar abans de necessitar és com pagar per una suite ofimàtica quan només necessites una llibreta.
La solució minimalista que proposem consta de quatre elements: una taula a Postgres, una funció de hash determinista, un avaluador de regles i una memòria cau en memòria. La taula feature_flags té columnes com key (text, primary key), enabled (booleà, interruptor mestre), rollout_percentage (enter entre 0 i 100), enabled_tenants i disabled_tenants (arrays de text per a llistes blanques/negres). L'interruptor mestre és el teu kill switch: si és false, la funció està apagada per a tothom, sense excepció. Les llistes de tenants permeten forçar l'activació o desactivació per a clients específics, ignorant el percentatge. El percentatge s'aplica de forma determinista: no amb Math.random() —que faria que un mateix usuari vegi la funció encesa en una petició i apagada en la següent— sinó amb una funció hash basada en FNV-1a que combina el nom del flag i l'identificador de l'usuari. Així, el mateix usuari, per al mateix flag, sempre obté el mateix resultat, fins que canviïs el percentatge. A més, salem el hash amb la clau del flag perquè un usuari no estigui sempre al mateix percentil en tots els flags: el cohort desafortunat del primer rollout no serà el mateix per al segon. L'avaluador aplica les regles en ordre: primer l'interruptor mestre; després les llistes d'exclusió (si l'usuari està a disabled_tenants, s'apaga); després les llistes d'inclusió (si està a enabled_tenants, s'encén); i finalment el percentatge determinista. Si no hi ha identificador (usuari anònim), només s'activa si el percentatge és 100. Un flag desconegut retorna false, mai llança una excepció: un error tipogràfic no ha de tombar una petició.
El rendiment és clau: no podem consultar Postgres a cada avaluació. Per això carreguem tots els flags en un mapa en memòria en iniciar i el refresquem cada 30 segons mitjançant un setInterval. L'actualització és atòmica: construïm el nou mapa i després reemplaçem la referència, de manera que un lector mai veu un mapa a mig construir. Si falla la consulta, mantenim l'última instantània vàlida. La conseqüència és que un canvi a la base de dades triga fins a 30 segons a propagar-se a totes les instàncies. Per a un equip petit, això continua sent molt més ràpid que un desplegament de rollback. Si necessites propagació subsegon, llavors podries considerar un sistema més complex o comprar el SaaS, però per a la majoria dels casos, 30 segons és perfectament acceptable. Aquest disseny encaixa perfectament en una arquitectura de SaaS multiinquilí, on l'identificador de tenant ja s'utilitza a tota l'aplicació. Q2BSTUDIO integra solucions de cloud a AWS i Azure que permeten desplegar aquesta lògica amb alta disponibilitat i escalat automàtic.
Quan hauries de comprar LaunchDarkly? Quan les necessitats superen allò que cent línies poden oferir. Per exemple: quan persones no tècniques (product managers, màrqueting) necessiten canviar flags sense escriure SQL; quan necessites un registre d'auditoria ric amb aprovacions (indústries regulades); quan la segmentació es torna complexa (pla, país, data de registre, etc.); quan necessites propagació en temps real (menys d'un segon); o quan comences a executar experiments A/B amb significança estadística. En aquests casos, el SaaS val cada euro. Però per a una startup que encara busca product-market fit, construir és la decisió intel·ligent. Recorda que els feature flags són només una peça de l'ecosistema tecnològic: també necessites IA per a personalització, ciberseguretat per protegir les dades, BI i Power BI per analitzar el comportament dels flags, i agents IA per automatitzar respostes. Q2BSTUDIO ofereix serveis en totes aquestes àrees, des de intel·ligència artificial fins a ciberseguretat i pentesting, ajudant els equips a construir sistemes robustos sense sobrecàrrega innecessària.
En resum: els feature flags són una eina poderosa que no requereix una subscripció mensual per a equips petits. Amb unes cent línies de codi, una taula a Postgres, un hash determinista i una memòria cau en memòria, obtens kill switches, desplegaments graduals i segmentació per tenant. Quan la teva organització creixi i necessiti funcions avançades, sempre pots migrar a un servei especialitzat. Però no paguis per avançat per problemes que encara no tens. La decisió de construir o comprar és estratègica, i a Q2BSTUDIO ajudem les empreses a prendre el camí correcte, oferint tant aplicacions a mida com integracions amb plataformes cloud, IA i ciberseguretat. El coneixement és a les teves mans —i a la teva base de dades.
