# Was ist ein Feature Flag? Ein Leitfaden für Solo-Entwickler URL: https://whatshouldibuildnext.com/de/journal/was-ist-ein-feature-flag Type: blog Locale: de Published: 2026-10-31 Updated: 2026-11-01 --- > Ein Feature Flag ist ein if-Statement, das du ohne erneutes Deployment umschaltest. Hier sind die vier Typen, was sie kosten und wann ein Solo-Entwickler darauf verzichten sollte. Was ist ein Feature Flag? Ein `if`-Statement, dessen Antwort außerhalb deines Codes liegt. Du lieferst den neuen Codepfad abgeschaltet aus und schaltest ihn später ein, indem du einen Wert in einer Konfigurationsdatei, einer Datenbankzeile oder einem Flag-Service änderst, ohne neu zu deployen. Genau dieser Trick trennt das Ausliefern von Code vom Veröffentlichen eines Features. Deshalb ist ein Flag das billigste Rollback, das du je besitzen wirst. Ich habe die zweite Hälfte dieses Satzes auf die harte Tour gelernt. Mein erster Flag war ein Boolean in einer Umgebungsvariable, am Freitagabend umgelegt, und ich hatte elf Monate lang vergessen, dass er existierte. Nichts ging kaputt. Genau das ist das Problem, und wir kommen gleich darauf zurück. ## Wie sieht ein Feature Flag im Code eigentlich aus? Kleiner, als die Homepages der Anbieter vermuten lassen. Ohne Dashboards ist ein Flag nur ein Lookup und eine Verzweigung: `const flags = { newCheckout: false }; if (flags.newCheckout) { return renderNewCheckout(user); } return renderOldCheckout(user);`Alles andere ist eine Frage, woher `flags` kommt und wer es ändern darf. Eine Konstante in der Datei ist ein Flag, das du durch ein Deployment änderst, was den Sinn verfehlt. Eine Umgebungsvariable ändert sich beim Neustart. Eine Zeile in deiner Datenbank ändert sich in Sekunden. Ein gehosteter Dienst ändert sich ebenfalls in Sekunden und liefert dir zusätzlich Targeting pro Nutzer, eine Oberfläche und ein Audit-Log. Was in der Praxis hakt: Der Code ist trivial, der Lebenszyklus nicht. Zwei Zweige in Produktion bedeuten zwei Verhaltensweisen zum Testen und zwei Pfade zum Debuggen um 2 Uhr nachts, und einer davon ist zum Verrotten verurteilt. ![Industrieller Kippschalter mit rotem Knopf auf einem Stahl-Bedienfeld, ein Notausschalter](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/9ca39f-i1.webp) ## Welche vier Arten von Feature Flags gibt es, und welche brauchst du zuerst? Martin Fowlers [Taxonomie der Feature Toggles](https://martinfowler.com/articles/feature-toggles.html) ist nach wie vor die sauberste Art, sie zu sortieren. Die nützliche Achse ist, wie lange jede Art leben sollte. **Release-Flags** verstecken unfertige oder riskante Arbeit. Sie sind kurzlebig: eine Woche oder zwei, dann löschen. Diesen Typ brauchst du zuerst. **Ops-Flags** sind Notausschalter. Du umhüllst ein schweres oder fragiles Feature, etwa ein Empfehlungs-Widget oder einen Drittanbieter-Aufruf, damit du es unter Last abschalten kannst, ohne zu deployen. Die meisten sind kurzlebig, einige bleiben dauerhaft, und das ist in Ordnung. **Experiment-Flags** teilen Nutzer für A/B-Tests in Gruppen auf. Sie leben so lange, bis ein statistisch aussagekräftiges Ergebnis vorliegt, also Stunden bis Wochen, und sie brauchen echten Traffic, um etwas zu bedeuten. **Berechtigungs-Flags** steuern Features nach Tarif oder Konto: den Pro-Tarif, die Beta-Gruppe. Die können jahrelang bestehen, und dann sind sie eigentlich keine Flags mehr. Sie sind Berechtigungen und verdienen ein richtiges Datenmodell. Wenn du als Solo-Entwickler 40 Nutzer hast, brauchst du Release-Flags und vielleicht einen Notausschalter. Experiment-Flags bei 40 Nutzern erzeugen Rauschen, keine Daten. Warte damit, bis du die Metrik und die Stichprobengröße nennen kannst. ## Welches Problem lösen Flags, das Branches und Deployments nicht lösen? Drei Dinge, und nur diese drei sind es wert, sich darum zu kümmern. **Unfertige Arbeit sicher ausliefern.** Langlebige Branches tun weh, weil das Zusammenführen ein kleiner Krieg ist. Ein Flag erlaubt dir, jeden Tag in main zu mergen, während der neue Code ausgeschaltet bleibt. Das ist der Motor hinter Trunk-based Development, bei dem alle auf einen Branch committen und die Flags die unfertigen Teile tragen. **Schrittweiser Rollout.** Schalte das Feature für dich selbst ein, dann für 1 % der Nutzer, dann 10 %, dann alle. Fowler beschreibt, eine Canary-Gruppe von etwa 1 % zu wählen, indem man die Nutzer-ID modulo 100 rechnet. Wenn etwas schiefgeht, betrifft es eine Handvoll Menschen statt deiner gesamten Basis. **Schnelles Zurücknehmen.** Ein Deployment zurückzurollen bedeutet einen Build, eine Pipeline und etwas Nerven. Ein Flag umzuschalten bedeutet eine Änderung. An einem schlechten Tag ist der Unterschied Minuten Schmerz gegen eine Stunde. Nichts davon braucht am ersten Tag einen Anbieter. Alles davon braucht Disziplin. ## Brauchst du LaunchDarkly, oder reicht eine JSON-Datei? Eine JSON-Datei oder eine Datenbanktabelle reicht, bis eines dieser Dinge zutrifft: Jemand ohne Entwicklerhintergrund muss Flags umlegen können, du brauchst prozentuale Rollouts oder Targeting pro Nutzer, du brauchst ein Audit-Log darüber, wer was geändert hat, oder du betreibst mehrere Services, die dieselben Flags lesen. Das ist die grobe Leiter, die ich in dieser Reihenfolge hochsteigen würde: - **Konstanten und Umgebungsvariablen.** Keine Kosten. Reicht für das erste Release-Flag eines Side Projects. - **Eine `flags`-Tabelle oder eine JSON-Datei, die zur Laufzeit gelesen wird.** Zehn Zeilen Code, sofortige Umschaltung, kein Anbieter. Damit kommt ein Solo-Projekt erstaunlich weit. - **Ein Open-Source- oder gehosteter Flag-Service.** Wenn du Targeting-Regeln, schrittweise Rollouts und eine Oberfläche willst, die auch andere bedienen können. - **Eine Enterprise-Plattform.** Wenn Compliance, Freigaben und Dutzende Entwickler ins Spiel kommen. Gehostete Tools decken die Schritte 3 und 4 ab. LaunchDarkly ist der Platzhirsch mit der tiefsten Targeting- und Governance-Funktionalität und einem Preis, der das widerspiegelt. Statsig bündelt Flags mit Experimenten und Produktanalytik. Das ergibt Sinn, wenn du messen willst, was das Flag bewirkt hat, und nicht nur umschalten. Verzichte auf beides, wenn dein ganzes Team aus dir besteht. Eine Tabelle mit drei Spalten schlägt ein Dashboard, das du zweimal im Quartal öffnest. Wähle einen Dienst erst, wenn dich die manuelle Variante etwas Konkretes gekostet hat, etwa eine nächtliche Änderung an der Produktionskonfiguration, die du bereust. Eine Versicherung, die sich lohnt zu kennen: [OpenFeature](https://openfeature.dev/docs/reference/intro) ist ein CNCF-Incubating-Projekt, das eine herstellerneutrale API zur Auswertung von Flags definiert, mit SDKs unter anderem für Node.js, Python, Go, Java, .NET und Web-Clients. Du programmierst gegen die Standardschnittstelle und tauschst den Provider darunter aus. Wenn du ahnst, dass du dein erstes Setup überwachsen wirst, wird der Wechsel über OpenFeature zu einer Konfigurationsänderung. ![Notizbuch mit handgezeichneten Kontrollkästchen und Pfeilen auf einem Entwicklertisch bei Nacht](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/f90753-i2.webp) ## Wie fügst du dein erstes Flag hinzu, ohne Chaos anzurichten? Beginne mit einem einzigen Release-Flag und ein paar Grundregeln. Das ist die Version, der ich gern gefolgt wäre. **Benenne es nach dem Feature, nicht nach dem Mechanismus.** `new-checkout-flow` sagt dir, was kaputtgeht, wenn es falsch ist. `flag_47` sagt dir in sechs Monaten nichts. **Standard auf aus, und aus bedeutet das alte Verhalten.** Die Konvention „aus gleich alt, an gleich neu“ ist das, was dich das System unter Druck verstehen lässt. Brichst du sie, wird jedes Flag zum Rätsel. **Auswerten an einer einzigen Stelle.** Fowler nennt die Lösung Toggle-Inversion: Statt `if (flags.x)` in zwanzig Dateien zu verteilen, entscheide einmal, nahe am Rand des Systems, und gib das Ergebnis weiter. Ein Entscheidungspunkt bedeutet eine Stelle zum Ändern und eine Stelle zum Testen. **Schreibe das Entfernungs-Ticket in dem Moment, in dem du das Flag anlegst.** Lege es mit Datum ins Backlog. Fowler schlägt außerdem Verfallsdaten für kurzlebige Toggles vor und sogar Tests, die fehlschlagen, sobald ein Flag sein Datum überschreitet. Ein Flag ohne Entfernungs-Ticket ist ein Kredit ohne Tilgungsplan. **Protokolliere jede Auswertung, die zählt.** Wenn ein Nutzer einen Fehler meldet, willst du wissen, auf welcher Seite des Flags er war. Kannst du das nicht beantworten, ist das Flag eine Belastung. Beim Testen wird oft übertrieben. Du musst nicht jede Kombination von Flags testen, weil die meisten Flags nicht miteinander interagieren. Teste die Konfiguration, die du in Produktion erwartest, teste den Fallback bei ausgeschaltetem neuen Flag, und optional einen Durchlauf mit allem eingeschaltet, um Abweichungen zu finden. ## Was kosten Feature Flags wirklich, worüber niemand spricht? Jedes Flag verdoppelt einen Codepfad. Zehn unabhängige Flags ergeben theoretisch 1.024 Kombinationen. Du wirst nie alle testen, aber du kannst trotzdem auf eine stoßen, die in Produktion niemand vorhergesehen hat. Teurer sind die toten Flags. Der Rollout ist abgeschlossen, alle nutzen das neue Verhalten, das Flag bleibt bei 100 %, und der alte Zweig liegt im Repo als Code, den niemand zu löschen wagt. Sechs Monate später erinnert sich niemand, ob das Abschalten sicher ist. Die berühmteste Version davon ist Knight Capital im August 2012. Ein altes Flag, das einst eine ausgemusterte Handelsfunktion aktiviert hatte, wurde für neuen Code wiederverwendet. Einer von acht Servern hat das Deployment verpasst und lief weiter mit altem Code. In 45 Minuten verlor die Firma laut eigenem Quartalsbericht rund $440 Millionen, eine Zahl, die spätere Berichte näher bei $460 Millionen sehen. Das war ein Handelshaus mit echtem Geld und echten Ingenieuren, deshalb behaupte ich nicht, dass dein Side Project sicherer ist. Die Lehre skaliert problemlos nach unten: Verwende nie einen Flag-Namen wieder, und lösche tote Flags, bevor sie zur Archäologie werden. ![Reihe Messingschlüssel an Haken, manche verrostet, manche blank, wie alte Flags, die im Code liegen geblieben sind](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-11/967554-i3.webp) Fowlers Sicht, bei der ich bleibe: Behandle Flags wie Inventar mit Lagerkosten. Manche Teams begrenzen die Anzahl aktiver Flags und verlangen, dass eines entfernt wird, bevor ein neues hinzukommt. Für einen Solo-Entwickler ist eine harte Obergrenze von fünf mehr als genug. ## Wann solltest du Feature Flags ganz weglassen? Öfter, als die Tool-Anbieter zugeben. Verzichte darauf, wenn das Feature klein ist, sich die Änderung in Git leicht zurücknehmen lässt und dein Deployment zwei Minuten dauert. Ein Flag fügt einen Zweig, eine Konfigurationsquelle und eine Sache hinzu, die man vergessen kann. Ist ein Revert schneller als das Umschalten eines Flags, ist das Flag Theater. Verzichte darauf, wenn du noch keine Nutzer hast. Ein schrittweiser Rollout auf null Personen ist nur eine Verzögerung. Ausliefern, Logs anschauen, reparieren. Verzichte darauf bei Datenbankmigrationen, die sich nicht durch einen Schalter zurücknehmen lassen. Ein Flag kann eine neue Spalte in der Oberfläche verbergen, aber es kann keine gelöschte Tabelle wiederherstellen. Schemaänderungen brauchen einen eigenen Expand-and-Contract-Plan, mit oder ohne Flags. Sie lohnen sich, wenn die Änderung Zahlungen oder Authentifizierung betrifft, wenn du täglich mit unfertiger Arbeit mergen willst oder wenn eine Drittanbieter-Abhängigkeit ausfallen könnte und du einen Notausschalter willst. ## Was musst du beobachten, sobald ein Flag live ist? Ein Flag steuert die Sichtbarkeit, und die hilft nur, wenn du siehst, was danach passiert. Ein Feature für 10 % der Nutzer einzuschalten, ohne Fehlerraten und Latenz zu beobachten, ist ein Münzwurf mit zusätzlichen Schritten. Stelle vor dem ersten Rollout sicher, dass du drei Fragen in unter einer Minute beantworten kannst: Sind die Fehler in der betroffenen Gruppe gestiegen, ist die Latenz schlechter, hat sich etwas in nachgelagerten Systemen geändert? Uptime-Monitoring und Log-Suche decken für ein kleines Produkt das meiste ab. Ein Tool wie Better Stack bündelt Monitore, Statusseiten und Logs an einem Ort, mit einem kostenlosen Tarif. Meine Regel heute: Ein Flag ist nur so gut wie der Alarm, der daranhängt. Ohne ihn schaltest du im Dunkeln. ## Was würden wir diese Woche tatsächlich tun? Such dir eine unfertige Sache aus, bei der du Angst hast, sie zu mergen. Lege sie hinter einen Boolean, den du aus einer Tabelle oder JSON-Datei liest, Standard aus, und merge sie heute in main. Schreibe das Entfernungs-Ticket, bevor du den Editor schließt, mit einem Datum in zwei Wochen. Dann schalte es nur für dich ein und nutze es einen Tag lang. Hält es stand, erweiterst du es. Wenn nicht, schaltest du es aus, und du hast nichts verloren außer einer Minute. Welches Flag in deiner Codebasis ist gerade seit mehr als einem Monat bei 100 %? Das ist deine erste Löschung. ## FAQ ### Was ist ein Feature Flag einfach erklärt? Ein Feature Flag ist eine Bedingung im Code, deren An-aus-Wert außerhalb des Codes liegt, in einer Konfigurationsdatei, einer Datenbank oder einem Flag-Service. Du kannst ihn zur Laufzeit ändern. So lässt sich ein Feature verdeckt ausliefern und später freischalten, ohne erneutes Deployment. ### Sind Feature Flags und Feature Toggles dasselbe? Ja. Feature Flag, Feature Toggle, Feature Switch und Release Toggle beschreiben alle dieselbe Technik. Teams wählen den Begriff aus Gewohnheit, und Tools verwenden die Begriffe austauschbar. ### Welche Haupttypen von Feature Flags gibt es? Vier Typen sind gängig: Release-Flags, um unfertige Arbeit zu verbergen, Ops-Flags (Notausschalter), um riskante Features abzuschalten, Experiment-Flags für A/B-Tests und Berechtigungs-Flags, um Features nach Tarif oder Konto zu steuern. ### Brauche ich ein kostenpflichtiges Feature-Flag-Tool für ein Side Project? In der Regel nicht. Eine Konstante, eine Umgebungsvariable, eine JSON-Datei oder eine Datenbanktabelle reicht für ein Solo-Projekt. Wechsle zu einem gehosteten Dienst, wenn Nicht-Entwickler Flags umlegen müssen oder du prozentuale Rollouts, Targeting und ein Audit-Log brauchst. ### Wie lange sollte ein Feature Flag leben? Release-Flags sollten eine oder zwei Wochen leben und dann zusammen mit dem alten Codepfad gelöscht werden. Ops-Notausschalter dürfen länger bleiben. Berechtigungs-Flags können jahrelang bestehen, sind aber eigentlich Berechtigungen und verdienen ein richtiges Datenmodell. ### Was ist das größte Risiko bei Feature Flags? Veraltete Flags. Jedes Flag fügt einen Codepfad hinzu, der getestet werden muss, und ein Flag, das auf 100 % steht, hinterlässt toten Code, den niemand zu entfernen wagt. Knight Capitals Verlust von 2012 in Höhe von rund $440 Millionen hing mit einem wiederverwendeten alten Flag zusammen. Schreibe das Entfernungs-Ticket, sobald du das Flag anlegst.