Feature Flags erklärt:Versteckt ausliefern, per Schalter

Feature Flags erklärt: Ein Feature Flag ist ein An/Aus-Schalter, der in deiner Datenbank statt in deinem Code liegt: Das Feature geht „dunkel“ in Produktion – ausgeliefert, aber unsichtbar – und du launchst es später, indem du den Schalter für einen Beta-Kunden, 10 % der Nutzer oder alle umlegst. Kein Redeploy, keine Code-Änderung, keine Panik am Launch-Tag.

Für einen Solo-Gründer sind Flags der Unterschied zwischen „Launch“ als beängstigendem Deploy und „Launch“ als Entscheidung, die du beim Kaffee triffst. Hier erfährst du, wie sie funktionieren, auf welche vier Arten du sie tatsächlich einsetzt und welche Fehler sie nach hinten losgehen lassen.

Feature Flags erklärt: was ein Feature Flag eigentlich ist

Ohne Flags bedeutet die Kontrolle darüber, wer ein Feature sieht, Code zu ändern. Der klassische Hack sieht so aus: „Wenn die E-Mail des Nutzers auf der Domain des Beta-Kunden endet, zeige das neue Feature.“ Jede Änderung dieser Regel ist eine Code-Änderung, und jede Code-Änderung ist ein Deployment. Die Konfiguration liegt an fünf verschiedenen Orten, nichts hat einen Audit-Trail, und wer den Schalter umlegen kann, ist, wer weiß, wo der Hack steckt.

Ein Feature Flag verlagert diese Entscheidung in die Daten. Das Flag ist ein benannter Schalter – „new_dashboard: off“ –, der in deinem Einstellungssystem neben Dingen wie Zeitzone und Theme gespeichert ist. Dein Code stellt eine einzige Frage: Ist dieses Flag für diesen Nutzer an? Ändere die Antwort in einem Dashboard, und das Produkt ändert sein Verhalten sofort – ohne Deployment. Flags sitzen in derselben Hierarchie wie der Rest deiner Einstellungen: ein globaler Standard, überschreibbar pro Organisation, überschreibbar pro Nutzer.

Versteckt ausliefern, per Schalter launchen

Der große gedankliche Durchbruch ist, dass Deployen und Launchen zwei verschiedene Ereignisse sind, und Flags sind das, was sie trennt.

Deployen heißt, dein Code hat den Server erreicht. Launchen heißt, Nutzer können ihn sehen. Ohne Flags sind das derselbe Moment – deshalb fühlen sich Launches gefährlich an und deshalb sitzen Gründer wochenlang auf fertiger Arbeit und warten auf den „richtigen“ Tag. Mit Flags deployst du das Feature halbfertig, dunkel, zehnmal, wenn du willst. Es fährt bei jedem Release mit, wird in Produktion getestet und ist nur für dich sichtbar. Wenn es bereit ist, ist der Launch ein Schalter – und wenn Deployen dir noch Angst macht, ist dies das Muster, das den größten Teil dieser Angst nimmt.

Es verändert auch dein Marketing. Wenn ein Launch nichts kostet, hörst du auf, alles auf einen großen Tag zu setzen, und lieferst stattdessen einen Strom kleiner, per Flag gesteuerter Releases aus – der Motor hinter Micro-Launches.

Die vier Arten, wie Gründer Flags tatsächlich nutzen

Beachte, dass das ebenso Produkt- und Marketing-Werkzeuge sind wie technische. Beta-Zugang ist ein Verkaufsgespräch („Willst du frühen Zugang?“). Schrittweiser Rollout ist Risikomanagement. A/B-Testing ist Optimierung der Preisseite. Der Notausschalter ist eine Schlafversicherung.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Das Argument für Flags um 2:47 Uhr nachts

Eine wahre Geschichte aus meinem eigenen Produktivsystem: 2:47 Uhr, mein Handy vibriert wegen eines Fehlerraten-Alarms. Ein Endpunkt schlägt fehl, Nutzer sind betroffen. Zwei Optionen – halb im Schlaf debuggen oder mit zwei Klicks auf die vorherige Version zurückrollen. Ich habe zurückgerollt. In 90 Sekunden behoben, wieder ins Bett, am Morgen in Ruhe richtig debuggt.

Ein Rollback ist ein grobes Werkzeug: Er macht alles in diesem Release rückgängig – das kaputte Feature und die drei guten, die mit ausgeliefert wurden. Ein Feature Flag ist chirurgisch. Liegt das kaputte Ding hinter einem Flag, schaltest du nur dieses Feature ab und lässt den Rest des Releases weiterlaufen. Im besten Fall stehst du gar nicht erst vor der Entscheidung um 2:47 Uhr: Der schrittweise Rollout sorgte dafür, dass nur 10 % der Nutzer den Fehler je sahen, das Flag ging aus, und die meisten deiner Kunden haben nie erfahren, dass etwas passiert ist.

Die Fehler, die Flags nach hinten losgehen lassen

• Kein Standardwert. Du fügst ein neues Flag hinzu, definierst aber nie, was es für bestehende Nutzer bedeutet – sie bekommen eine undefinierte Antwort, und die App verhält sich auf nicht reproduzierbare Weise falsch. Jedes Flag wird mit einem expliziten Standardwert ausgeliefert.
• Kein Audit-Trail. Das Produkt verhält sich plötzlich anders, und niemand weiß, wer was wann umgelegt hat. Jede Flag-Änderung sollte festhalten: wer, was, alter Wert, neuer Wert, Zeitstempel – Flags ohne Historie sind ein Debugging-Albtraum.
• Jeder kann alles umlegen. Flags sind Produktionskontrollen. Das Ändern eines Flags auf Organisationsebene sollte Admin-Rechte erfordern, genau wie das Ändern der Abrechnung der Organisation.
• Das Flag bei jeder Anfrage per Datenbankabfrage prüfen. Flag-Prüfungen passieren ständig; sie müssen aus einem Cache kommen, der sich aktualisiert, wenn sich das Flag ändert, nicht aus einer frischen Abfrage bei jedem Seitenaufruf.

Brauchst du Flags von Tag eins an?

Früher, als du denkst. Du brauchst kein ausgefallenes Flag-Produkt – eine Flags-Tabelle in deiner eigenen Datenbank, verwaltet über eine einfache Admin-Oberfläche, ist das Muster, das dies in jeder Größenordnung antreibt. Es ist Teil deines Einstellungssystems, das die KI aus einer guten Spezifikation schnell baut; die Flag-Mechanik selbst sind ein paar Stunden Arbeit, kein Projekt.

Der Nutzen beginnt mit deinem allerersten beängstigenden Feature. Wenn du das erste Mal an einem Dienstag etwas dunkel auslieferst, die ganze Woche in Produktion testest und es am Montag per Schalter „launchst“, wirst du dich fragen, wie jemand allein ohne das baut.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Feature Flag und einer Einstellung?

Eine Einstellung speichert eine Präferenz – Zeitzone, Theme, Währung. Ein Feature Flag speichert eine Entscheidung über Verfügbarkeit: Ist dieses Feature an, und für wen? Beide liegen im selben hierarchischen System (globaler Standard → Organisations-Override → Nutzer-Override), weshalb die Flag-Mechanik meist als Teil deines Einstellungssystems gebaut wird.

Was ist der Unterschied zwischen einem Feature Flag und einem Rollback?

Ein Rollback setzt dein gesamtes Deployment auf die vorherige Version zurück – wirksam, aber es nimmt die guten Änderungen mit den schlechten herunter. Ein Flag schaltet ein bestimmtes Feature ab und lässt alles andere weiterlaufen. Du willst beides: Rollbacks als Notbremse, Flags als Präzisionswerkzeug, nach dem du zuerst greifst.

Machen Feature Flags die App langsamer?

Nicht, wenn sie gecacht sind. Die Flag-Prüfung läuft ständig, also muss die Antwort aus einem Cache kommen, der sich aktualisiert, wenn ein Flag sich ändert – nie aus einer frischen Datenbankabfrage pro Seitenaufruf. Richtig gemacht sind die Kosten praktisch null.

Kann ein nicht-technischer Gründer Feature Flags verwalten?

Genau das ist der Sinn. Flags verlagern Launch-Entscheidungen aus dem Code in ein Dashboard: Du entscheidest, wer was wann sieht, ohne ein Deployment anzufassen. Du steuerst den Rollout – heute 10 %, am Montag alle – so, wie du einen Newsletter planen würdest.