Leer hoe je een webapp ontwerpt en bouwt voor feature flags: flags aanmaken, gebruikers targeten, geleidelijke rollouts uitvoeren, een kill switch toevoegen en wijzigingen veilig bijhouden.
Een feature flag (ook wel "feature toggle") is een eenvoudige controle waarmee je een productfunctionaliteit aan of uit kunt zetten zonder nieuwe code te deployen. In plaats van een release te koppelen aan een deploy, scheid je "code is gedeployed" van "code is actief." Die kleine verschuiving verandert hoe veilig — en hoe snel — je kunt uitrollen.
Teams gebruiken feature flags omdat ze risico verminderen en flexibiliteit vergroten:
De operationele waarde is eenvoudig: feature flags geven je een snelle, gecontroleerde manier om te reageren op gedrag in de echte wereld — fouten, performance regressies of negatieve gebruikersfeedback — zonder te wachten op een volledige redeploy-cyclus.
Deze gids leidt je door het bouwen van een praktische feature flag- en rolloutbeheer-webapp met drie kernonderdelen:
Het doel is geen gigantisch enterprise-platform; het is een helder, onderhoudbaar systeem dat je aan een productteam kunt geven en in productie kunt vertrouwen.
Als je snel wilt prototypen, kan een vibe-coding workflow helpen. Teams gebruiken bijvoorbeeld vaak Koder.ai om een eerste werkende versie van het React-dashboard en Go/PostgreSQL API te genereren vanuit een gespecificeerd chat-gesprek, en daarna itereren ze op de regelsengine, RBAC en auditvereisten in planningsmodus voordat ze de broncode exporteren.
Voordat je schermen ontwerpt of code schrijft, wees duidelijk over voor wie het systeem is en wat “succes” betekent. Feature flag-tools falen vaak niet omdat de regelsengine fout is, maar omdat de workflow niet aansluit op hoe teams software uitrollen en ondersteunen.
Engineers willen snelle, voorspelbare controls: maak een flag aan, voeg targetingregels toe en ship zonder redeploy. Productmanagers willen zekerheid dat releases gefaseerd en gepland kunnen worden, met zichtbaarheid wie erdoor wordt beïnvloed. Support en operations hebben een veilige manier nodig om op incidenten te reageren — bij voorkeur zonder engineering te pagineren — door een risicovolle feature snel uit te zetten.
Een goed requirementsdocument benoemt deze persona’s en de acties die ze moeten kunnen uitvoeren (en niet mogen uitvoeren).
Focus op een compacte kern die geleidelijke rollout en rollback mogelijk maakt:
Dit zijn geen "leuke extra's" — het zijn essentiële functies die van een rollout-tool iets bruikbaars maken.
Noteer deze nu, maar bouw ze niet als eerste:
Schrijf veiligheidsvereisten expliciet op als regels. Veelvoorkomende voorbeelden: goedkeuringen voor productie-wijzigingen, volledige auditbaarheid (wie wijzigde wat, wanneer en waarom) en een snelle rollback-route die zelfs tijdens een incident beschikbaar is. Deze “definitie van veilig” stuurt later beslissingen over machtigingen, UI-frictie en wijzigingsgeschiedenis.
Een feature flag-systeem is het meest overzichtelijk als je "flags beheren" scheidt van "evaluaties serveren." Zo blijft de admin-ervaring prettig en veilig, terwijl je applicaties snelle, betrouwbare antwoorden krijgen.
Op hoofdlijnen wil je vier bouwstenen:
Een eenvoudig mentaal model: het dashboard update flagdefinities; applicaties consumeren een gecompileerde snapshot van die definities voor snelle evaluatie.
Je hebt doorgaans twee patronen:
Server-side evaluatie (aanbevolen voor de meeste flags). Je backend vraagt de SDK/evaluatielaag met een user/context-object en beslist vervolgens wat te doen. Dit houdt regels en gevoelige attributen buiten de client en maakt consistente gedragingen makkelijker.
Client-side evaluatie (selectief gebruiken). Een web-/mobile-client haalt een vooraf gefilterde, ondertekende configuratie op (alleen wat de client mag weten) en evalueert lokaal. Dit kan backendload verminderen en UI-responsiviteit verbeteren, maar vereist striktere datahygiëne.
Om te beginnen is een modulaire monolith meestal het meest praktisch:
Naarmate het gebruik groeit, is het eerste wat meestal gesplitst wordt het evaluatiepad (read-heavy) van het admin-pad (write-heavy). Je kunt hetzelfde datamodel behouden en later een dedicated evaluatieservice introduceren.
Flag-checks zitten op hete paden, optimaliseer reads:\n
Het doel is consistente gedragingen, zelfs tijdens gedeeltelijke storingen: als het dashboard down is, moeten applicaties nog steeds evalueren met de laatst bekende goede configuratie.
Een feature-flag-systeem slaagt of faalt op zijn datamodel. Als het te los is, kun je wijzigingen niet auditen of veilig terugdraaien. Als het te rigide is, vermijden teams het. Streef naar een structuur die duidelijke defaults, voorspelbare targeting en een betrouwbare geschiedenis ondersteunt.
Flag is de product-level schakelaar. Houd hem stabiel door:
key (uniek, gebruikt door SDKs, bijv. new_checkout)\n- name en description (voor mensen)\n- type (boolean, string, number, JSON)\n- archived_at (soft delete)Variant vertegenwoordigt de waarde die een flag kan teruggeven. Zelfs boolean flags profiteren van expliciete varianten (on/off) omdat dat rapportage en rollouts standaardiseert.
Environment scheidt gedrag per context: dev, staging, prod. Modelleer dit expliciet zodat één flag verschillende regels en defaults per omgeving kan hebben.
Segment is een opgeslagen groepsdefinitie (bijv. “Beta testers”, “Interne gebruikers”, “High spenders”). Segmenten moeten herbruikbaar zijn voor veel flags.
Regels bevatten de meeste complexiteit, maak ze daarom eersteklas records.
Een praktische aanpak:
FlagConfig (per flag + environment) slaat default_variant_id, enabled state en een pointer naar de huidige published revision op.\n- Rule hoort bij een revision en bevat:\n - priority (lagere nummer wint)\n - conditions (JSON-array zoals attributenvergelijkingen)\n - serve (vaste variant, of percentage-rollout over varianten)\n- fallback is altijd default_variant_id in FlagConfig wanneer geen regel matcht.Dit houdt evaluatie simpel: laad de gepubliceerde revision, sorteer regels op prioriteit, match de eerste regel, anders de default.
Behandel elke wijziging als een nieuwe FlagRevision:\n
status: draft of published\n- created_by, created_at, optionele comment\n
Publiceren is een atomische actie: zet FlagConfig.published_revision_id naar de gekozen revision (per omgeving). Drafts laten teams wijzigingen voorbereiden zonder gebruikers te beïnvloeden.Voor audits en rollback, sla een append-only wijzigingslog op:\n
AuditEvent: wie wijzigde wat, wanneer, in welke omgeving\n- before/after snapshots (of een JSON-patch) die naar revisie-IDs verwijzenRollback wordt dan “her-publiceer een oudere revisie” in plaats van handmatig instellingen reconstrueren. Dat is sneller, veiliger en makkelijk uit te leggen aan niet-technische stakeholders via de history-view van het dashboard.
Targeting is het “wie krijgt wat”-deel van feature flags. Goed gedaan stelt je in staat veilig uit te rollen: expose een wijziging eerst aan interne gebruikers, dan aan een specifieke klanttier, dan aan een regio — zonder redeploy.
Begin met een klein, consistent set attributen die je apps betrouwbaar met elke evaluatie sturen:
Houd attributen saai en voorspelbaar. Als de ene app plan=Pro stuurt en de andere plan=pro, gedragen regels zich onvoorspelbaar.
Segmenten zijn herbruikbare groepen zoals “Beta testers,” “EU-klanten,” of “Alle enterprise-admins.” Implementeer ze als opgeslagen definities (geen statische lijsten), zodat lidmaatschap on-demand kan worden berekend:
Voor snelle evaluatie cache je segmentlidmaatschap kort (seconden/minuten), keyed per omgeving en gebruiker.
Definieer een duidelijke evaluatievolgorde zodat resultaten uitlegbaar zijn in het dashboard:\n
Ondersteun AND/OR groepen en gangbare operators: equals, not equals, contains, in list, greater/less than (voor versies of numerieke attributen).
Minimaliseer persoonlijke data. Geef de voorkeur aan stabiele, niet-PII identifiers (bijv. een interne user ID). Als je identifiers moet opslaan voor allow/deny-lijsten, sla dan gehashte IDs op waar mogelijk en vermijd het kopiëren van e-mails, namen of ruwe IP-adressen in je flag-systeem.
Rollouts zijn waar een feature flag-systeem echte waarde levert: je kunt veranderingen geleidelijk blootstellen, opties vergelijken en problemen stoppen — zonder redeploy.
Een percentage-rollout betekent “activeer voor 5% van gebruikers” en verhoog dan naarmate het vertrouwen groeit. De sleutel is consistente bucketing: dezelfde gebruiker moet betrouwbaar in (of uit) de rollout blijven over sessies.
Gebruik een deterministische hash van een stabiele identifier (bijv. user_id of account_id) om een bucket 0–99 toe te wijzen. Als je gebruikers willekeurig bij elke request kiest, zullen mensen tussen ervaringen "flippen", metrics ruisen en support teams issues niet kunnen reproduceren.
Bepaal ook bewust de bucketeenheid:
Begin met boolean flags (aan/uit), maar plan voor multivariabele varianten (bijv. control, new-checkout-a, new-checkout-b). Multivariabel is essentieel voor A/B-tests, copy-experimenten en incrementele UX-wijzigingen.
Je regels moeten altijd één opgeloste waarde per evaluatie retourneren, met een duidelijke prioriteitsvolgorde (bijv. expliciete overrides > segmentregels > percentage-rollout > default).
Planning laat teams releases coördineren zonder iemand wakker te houden om een schakel om te zetten. Ondersteun:
Behandel schema’s als onderdeel van de flag-config, zodat wijzigingen auditeerbaar en previewbaar zijn voordat ze live gaan.
Een kill switch is een nood-"force off" die alles overschrijft. Maak het een eersteklas controle met het snelste pad in UI en API.
Bepaal wat er gebeurt tijdens storingen:
Documenteer dit duidelijk zodat teams weten wat de app doet als het flag-systeem gedegradeerd is. Voor meer over dagelijkse werkwijzen zie vermeldingen zoals /blog/testing-deployment-and-governance.
Je webapp is slechts de helft van het systeem. De andere helft is hoe je productcode flags veilig en snel leest. Een nette API plus een kleine SDK voor elk platform (Node, Python, mobiel, etc.) zorgt voor consistente integratie en voorkomt dat elk team z’n eigen aanpak uitvindt.
Je applicaties zullen read-endpoints veel vaker aanroepen dan write-endpoints, optimaliseer deze eerst.
Gangbare patronen:
GET /api/v1/environments/{env}/flags — list alle flags voor een omgeving (vaak gefilterd op “enabled” alleen)\n- GET /api/v1/environments/{env}/flags/{key} — haal een enkele flag op via key\n- GET /api/v1/environments/{env}/bootstrap — haal flags + segmenten op die nodig zijn voor lokale evaluatieMaak responses cache-vriendelijk (ETag of updated_at versie) en houd payloads klein. Veel teams ondersteunen ook ?keys=a,b,c voor batch fetch.
Write-endpoints moeten strikt en voorspelbaar zijn:
POST /api/v1/flags — create (valideer key-uniciteit, naamgevingsregels)\n- PUT /api/v1/flags/{id} — update draft-config (schema-validatie)\n- POST /api/v1/flags/{id}/publish — promote draft naar een omgeving\n- POST /api/v1/flags/{id}/rollback — revert naar laatste bekende goede versieGeef duidelijke validatiefouten terug zodat het dashboard kan uitleggen wat er moet worden hersteld.
Je SDK moet caching met TTL, retries/backoff, timeouts en een offline fallback (serve last cached values) afhandelen. Het moet ook een enkele "evaluate"-aanroep blootstellen zodat teams je datamodel niet hoeven te begrijpen.
Als flags van invloed zijn op prijs, entitlements of security-gevoelig gedrag, vertrouw dan niet op de browser/mobile client. Geef de voorkeur aan server-side evaluatie, of gebruik ondertekende tokens (server geeft een ondertekende "flag snapshot" die de client kan lezen maar niet vervalsen).
Een feature flag-systeem werkt alleen als mensen het genoeg vertrouwen om tijdens echte releases te gebruiken. Het admin dashboard bouwt dat vertrouwen: duidelijke labels, veilige defaults en wijzigingen die makkelijk te reviewen zijn.
Begin met een simpele flaglijstweergave die ondersteunt:
Maak de “huidige staat” in één oogopslag leesbaar. Bijvoorbeeld: Aan voor 10%, Targeting: Beta segment, of Uit (kill switch actief) in plaats van alleen een groene stip.
De editor moet voelen als een begeleid formulier, niet als een technische configuratiescherm.
Voeg toe:
Als je varianten ondersteunt, toon ze als mensvriendelijke opties (“Nieuwe checkout”, “Oude checkout”) en valideer dat het verkeer correct optelt.
Teams hebben bulk enable/disable en “kopieer regels naar een andere omgeving” nodig. Voeg guardrails toe:
Gebruik waarschuwingen en verplichte notities voor risicovolle acties (productiewijzigingen, grote percentage-sprongen, kill switch toggles). Toon een wijzigingssamenvatting vóór opslaan — wat veranderde, waar en wie erdoor wordt getroffen — zodat niet-technische reviewers met vertrouwen kunnen goedkeuren.
Security is waar feature flag-tools snel vertrouwen winnen — of door je securityteam worden geblokkeerd. Omdat flags gebruikerservaringen direct kunnen veranderen (en soms productie kunnen breken), behandel toegangscontrole als een eersteklas onderdeel van je product.
Begin met e-mail + wachtwoord voor eenvoud, maar plan voor enterpriseverwachtingen.
Een helder model is role-based access control (RBAC) plus omgeving-niveau permissies.
Scope die rol vervolgens per omgeving (Dev/Staging/Prod). Iemand kan bijvoorbeeld Editor in Staging zijn maar alleen Viewer in Prod. Dit voorkomt per ongeluk schakelen in productie terwijl teams elders snel kunnen werken.
Voeg een optionele goedkeuringsworkflow toe voor productie-edits:
Je SDKs hebben credentials nodig om flagwaarden op te halen. Behandel deze als API-keys:
Voor traceerbaarheid, koppel dit aan je audittrail-design en logging.
Wanneer feature flags echte gebruikerservaringen aansturen, wordt “wat veranderde?” een productieprobleem, geen papierwerk. Auditing en monitoring veranderen je rollout-tool van een togglebord in een operationeel systeem dat je team kan vertrouwen.
Elke write-actie in de admin-app moet een audit-event genereren. Behandel het als append-only: wijzig geschiedenis nooit — voeg een nieuw event toe.
Leg de essentie vast:
Maak de log makkelijk doorzoekbaar: filter op flag, omgeving, actor en tijdsbestek. Een "kopieer link naar deze wijziging" deep link is erg waardevol tijdens incidenten.
Voeg lichte telemetry toe rond flag-evaluaties (SDK-reads) en beslissingsuitkomsten (welke variant werd geserveerd). Minimaal registreer:
Dit helpt bij debuggen (“ontvangen gebruikers daadwerkelijk variant B?”) en governance (“welke flags zijn dood en kunnen verwijderd worden?”).
Alerts moeten een wijzigingsgebeurtenis koppelen aan een impactsignaal. Een praktische regel: als een flag is ingeschakeld (of opgehoogd) en errors stijgen kort daarna, page dan iemand.
Voorbeelden van alertcondities:
Maak een simpel "Ops"-gebied in je dashboard:
Deze weergaven verminderen giswerk tijdens incidenten en maken rollouts gecontroleerd in plaats van riskant.
Feature flags zitten op het kritieke pad van elk request, dus betrouwbaarheid is een producteigenschap, geen infra-detail. Je doel is eenvoudig: flag-evaluatie moet snel, voorspelbaar en veilig zijn, zelfs wanneer delen van het systeem gedegradeerd zijn.
Begin met in-memory caching in je SDK of edge-service zodat de meeste evaluaties het netwerk niet halen. Houd de cache klein en keyed op omgeving + flagset-versie.
Voeg Redis toe als je gedeelde, low-latency reads nodig hebt over veel app-instances (en om load op je primaire database te verminderen). Redis is ook nuttig voor het opslaan van een “huidige flag snapshot” per omgeving.
Een CDN helpt alleen als je een read-only flags-endpoint exposeert dat veilig publiek te cachen is of per-tenant (vaak is dat niet het geval). Als je een CDN gebruikt, geef de voorkeur aan ondertekende, kortlevende responses en vermijd caching van gebruikersspecifieke data.
Polling is eenvoudiger: SDKs halen elke N seconden de laatste flag-snapshot op met ETags/version checks om onnodig downloaden te vermijden.
Streaming (SSE/WebSockets) geeft snellere propagatie voor rollouts en kill switches. Het is geweldig voor grote teams, maar vereist meer operationele zorg (connectielimieten, reconnect-logic, regionale fanout). Een praktisch compromis is polling standaard en optionele streaming voor "instant" omgevingen.
Bescherm je API's tegen foutieve SDK-configuraties (bijv. pollen elke 100ms). Handhaaf server-side minimumintervallen per SDK-key en geef duidelijke fouten terug.
Bescherm ook je database: zorg dat je read-pad snapshot-based is, niet “evalueer regels door user-tabellen te joinen.” Feature-evaluatie mag nooit dure joins triggeren.
Back-up je primaire datastore en voer restore-drills periodiek uit (niet alleen backups). Sla een onveranderlijke geschiedenis van flag-snapshots op zodat je snel kunt terugdraaien.
Definieer veilige defaults voor outages: als de flag-service niet bereikbaar is, moeten SDKs terugvallen op de laatst bekende goede snapshot; als er geen bestaat, default naar “uit” voor risicovolle features en documenteer uitzonderingen (zoals billing-kritieke flags).
Een feature flag-systeem is niet "deploy en vergeet." Omdat het productgedrag aanstuurt, wil je hoge zekerheid in rule-evaluatie, wijzigingsworkflows en rollback-paden — en een lichte governance zodat het systeem veilig blijft naarmate meer teams het gebruiken.
Begin met tests die de kernbeloftes van flagging beschermen:
Een praktisch advies: voeg “golden” testcases toe voor lastige regels (meerdere segmenten, fallbacks, conflicterende condities) zodat regressies duidelijk zijn.
Maak staging een veilige oefenomgeving:
Voor productie-releases, gebruik een korte checklist:
Voor governance: houd het simpel: definieer wie naar productie kan publiceren, vereis goedkeuring voor high-impact flags, review verouderde flags maandelijks en stel een “vervaldatum” veld in zodat tijdelijke rollouts niet eeuwig blijven.
Als je dit als intern platform bouwt, helpt het vaak om te standaardiseren hoe teams wijzigingen aanvragen. Sommige organisaties gebruiken Koder.ai om een initieel admin-dashboard op te zetten en workflows (goedkeuringen, audit-samenvattingen, rollback-UX) met stakeholders in chat te itereren, en daarna de codebase te exporteren voor een volledige security review en langdurig eigenaarschap.
Een feature flag (feature toggle) is een runtime-controle die een functionaliteit aan/uit (of naar een variant) zet zonder nieuwe code te deployen. Het scheidt code uitrollen van gedrag activeren, waardoor je veiligere staged rollouts, snelle rollbacks en gecontroleerde experimenten kunt uitvoeren.
Een praktische opzet verdeelt het systeem in:
Deze scheiding houdt de wijzigingsworkflow veilig en auditeerbaar en zorgt ervoor dat evaluaties weinig latency hebben.
Gebruik consistente bucketing: bereken een deterministische hash van een stabiele identifier (bijv. user_id of account_id), zet die om naar 0–99 en includeer/excludeer op basis van het rollout-percentage.
Vermijd per-request willekeur; anders zullen gebruikers tussen ervaringen "flippen", worden metrics ruiserig en kan support issues niet reproduceren.
Begin met:
Een duidelijke precedentie maakt resultaten uitlegbaar:
Houd de set attributen klein en consistent (bijv. role, plan, region, app version) om drift tussen services te voorkomen.
Sla schema’s op als onderdeel van de omgeving-specifieke flag-config:
Maak geplande wijzigingen auditeerbaar en previewbaar, zodat teams precies kunnen bevestigen wat er gebeurt voordat het live gaat.
Optimaliseer voor read-heavy gebruik:
Dit voorkomt dat je database bij elke flag-check wordt aangeroepen.
Als een flag van invloed is op prijsstelling, entitlements of securitygevoelig gedrag, geef dan de voorkeur aan server-side evaluatie zodat clients regels of attributen niet kunnen manipuleren.
Als client-evaluatie noodzakelijk is:
Gebruik RBAC plus omgeving-scoping:
Voor productie: voeg optionele goedkeuringen toe voor wijzigingen in targeting/rollouts/kill switch. Leg altijd aanvrager, goedkeurder en de exacte wijziging vast.
Leg ten minste vast:
Voor outages: SDKs moeten terugvallen op de last known good config, en daarna een gedocumenteerde veilige default (vaak “off” voor risicovolle features). Zie ook auditing, monitoring and alerts en testing, deployment and governance.
key, type, naam/omschrijving, archived/soft-delete.dev/staging/prod met gescheiden configuraties.Voeg revisions (draft vs published) toe zodat publiceren een atomische pointerwijziging is en rollback neerkomt op het opnieuw publiceren van een oudere revisie.