Feature Flags in Startups: Die Tools, die die Investition wert sind

Jedes Startup erreicht einen Punkt, an dem es sich zwischen Bereitstellung und Veröffentlichung entscheiden muss. Es handelt sich um verschiedene Dinge, und eine Verwechslung der beiden ist kostspielig. Deploy bedeutet, den Code in die Produktion zu überführen. Release bedeutet, dem Benutzer die Funktionalität bereitzustellen. Es gibt Feature-Flags, um diese beiden Entscheidungen zu trennen, und wenn sie richtig eingesetzt werden, verändern sie die Arbeitsweise des gesamten Teams.

Das Problem ist, dass die Diskussion über Feature-Flags fast immer mit dem Tool beginnt. Jemand empfiehlt ein bekanntes SaaS, das Team meldet sich an und stellt sechs Monate später fest, dass es für Kapazität bezahlt, die es nie nutzen wird, oder, schlimmer noch, dass es eine wichtige Produktentscheidung an einen Abrechnungsverantwortlichen ausgelagert hat, den es nicht kennt.

Dieser Text richtet sich an diejenigen, die kurz vor der Einstellung stehen. Es geht nicht darum, was ein Feature-Flag ist, sondern darum, worauf es ankommt, wenn man entscheidet, wo man Startkapital anlegt, das die knappste Ressource ist, die es gibt.

Was kaufen Sie wirklich?

Ein Feature-Flag ist im Wesentlichen ein zur Laufzeit konfigurierbarer Wert. Sie könnten dies mit einer Tabelle in der Datenbank und einem Cache implementieren. Warum also für ein Werkzeug bezahlen?

Denn der Wert liegt nicht in if. Es ist überall: Benutzersegmentierung, progressive Einführung (1 %, 5 %, 25 %), sofortiger Kill-Switch, Prüfung, wer was aktiviert hat, Integration mit Analysen zur Messung der Auswirkungen und SDKs, die Ihre Anwendung nicht herunterfahren, wenn der Flag-Dienst ausfällt. An diesem letzten Punkt scheitern die meisten Homebrew-Implementierungen.

Wenn ein Startup Tools bewertet, lautet die richtige Frage nicht „Welches hat mehr Funktionen“, sondern „Welches löst das Problem, das ich jetzt habe, ohne mich auf das zu beschränken, was ich in zwei Jahren brauche“.

Die echten Optionen für diejenigen, die gerade erst anfangen

Der Markt ist in drei Blöcke unterteilt und jeder Block dient einer Bühne.

Spezialisiertes SaaS

LaunchDarkly ist die ausgereifte Referenz in dieser Kategorie. Es macht alles, ist robust und kostet dafür Geld. Bei einem Startup vor der Serie A steigt der Preis pro Sitzplatz und pro Benutzerkontext zu schnell, sodass Sie am Ende möglicherweise mehr für Flags als für Ihre Produktionsinfrastruktur bezahlen müssen. Es lohnt sich, wenn das Experimentieren im Mittelpunkt des Produkts steht und das Team bereits eine Kultur der kontinuierlichen Veröffentlichung hat.

Flagsmith und Unleash besetzen den Mittelweg. Bei beiden gibt es Open-Source-Versionen, die Sie selbst hosten, und verwaltete Versionen. Für ein kleines Team ist es eine finanziell sinnvolle Strategie, mit dem selbstgehosteten Modell zu beginnen und auf das verwaltete Modell umzusteigen, wenn der Betrieb schwierig wird.

Open-Source, selbst gehostet

Unleash ist hier der solideste Name. Sie führen es in einem Container aus, verbinden die SDKs und erhalten 80 % des Wertes eines Premium-SaaS ohne Lizenzkosten. Die Kosten verlagern sich auf Ihr Team: Jemand muss dafür sorgen, dass es weitergeht. Für Startups mit starkem Engineering und einem knappen Budget ist es oft die rationalste Wahl.

Interner Build

Das Bauen zu Hause ist nur dann gerechtfertigt, wenn Feature-Flags Teil Ihres Wettbewerbsunterscheidungsmerkmals sind, beispielsweise eine Plattform, die Experimente verkauft. Bei allem anderen handelt es sich bei internem Aufbau um technische Schulden, die als Einsparungen getarnt sind. Sie sparen das Abonnement und geben doppelt so viel für Wartung, Cache-Bugs und das Fehlen eines zuverlässigen Kill-Switches zum ungünstigsten Zeitpunkt aus.

Wie ich über die Gesamtkosten denke

Der Abopreis ist der sichtbare Teil. Die tatsächlichen Kosten bestehen aus drei Ebenen.

Der erste betrifft die Betriebskosten: Wer wartet ihn, wer reagiert, wenn der Flaggendienst langsam wird, wie viel Infrastruktur verbraucht er. Selbst gehostet scheint bis zum ersten Anbruch des Vorfalls kostenlos zu sein.

Der zweite Grund sind die Lock-in-Kosten. Proprietäre SDKs, spezifische Konfigurationsformate und Integrationen, die nur innerhalb des Ökosystems des Tools funktionieren, verursachen ausgehende Kosten, die nicht im Angebot aufgeführt sind. Fragen Sie vor der Unterschrift, wie es wäre, zu gehen.

Der dritte Punkt sind die Kosten der Flaggenschulden. Jede Flagge, die hereinkommt, braucht einen Plan, um wieder herauszukommen. Teams, die Flags als dauerhaft behandeln, sammeln Hunderte davon an, und der Code wird zu einem Labyrinth von Bedingungen, die niemand zu entfernen wagt. Dies ist der häufigste Fehler und auf lange Sicht der teuerste, und kein Werkzeug allein löst ihn, es ist Prozessdisziplin.

Der Fehler, den Startups meiner Meinung nach machen

Die klassische Falle besteht darin, das Werkzeug vor der Kultur zu übernehmen. Feature-Flags erfordern, dass das Team weiß, wie die Bereitstellung von der Veröffentlichung getrennt werden kann, dass das Produkt über eine progressive Einführung nachdenkt und dass es ein Ritual zur Bereinigung alter Flags gibt. Der Kauf des Werkzeugs ohne Werkzeug ist wie der Kauf eines Rennwagens ohne Fahrkenntnisse.

Ich habe gesehen, wie kleine Teams Flags in verschleierte Produktkonfigurationen verwandelten und Flags für Entscheidungen verwendeten, die in der Datenbank oder in einem Berechtigungssystem sein sollten. Das Ergebnis ist ein Experimentierinstrument, das mit Verantwortlichkeiten überlastet ist, die nicht zu seinen eigenen gehören, und eine wachsende Rechnung ohne proportionale Rendite.

Im brasilianischen Kontext gibt es immer noch einen Punkt, den nur wenige berücksichtigen: Wenn Ihre Flaggen Benutzer nach persönlichen Attributen segmentieren, verarbeiten Sie personenbezogene Daten. Es gilt LGPD. Wem Sie eine Funktion auf Grundlage dessen zur Verfügung stellen und wo diese Segmentierungsdaten gespeichert werden, ist eine Frage der Governance, nicht nur der Technik.

Wann es sich lohnt und wann nicht

Es lohnt sich, wenn Sie häufig starten, Hypothesen mit echten Benutzern testen möchten und eine Paniktaste benötigen, um etwas, das schief gelaufen ist, ohne erneute Bereitstellung zu deaktivieren. Für ein Produkt, das auf den Produktmarkt abgestimmt ist, ist die Fähigkeit, schnell zu testen und rückgängig zu machen, Gold wert.

Es lohnt sich nicht, wenn man einmal im Monat startet, nur wenige Nutzer hat und noch prüft, ob das Produkt für jeden geeignet ist. In diesem Stadium reicht ein einfaches Flag in einer Umgebungsvariablen aus, und das Abonnementgeld macht an anderer Stelle einen größeren Unterschied.

Die reife Entscheidung besteht darin, einfach anzufangen und bei auftretenden Schmerzen die Leiter hinaufzusteigen. Selbstgehostete Open-Source-Lösung für diejenigen mit technischem Hintergrund und wenig Geld. Verwaltetes SaaS, wenn die Wartungskosten die Abonnementkosten übersteigen. Interner Aufbau fast nie.

Die Frage, die zählt

Bei Feature Flags geht es nicht um Technologie. Es geht darum, dem Team die Freiheit zu geben, kleine Fehler zu machen und diese schnell wieder rückgängig zu machen, anstatt bei jeder Veröffentlichung alles aufs Spiel zu setzen. Das richtige Tool ist dasjenige, das diese Freiheit zu den derzeit niedrigsten Gesamtkosten bietet, und nicht dasjenige mit der bekanntesten Marke auf dem Pitch Deck des Konkurrenten.

Wenn Sie diese Entscheidung in Ihrem Startup jetzt treffen und konkrete Kompromisse in Ihrem Fall besprechen möchten, ist es ein Gespräch wert. Hier im Blog gibt es weitere Artikel über Experimente, kontinuierliche Bereitstellung und digitale Produktarchitektur, die dabei helfen können, ein vollständiges Bild zu zeichnen.