Forem: Domenico Giordano

Feature Flags Pricing Comparison 2026: Stop Paying Per Seat

Domenico Giordano — Fri, 03 Apr 2026 12:55:17 +0000

I recently spent a weekend calculating the actual cost of feature flags across every major platform. The difference between the cheapest and most expensive option for the same workload? Over 100x. Here's the full breakdown so you don't have to do the math yourself.

The Enterprise Pricing Problem

Feature flags pricing has become absurdly complex. The core concept is simple — a conditional check that's controlled remotely — yet the industry has converged on pricing models that charge five or six figures per year for what is fundamentally a key-value store with targeting rules.

LaunchDarkly charges per Monthly Active User (MAU). Statsig charges per event. Optimizely bundles feature flags into a full experimentation platform you might not need. For a team of 10 developers with a growing product, the annual cost of feature flags can exceed what you pay for your entire cloud infrastructure.

This isn't sustainable. And the market is responding — new tools with transparent, predictable pricing are gaining traction precisely because developers are tired of "contact sales" being the only way to find out what something costs.

Feature Flags Pricing Models Explained

There are four main pricing models in the feature flags market:

Per Seat (Per Developer)

You pay for each team member who accesses the dashboard. Simple to understand, but it creates a perverse incentive: teams limit who can manage flags, which slows down the release process.

Who uses it: GrowthBook, some Flagsmith plans

Per MAU (Monthly Active Users)

You pay based on how many unique users evaluate flags in your application. This punishes success — the more users you acquire, the more you pay for feature flags, even if your flag usage stays constant.

Who uses it: LaunchDarkly, Statsig

Per Config Fetch / Event

You pay per API call or flag evaluation. More predictable than MAU, but can still surprise you if you increase polling frequency or add more clients.

Who uses it: ConfigCat (config fetches)

Flat Tier (Per Request Bands)

You pick a plan based on request volume. The price is fixed within each tier, so you know exactly what you'll pay. No surprises when you add users, team members, or flags.

Who uses it: Rollgate

Feature Flags Pricing Comparison Table

	Rollgate	LaunchDarkly	Flagsmith	ConfigCat	GrowthBook
Free tier	500K req/mo, 3 projects, unlimited flags	Limited trial	50K req/mo	10 flags	Free (self-hosted)
Entry plan	€39/mo (Starter)	~$700/mo (est.)	~$45/mo	~$84/mo	$99/mo
Mid plan	€99/mo (Pro)	Custom quote	~$125/mo	Custom	$199/mo
Enterprise	€299/mo (Growth)	$25K-150K/yr	Custom	Custom	Custom
Pricing unit	SDK requests	MAU	Requests + seats	Config fetches	Seats
Price scales with	API traffic	User growth	Traffic + team size	Polling frequency	Team size

Disclaimer: Competitor pricing changes frequently. The figures above are estimates based on publicly available information as of March 2026. Always check each vendor's pricing page for current rates.

What's Included at Each Rollgate Tier

Feature	Free	Starter (€39-45/mo)	Pro (€99-119/mo)	Growth (€299-349/mo)
SDK requests/mo	500K	1M	3M	12M
Flag evaluations/mo	5M	10M	30M	120M
Projects	3	5	10	Unlimited
Flags	Unlimited	Unlimited	Unlimited	Unlimited
Environments	3	5	Unlimited	Unlimited
Team members	3	5	15	50
SSE connections	1	25	100	500
Audit log retention	3 days	14 days	90 days	1 year
Scheduled changes	--	Yes	Yes	Yes
1-click rollback	--	Yes	Yes	Yes
RBAC	--	--	Yes	Yes
SLA	--	--	--	99.9%

The annual billing option saves roughly 15-18% on each paid plan.

The Real Cost: A 10-Developer Team with 2M Requests/Month

Let's make this concrete. Your team:

10 developers with dashboard access
50,000 Monthly Active Users
2 million SDK requests per month (polling every 30 seconds across web + mobile)
3 environments (dev, staging, production)
15 active feature flags

Rollgate: €99/month (Pro)

The Pro plan covers 3M requests/month, 10 projects, 15 team members, and unlimited flags. All environments included. Scheduled changes and rollback included.

Annual: €99 x 12 = €1,188/year (or €1,068 with annual billing)

LaunchDarkly: Estimated $8,000-12,000/month

LaunchDarkly prices by MAU. At 50K MAU, you're well past the starter tier. Enterprise contracts typically start at $25K/year for small teams and scale significantly with MAU growth. With 50K MAU, expect quotes in the $100K-150K/year range.

Annual: $96,000-$150,000/year (estimated, check their sales team for exact pricing)

Flagsmith: Estimated $125-250/month

Flagsmith's cloud pricing includes per-seat and per-request components. For 10 seats and 2M requests, expect mid-tier pricing.

Annual: ~$1,500-$3,000/year (estimated)

ConfigCat: Estimated $150-300/month

ConfigCat charges per config fetch. With 2M requests/month and 10 team members, you'll likely need a mid-to-high tier plan.

Annual: ~$1,800-$3,600/year (estimated)

GrowthBook: $199/month (Pro)

GrowthBook charges per seat. The Pro plan at $199/month covers up to 20 seats with premium features.

Annual: $2,388/year

Cost Summary

Tool	Estimated Annual Cost	Cost vs Rollgate
Rollgate	~€1,100/year	--
Flagsmith	~$1,500-3,000/year	1.4-2.7x
ConfigCat	~$1,800-3,600/year	1.6-3.3x
GrowthBook	~$2,400/year	2.2x
LaunchDarkly	~$96,000-150,000/year	87-136x

These are rough estimates for comparison purposes. Actual costs depend on your specific usage patterns, negotiated contracts, and plan selection. Rollgate's pricing is publicly listed; for other tools, check their websites or contact their sales teams.

The gap is largest with LaunchDarkly because MAU-based pricing fundamentally scales differently than request-based pricing. As your product grows from 50K to 500K users, your LaunchDarkly bill grows 10x. Your Rollgate bill stays the same — or moves one tier up if your request volume increases.

Why Request-Based Pricing Makes More Sense

MAU-based pricing charges you for users who might evaluate a flag once per session. Request-based pricing charges you for actual API usage. The difference matters because:

Your user count grows faster than your flag usage. When you go from 10K to 100K users, your feature flag evaluation patterns don't change 10x. You still have the same polling intervals, the same SDKs, the same flags. Your request volume grows, but not linearly with users — especially with local caching and SSE.

You can control request volume. Increase polling interval from 30s to 60s, and you cut requests in half. Enable SSE, and you eliminate most polling requests entirely. You can't control how many users sign up.

It's predictable. A polling client at 30s intervals generates approximately 86K requests per month. Multiply by your client count and you know your tier. With MAU pricing, a viral marketing campaign can triple your bill overnight.

Here's a typical integration — the SDK handles polling and caching automatically:

import { RollgateProvider, useFlag } from '@rollgate/sdk-react';

function App() {
  return (
    <RollgateProvider
      apiKey="rg_client_your_key"
      options={{
        pollingInterval: 30000, // 30s default
        enableSSE: true,        // real-time updates, reduces polling
      }}
    >
      <FeatureFlaggedApp />
    </RollgateProvider>
  );
}

function FeatureFlaggedApp() {
  const showNewUI = useFlag('redesigned-ui', false);
  const maxUploadSize = useFlag('max-upload-mb', 10);

  return (
    <div>
      {showNewUI ? <NewUI maxUpload={maxUploadSize} /> : <CurrentUI />}
    </div>
  );
}

One SDK connection, one polling interval, all flags cached locally. Whether you have 1,000 or 1,000,000 users, each client makes the same number of requests.

How to Calculate Your Feature Flags Cost

Before you commit to a tool, estimate your actual usage:

Count your SDK clients: How many servers, browser instances, or mobile apps will connect? Each one polls independently.
Determine your polling interval: Default is usually 30 seconds. At 30s, one client = ~86K requests/month. At 60s = ~43K. With SSE, polling is minimal.
Multiply: clients x requests_per_client = monthly_requests
Pick the tier that covers your volume.

Example: You have 3 API servers + 1 web frontend. With 30s polling, that's 4 x 86K = 344K requests/month. Rollgate Free (500K) covers this. You pay nothing.

Scaling example: Your product grows to 20 API servers + 5 frontend instances. That's 25 x 86K = 2.15M requests/month. Rollgate Pro (3M) at €99/month covers this. On LaunchDarkly, the cost would depend on how many end users those 20 servers handle — potentially tens of thousands of dollars per month.

Stop Overpaying for Feature Flags

Feature flags should be a line item, not a line of the budget. The core technology — flag evaluation, targeting rules, SDK communication — isn't complex enough to justify enterprise pricing for most teams.

Rollgate offers transparent, flat-tier pricing with no surprises. The free tier (500K requests/month) is generous enough for small teams and side projects. Paid plans start at €39/month and include scheduled releases and instant rollback.

Check the full pricing at rollgate.io or try the live demo.

For more context on choosing a feature flag tool, see our LaunchDarkly alternative comparison and gradual rollout strategies.

I'm building Rollgate, a feature flag platform for developers. If you have questions about feature flags, drop them in the comments — happy to help!

Feature Flags vs Feature Branches: When to Use Each

Domenico Giordano — Fri, 03 Apr 2026 12:55:16 +0000

I used to think feature branches were the only way to manage releases. Then I joined a team that used feature flags with trunk-based development, and I never looked back. Turns out, the "feature flags vs feature branches" debate is a false dichotomy — here's how to think about it.

The False Dichotomy

Developers often frame feature flags vs feature branches as an either/or choice. In reality, they solve different problems and work best together. Feature branches manage code integration. Feature flags manage feature release. Understanding this distinction is key to a healthy deployment workflow.

Whether you call them feature flags, feature toggles, or feature switches, the core idea is the same: decouple deployment from release. And whether you use Git Flow, GitHub Flow, or trunk-based development, branches are about managing code changes. Once you internalize that these tools operate at different layers, the "feature branch vs feature toggle" debate dissolves.

Feature Flags vs Feature Toggles: Are They the Same?

Before we go deeper, let's clear up a common source of confusion. You'll see "feature flags," "feature toggles," "feature switches," and "feature gates" used across blog posts, documentation, and conference talks. They all refer to the same concept: a conditional check in your code that controls whether a piece of functionality is active.

Martin Fowler popularized the term "feature toggle" in his 2010 article. The term "feature flag" gained traction in the DevOps community and is more common today, especially in SaaS tooling. Some teams use "toggle" for simple on/off switches and "flag" when targeting rules and percentage rollouts are involved, but this distinction isn't universal.

Throughout this article, we use "feature flag" and "feature toggle" interchangeably. If you've been searching for "feature branch vs feature toggle," you're in the right place.

For a complete introduction to the concept, see our guide on what feature flags are and how they work.

What Are Feature Branches?

Feature branches are a Git workflow where each new feature is developed on a separate branch. When the feature is ready, the branch is merged into the main branch (usually main or develop).

git checkout -b feature/new-payment-flow
# ... work on the feature ...
git push origin feature/new-payment-flow
# Create a pull request, get reviews, merge

Advantages of Feature Branches

Isolation: Changes are isolated until the branch is merged
Code review: Pull requests enable structured review
CI checks: Automated tests run on each branch before merging
Familiar: Every developer knows Git branching

Problems with Feature Branches

Long-lived branches diverge: The longer a branch lives, the harder the merge. Conflicts accumulate, and integration becomes painful.
Delayed feedback: You don't know if your feature works in production until it's merged and deployed.
All-or-nothing releases: Merging a feature branch means releasing it. There's no way to deploy the code but hide the feature.
Merge conflicts: Large branches touching many files create merge hell, especially on active codebases.

The Hidden Cost of Long-Lived Feature Branches

The problems above aren't theoretical. Long-lived feature branches impose real, measurable costs on engineering teams.

Merge Conflict Escalation

Research from DORA (DevOps Research and Assessment) consistently shows that teams practicing trunk-based development with short-lived branches ship faster and with fewer failures. The reason is compounding: every day a branch stays open, the probability of a merge conflict increases non-linearly. A branch open for 2 days might have a 10% chance of conflict. At 2 weeks, that number can exceed 80%, depending on team size and codebase activity.

Context Switching Tax

When a developer opens a PR for a 3-week-old branch and receives 47 review comments, the original context is gone. The developer has moved on to other work. Rebuilding mental context to address feedback on stale code is one of the most expensive activities in software development. Studies suggest context switching can cost 20-25 minutes per interruption.

Integration Risk Compounds

Consider a team of 6 developers, each working on a separate feature branch for 2 weeks. When all six branches merge in the same sprint, the integration surface is enormous. Features that worked in isolation break when combined. This "merge day" anti-pattern is why many teams dread release weeks.

Delayed Bug Discovery

A bug introduced on a feature branch stays hidden until merge. If your branch diverged from main 10 days ago, the bug has had 10 days to become entangled with other changes. Compare this to trunk-based development where the same bug would surface within hours, when it's cheap to fix and the context is fresh.

The alternative is clear: keep branches short (hours to days, not weeks) and use feature flags for long-running features that span multiple merges.

What Are Feature Flags?

Feature flags wrap new functionality in a conditional check. The code is deployed to production but only activated when the flag is enabled. This decouples deployment from release.

import { useFlag } from '@rollgate/sdk-react';

function PaymentPage({ user }) {
  const showNewPayment = useFlag('new-payment-flow');

  if (showNewPayment) {
    return <NewPaymentFlow />;
  }
  return <CurrentPaymentFlow />;
}

On the backend, the same pattern works in any language. Here's Go:

package main

import (
    "net/http"
    rollgate "github.com/rollgate/sdk-go"
)

func paymentHandler(w http.ResponseWriter, r *http.Request) {
    user := getUserFromContext(r)
    ctx := rollgate.NewContext(rollgate.WithUserID(user.ID))

    if rollgate.IsEnabled("new-payment-flow", ctx) {
        handleNewPaymentFlow(w, r)
        return
    }
    handleCurrentPaymentFlow(w, r)
}

Advantages of Feature Flags

Deploy anytime: Code goes to production even if the feature isn't ready for users
Gradual rollout: Enable for 1% of users, then 10%, then 100% — learn more in our gradual rollouts guide
Instant rollback: Disable a flag in seconds, no redeployment needed
Targeting: Show features to specific users, teams, or segments
Trunk-based development: Everyone commits to main, reducing merge conflicts
Scheduled releases: Combine flags with time-based rules for scheduled feature releases

Problems with Feature Flags

Code complexity: Two code paths mean more logic to maintain
Stale flags: Unused flags accumulate as technical debt
Testing surface: You need to test both flag states
Requires discipline: Flags need to be cleaned up after full rollout

How Companies Like Google and Netflix Use Trunk-Based Development

Trunk-based development with feature flags isn't a niche practice. It's how the world's most productive engineering organizations ship software.

Google

Google operates one of the largest monorepos in existence, with over 80,000 engineers committing to a single repository. Long-lived feature branches would be impossible at this scale. Instead, Google uses trunk-based development where all engineers commit to head. Incomplete features are guarded by flags (internally called "experiments" or "flags") that keep them invisible until ready. This approach allows Google to make over 60,000 commits per day without breaking the build.

Netflix

Netflix deploys hundreds of times per day across its microservices architecture. Their engineering blog describes how every feature is wrapped in a flag before reaching production. This allows them to test new recommendation algorithms, UI changes, and encoding pipelines with real traffic at controlled percentages. When a new video player feature caused buffering issues in 2019, they disabled it for all users in under 30 seconds — something a rollback deployment would have taken minutes or longer.

Meta (Facebook)

Meta ships code to production twice daily using a system called Gatekeeper, their internal feature flag platform. Every new feature — from News Feed ranking changes to Messenger updates — goes through a flag-controlled rollout. Engineers can target by geography, device type, employee status, or custom segments. This system handles billions of flag evaluations per day.

Spotify

Spotify uses feature flags extensively for their "controlled rollout" process. New features are first exposed to internal employees ("dogfooding"), then to a small percentage of users in a single market, then expanded globally. This layered approach catches issues at each stage before they reach the full 500+ million user base.

The pattern is consistent across these organizations: short-lived branches for code management, feature flags for release management.

When to Use Feature Branches

Feature branches are the right choice when:

Short-lived work (1-3 days): Bug fixes, small features, refactors that can be reviewed and merged quickly
Code review is essential: You want a structured PR workflow with approvals
No production risk: The change doesn't need gradual rollout or targeting
Open-source contributions: External contributors need isolated branches for PRs

When to Use Feature Flags

Feature flags are the right choice when:

Gradual rollout needed: You want to release to a percentage of users first
Long-running features: Work that spans multiple sprints or weeks
Production testing: You need to verify behavior in production before full release
Kill switch required: The feature could impact system stability
User targeting: Different users should see different experiences
A/B testing: You're running experiments between variants

The Best Approach: Use Both

The most effective teams use short-lived feature branches combined with feature flags:

Create a short-lived branch for a small piece of work (1-2 days)
Wrap new UI or behavior behind a feature flag
Merge to main quickly — the flag is off, so nothing changes for users
Deploy to production — the code is there but hidden
Enable the flag gradually when the full feature is ready
Clean up the flag once the feature is at 100%

This gives you the best of both worlds:

Short branches avoid merge conflicts and integration pain
Feature flags give you release control without deployment pressure
Trunk-based development keeps the main branch always deployable
Continuous delivery becomes natural, not scary

Trunk-Based Development with Feature Flags

Trunk-based development (TBD) is the practice of keeping branches short (hours to days) and merging to main frequently. Feature flags are what make TBD safe for large features:

Day 1: Merge backend API behind flag -> Deploy -> Flag off
Day 2: Merge UI component behind flag -> Deploy -> Flag off
Day 3: Merge integration tests -> Deploy -> Flag off
Day 4: Enable flag for internal team -> Test in production
Day 5: Rollout to 10% -> Monitor metrics
Day 7: Rollout to 100% -> Remove flag

Each merge is small, easy to review, and safe to deploy. The feature grows incrementally in production without affecting users until you decide it's ready.

Here's a concrete Node.js example of a flag-guarded API endpoint that you can merge to main safely on Day 1:

import Rollgate from '@rollgate/sdk-node';

const rollgate = new Rollgate({
  apiKey: process.env.ROLLGATE_SERVER_KEY,
});

app.post('/api/checkout', async (req, res) => {
  const user = req.user;
  const useNewCheckout = await rollgate.isEnabled('new-checkout-flow', {
    userId: user.id,
    attributes: { plan: user.plan, country: user.country },
  });

  if (useNewCheckout) {
    return handleNewCheckout(req, res);
  }
  return handleLegacyCheckout(req, res);
});

Migration Guide: From Feature Branches to Feature Flags

If your team currently relies on long-lived feature branches, migrating to a flag-based workflow doesn't have to happen overnight. Here's a practical step-by-step approach.

Step 1: Pick One Feature as a Pilot

Don't try to convert your entire workflow at once. Choose a medium-complexity feature that's about to start development. This gives you a real scenario to learn from without risking critical work.

Step 2: Set Up Your Flag Service

You need a way to create and manage flags. You can start with environment variables or a config file, but a dedicated service like Rollgate gives you a dashboard, targeting rules, and audit logs from day one.

Step 3: Adopt the Branch + Flag Pattern

Instead of a single long-lived feature/new-dashboard branch, break the work into small PRs (each 1-2 days):

# PR 1: Add the flag and the empty shell
git checkout -b add-dashboard-flag
# Create the flag in Rollgate, add the conditional check
# Merge to main -- flag is OFF, no user impact

# PR 2: Build the data layer
git checkout -b dashboard-data-layer
# Add API endpoints behind the flag
# Merge to main -- still invisible to users

# PR 3: Build the UI
git checkout -b dashboard-ui
# Add components behind the flag
# Merge to main -- still invisible

# Ready? Enable the flag for your team first, then gradually roll out.

Step 4: Establish Flag Hygiene Rules

Agree on team conventions before flags accumulate:

Naming: Use a consistent pattern like feature.dashboard-v2 or release.new-checkout
Ownership: Every flag has an owner responsible for cleanup
TTL: Set an expected removal date when creating the flag
Cleanup sprint: Dedicate time each sprint to removing fully-rolled-out flags

Step 5: Expand to the Full Team

Once the pilot is complete, share lessons learned and repeat the pattern. Most teams report that within 2-3 sprints, the flag-based workflow feels natural and the benefits are obvious: fewer merge conflicts, faster releases, and fewer incidents.

Real-World Comparison

Aspect	Feature Branches Only	Feature Branches + Flags
Branch lifetime	Days to weeks	Hours to days
Merge conflicts	Frequent	Rare
Release control	None (merge = release)	Full (gradual, targeted)
Rollback speed	Minutes (redeploy)	Seconds (toggle flag)
Production testing	Not possible	Easy
A/B testing	Not possible	Built-in

FAQ

Can I use feature flags without a feature flag service?

Yes. The simplest feature flag is an if statement checking an environment variable:

if (process.env.ENABLE_NEW_DASHBOARD === 'true') {
  showNewDashboard();
}

This works for basic use cases, but it has limitations. Changing a flag requires redeployment, there's no gradual rollout, no user targeting, and no audit trail. As your team grows and you manage more flags, a dedicated service pays for itself in reduced deployment risk and developer time. Most teams start with env vars and upgrade to a flag service once they hit 5-10 flags.

Do feature flags slow down my application?

A well-implemented feature flag adds negligible overhead. The flag evaluation itself is a simple conditional check — microseconds at most. Modern SDKs cache flag values locally and sync in the background, so evaluations don't make network requests on the hot path.

In Go, a cached flag evaluation looks like this:

// This reads from local cache -- no network call
enabled := rollgate.IsEnabled("new-feature", ctx)
// Typical evaluation time: <1 microsecond

The performance concern is valid only if your implementation makes a remote API call on every evaluation — which no production-grade SDK does.

How do I handle database migrations with feature flags?

Database migrations are one of the trickier aspects of flag-based development. The key principle is: your database schema must support both code paths simultaneously.

Here's a practical approach:

Additive migrations only: Add new columns or tables, never remove or rename existing ones while the flag is active
Dual-write pattern: When the flag is on, write data to both the old and new schema. When off, write only to the old schema
Backfill after full rollout: Once the flag is at 100% and removed, run a migration to clean up the old schema

async function saveOrder(order: Order) {
  // Always write to the existing table
  await db.orders.insert(order);

  // When the flag is on, also write to the new normalized tables
  if (await rollgate.isEnabled('normalized-orders')) {
    await db.orderHeaders.insert(order.header);
    await db.orderLines.insertMany(order.lines);
  }
}

This approach avoids the scenario where you roll back a flag and lose access to data written in a new format. Both code paths can read from the same source during the transition.

Conclusion

Feature branches and feature flags aren't competing approaches — they're complementary tools. Use feature branches for code management and review. Use feature flags for release management and safety. Together, they enable fast, safe, continuous delivery.

If you're still doing long-lived feature branches with big-bang releases, consider adding feature flags to your workflow. Start with one flag on your next feature and experience the difference. The teams at Google, Netflix, and Spotify didn't adopt this pattern because it was trendy — they adopted it because it works.

Get started with Rollgate — free tier, no credit card required.

I'm building Rollgate, a feature flag platform for developers. If you have questions about feature flags, drop them in the comments — happy to help!

How I Built a Feature Flags SaaS as a Solo Developer

Domenico Giordano — Fri, 03 Apr 2026 12:55:15 +0000

I spent a year building a feature flags SaaS from scratch. No co-founder, no VC, just me, Go, and a Hetzner VPS. This post covers the full technical journey — the stack I chose, the features I built, the mistakes I made, and the real numbers behind a solo SaaS. If you're thinking about building your own developer tool, I hope this helps.

How I Built Rollgate: From Side Project to Feature Flags SaaS

Over the past year, I built Rollgate, a SaaS platform for feature flag management. The goal was simple: offer the same capabilities as LaunchDarkly — gradual rollouts, user targeting, A/B testing, kill switches — without the $70k/year enterprise price tag.

In this article, I share the technical journey: architectural decisions, all the features I implemented, mistakes made, and the real numbers behind a SaaS built by a single developer.

The Problem

Anyone who has worked in a development team knows the situation: you want to release a feature, but you're not sure it works for all users. Traditional deployment is a binary event — either the feature is live for everyone, or for no one.

Feature flags solve this by separating deployment from release. You can deploy code to production and enable it gradually: first 1% of users, then 5%, then 25%, and so on. If something goes wrong, you turn off the flag in a second — no rollback, no hotfix, no downtime.

Tools like LaunchDarkly do exactly this, but cost $25k to $150k per year. For a startup or mid-size team, that's prohibitive. I thought: can I build something equivalent and offer it at a fraction of the price?

Choosing the Tech Stack

The first fundamental decision was the stack. I had two non-negotiable requirements: low latency (feature flags are evaluated on every request) and operational simplicity (fewer moving parts means fewer things to break).

Backend: Go

I chose Go for the backend API for three reasons:

Performance — A flag evaluation must happen in microseconds. Go compiles to native binary, has no significant GC pauses, and handles thousands of concurrent connections with goroutines.
Simple deployment — A single static binary. No runtime, no dependencies. The final Docker image weighs 20MB.
Excellent stdlib — HTTP server, JSON encoding, crypto, testing — all built-in. Fewer external dependencies means less surface area for bugs.

The router is Chi, lightweight and net/http-compatible. No heavy frameworks — I prefer composition over convention.

Frontend: Next.js

For the dashboard, I chose Next.js with React and Tailwind CSS. It provides SSR/SSG for marketing pages (SEO), API routes for backend proxying, and a smooth dev experience.

Database: PostgreSQL + Redis

PostgreSQL for persistence: JSONB for flag metadata, partial indexes, LISTEN/NOTIFY for cache invalidation. 29 tables, 67 indexes, 29 foreign keys.

Redis as cache layer for flag evaluations. When an SDK asks "is flag X enabled for user Y?", Redis serves the answer in milliseconds, updated in real-time via pub/sub.

Rollgate's Feature Set

Rollgate isn't a simple toggle on/off. I implemented a complete set of features covering the entire software release lifecycle.

Feature Flags with Multiple Types

Flags support four value types:

Boolean — Classic on/off. Perfect for kill switches and feature toggles.
String — Returns text. Ideal for A/B testing ("variant-a", "variant-b") or dynamic messages.
Number — Returns a numeric value. Useful for configuring limits, percentages, or algorithm parameters.
JSON — Returns a structured object. For complex configurations like layouts, plan-specific feature sets, or business rules.

Gradual Rollouts

Percentage rollout enables a flag for a specific percentage of users. Distribution uses consistent hashing (MurmurHash3) on the user ID, so the same user always gets the same result without saving state:

hash = MurmurHash3(flagKey + userId) % 10000
isEnabled = hash < rolloutPercentage * 100

Precision to 0.01%. You can go from 1% to 5% to 25% to 100% gradually, monitoring metrics at each step.

User Targeting and Segments

Targeting enables flags for specific user groups based on attributes:

User attributes — Email, plan, country, app version, any custom attribute
Operators — equals, contains, startsWith, endsWith, regex, in, greaterThan, lessThan
Reusable segments — Define "Beta Users" or "Enterprise Customers" once, use in all flags
Combined rules — AND/OR logic across multiple conditions

Kill Switches

The kill switch is the most critical production feature. When something goes wrong — a bug, a performance issue, a third-party integration down — you need to disable a feature instantly.

In Rollgate, every flag has a toggle that takes effect in seconds via real-time SSE propagation. No deploy needed, no server access required, you don't even need to be a developer. A product manager can kill a feature from the dashboard on their phone.

I've seen enterprise teams take 30-45 minutes for a traditional rollback (revert commit, CI, deploy, verify). With a kill switch, it's 2 seconds. During a production incident, those 30 minutes can cost thousands in lost revenue.

Scheduled Changes

Scheduled changes let you program flag modifications for a specific date and time:

Coordinated launch — "Enable the new feature Friday at 2 PM when marketing publishes the blog post"
Temporary promotions — "Enable the Black Friday banner from Friday to Monday"
Automatic progressive rollout — "1% Monday, 10% Wednesday, 50% Friday, 100% next Monday"
Feature sunset — "Disable the old API on April 1st"

Each scheduled change appears in the flag's timeline with pending/executed/cancelled status. A server-side cron job checks every minute for changes to apply.

Instant Rollback

Every flag modification is saved in history with timestamp, author, and complete state snapshot. Rollback restores the exact flag state at a previous point — not just the value, but also targeting rules, percentages, and scheduled changes.

It's different from a simple "undo": you can go back 5 changes, or to a specific dated version. The audit log tracks who did what and when.

A/B Testing

String variant flags enable native A/B testing. Instead of simple true/false, the flag returns a variant ("control", "variant-a", "variant-b") with configurable percentage distribution.

Evaluation tracking records which variant was served to each user, with timestamp and context. This allows correlating variants with business metrics in your preferred analytics tool.

I deliberately didn't build an integrated statistical engine — I prefer teams use their existing analytics tools rather than creating another data silo.

Multi-Environment

Every project has separate environments: development, staging, production (and as many as you want). Flags are independent per environment — you can have a flag active in staging but off in production.

Each environment has its own API keys (server and client), targeting rules, and history. This prevents the classic "oops, I modified the production flag thinking it was staging" mistake.

Audit Log

Every platform action is recorded in an immutable audit log: who created/modified/deleted a flag, what changed (before/after diff), when (precise timestamp), from which IP and user agent.

Retention varies by plan: 3 days (Free), 14 days (Starter), 90 days (Pro), 1 year (Growth). For compliance and debugging, having a complete trace is essential.

Webhooks

Webhooks notify external systems when a flag changes. Every create, update, or delete sends an HTTP POST to configured URLs with the full event payload.

Use cases: notify Slack when a production flag changes, trigger a deploy, update monitoring, sync with project management tools. Webhooks have automatic retry with exponential backoff and delivery logging.

Analytics and Usage Tracking

Rollgate tracks flag evaluations in real-time: how many times evaluated, unique users, true/false distribution, trends over time. Usage limits are per plan: 500K requests/month (Free), 1M (Starter), 3M (Pro), 12M (Growth).

13 SDKs

I built 13 SDKs covering all major languages and frameworks:

JavaScript/TypeScript — sdk-core, sdk-node, sdk-browser, sdk-react, sdk-vue, sdk-angular, sdk-svelte
Mobile — sdk-react-native, sdk-flutter
Backend — sdk-go, sdk-java, sdk-python, sdk-dotnet

All SDKs share the same features: local cache, circuit breaker, retry with backoff, event buffering, and real-time SSE updates. If the server is down, SDKs continue working with cached values.

import { RollgateProvider, useFlag } from '@rollgate/sdk-react';

function App() {
  return (
    <RollgateProvider apiKey="rg_client_your_key">
      <Dashboard />
    </RollgateProvider>
  );
}

function Dashboard() {
  const showNewFeature = useFlag('new-dashboard', false);

  return showNewFeature ? <NewDashboard /> : <LegacyDashboard />;
}

System Architecture

Client SDK -> API Server (Go) -> Redis Cache -> PostgreSQL
              ^
          SSE Connection (real-time updates)

Flag evaluation happens in ~200us. P99 latency is under one millisecond. The system supports tens of thousands of simultaneous SSE connections.

Technical Challenges

Race Conditions on Updates

When multiple users modify the same flag simultaneously, I use optimistic locking with a version counter. If someone else modified the flag in the meantime, the operation returns 409 Conflict.

Circuit Breaker in SDKs

If the API server is down, SDKs must not crash the host app. The circuit breaker has three states (Closed, Open, Half-Open) with exponential retry and request deduplication.

SEO for a SaaS App

I separated marketing and dashboard with a domain split: rollgate.io for SEO pages (Server Components) and app.rollgate.io for the authenticated dashboard.

Resilience and Monitoring

Daily backups — PostgreSQL dump every night to a geographically separate server
Monitoring — Prometheus + Grafana + Alertmanager with real-time alerts
Health checks — Automated verification of API, Web, DB, Redis every 60 seconds
Disaster recovery — Automated script rebuilds the entire stack in ~20 minutes
SDK resilience — Local cache + circuit breaker = works even offline

The Numbers

Metric	Value
Go files (non-test)	147
TypeScript/TSX files	168
API endpoints	114
DB tables	29
Total tests	~850
Published SDKs	13
Codebase score	7.86/10

What I Learned

1. Simplicity Wins

Kubernetes in production? No, Docker Compose is enough. Microservices? No, a modular monolith is simpler. Every added complexity has a maintenance cost that must justify its weight.

2. Tests Save Lives

With ~850 tests, I can refactor with confidence. CI runs everything on every PR and blocks deployment if something fails.

3. Billing Is Harder Than the Product

Paddle for payments was surprisingly complex: webhooks, subscription lifecycle, prorating, dunning, tax handling. Use a payment provider that handles everything (Paddle, Lemon Squeezy) rather than raw Stripe.

4. SEO Requires Constant Attention

If Google doesn't index you, nobody will find you. I spent weeks on SSR, JSON-LD, sitemaps, meta tags. It never ends.

5. Building Solo Is Sustainable (With Limits)

Code is the easy part — finding users is the real challenge. Marketing, support, and growth require different skills.

The Market: Competitors and Positioning

The feature flags market is dominated by a few players with aggressive enterprise pricing:

Platform	Pricing	Strengths	Limitations
LaunchDarkly	From $833/mo	Market leader, enterprise-ready, vast integrations	Prohibitive for startups, excessive complexity
Flagsmith	From $45/mo	Free self-hosted, API-first	Less polished UI, fewer SDKs
Unleash	From $80/mo	Mature self-hosted, good docs	Complex setup, dated UI
PostHog	Usage-based	Complete suite (analytics + flags), open-source	Flags aren't the focus, overhead
Rollgate	Free -> €45/mo	Accessible pricing, 13 SDKs, 5-min setup	New to market, growing community

Choosing the Pricing Model

Pricing was one of the hardest decisions. I studied every competitor and identified three approaches:

Per-seat (LaunchDarkly) — Scales with team size, penalizes large companies. $70k/year for 50 developers isn't unusual.
Usage-based (PostHog) — Scales with traffic, unpredictable for budgeting. Can explode with traffic spikes.
Fixed tiers (Rollgate) — Predictable pricing, scales by features and limits. Customers know exactly what they pay.

I chose fixed tiers because cost predictability is essential for startups and SMBs. The four plans:

Plan	Monthly	Annually	Requests/mo	Team	Target
Free	€0	€0	500K	3 members	Side projects, MVPs
Starter	€45/mo	€39/mo	1M	5 members	Early-stage startups
Pro	€119/mo	€99/mo	3M	15 members	Growing teams
Growth	€349/mo	€299/mo	12M	50 members	Scale-ups, high traffic

The free tier is generous by design: 500K requests/month is enough for an app with thousands of active users. The goal is to lower the entry barrier — if a developer tries Rollgate and it works, upgrading to Starter as the project grows is natural.

Why Not Open Source?

I evaluated the open-core model (free core, paid enterprise features), but it requires an active community to work. For a solo project, the risk is giving everything away for free without monetizing. I opted for a SaaS model with a generous free tier, with plans to release a self-hosted version under BSL (Business Source License) — the same approach used by HashiCorp and Sentry.

What's Next

Rollgate is live at rollgate.io with a generous free tier (500K requests/month). Next up: advanced A/B testing with auto-winner, teams with SSO, self-hosted version, and complete OpenAPI spec.

If you're interested in the project or have questions about building a SaaS solo, I'd love to hear from you in the comments.

I'm building Rollgate, a feature flag platform for developers. If you have questions about feature flags, drop them in the comments — happy to help!

The Best LaunchDarkly Alternative in 2026: Rollgate vs the Rest

Domenico Giordano — Fri, 03 Apr 2026 12:55:14 +0000

Let's be real: LaunchDarkly is a great product, but the pricing is wild. I was paying more for feature flags than for my entire cloud infrastructure. So I started looking at alternatives, and eventually built one. Here's an honest comparison of what's out there in 2026.

Why Teams Are Looking for a LaunchDarkly Alternative

If you're searching for a LaunchDarkly alternative, you're not alone. LaunchDarkly is the category leader in feature flags, but it's also the most expensive option by a wide margin. Enterprise contracts typically range from $25,000 to $150,000 per year, and pricing scales with Monthly Active Users (MAU) — a metric that punishes success. The more users you have, the more you pay, even if your feature flag usage stays the same.

For teams with 10 developers and a growing product, the math doesn't work. You're paying enterprise pricing for what is fundamentally a configuration service: a key-value store with targeting rules and an SDK.

That's why more teams are evaluating alternatives to LaunchDarkly that offer the same core capabilities — feature flags, targeting, rollback — without the unpredictable pricing model.

What to Look for in a LaunchDarkly Alternative

Not all feature flag tools are created equal. Before you switch, make sure the alternative checks these boxes:

Transparent, Predictable Pricing

No "contact sales" as the only option. No MAU-based pricing that explodes when your product grows. You should know exactly what you'll pay before you sign up. For a deeper breakdown of how different vendors charge, see our feature flags pricing comparison.

Multi-Platform SDK Support

Your stack isn't just React. You need SDKs for your backend (Node.js, Go, Python, Java), your frontend (React, Vue, Angular, Svelte), and your mobile apps (React Native, Flutter). The SDKs should include circuit breakers, retry logic, and local caching out of the box.

Scheduled Releases

The ability to schedule a flag change for a specific date and time — without writing cron jobs or staying awake at 3am. This is a feature that LaunchDarkly offers only on higher tiers, and many alternatives don't offer at all.

Instant Rollback

When something breaks in production, you need to revert a flag to its previous state in one click. Not "create a new flag version," not "redeploy" — one click, instant rollback to the exact previous state.

GDPR Compliance with EU Data Residency

If you serve European users, your feature flag data should stay in Europe. LaunchDarkly's infrastructure is primarily US-based. For teams that need GDPR compliance without complex DPAs, an EU-hosted alternative is simpler.

LaunchDarkly Pricing Breakdown: Why MAU Gets Expensive

LaunchDarkly's pricing model revolves around two axes: seats (the developers who manage flags) and Monthly Active Users (the end users your application evaluates flags for). This sounds reasonable until you look at how MAU scales in practice.

Here's how it works:

Base plan cost: LaunchDarkly's Pro plan starts around $10,000/year. Enterprise plans start around $25,000/year and go well over $100,000/year depending on contract terms.
MAU tiers: Each plan includes a base MAU allotment. Once you exceed it, you pay per additional MAU block. The per-MAU overage cost varies by contract, but published estimates range from $0.01 to $0.03 per MAU.
MAU counts every unique user: Every user who triggers a flag evaluation counts, regardless of how many flags you use. If you have 100,000 active users but only 3 flags, you're still paying for 100,000 MAU.
Client-side vs server-side: Client-side SDKs report MAU automatically. Server-side SDKs can too, depending on how you pass user contexts.

The problem is that MAU correlates with product growth, not feature flag complexity. A team with 50,000 MAU and 5 flags pays far more than a team with 1,000 MAU and 200 flags — even though the second team puts more load on the system.

For startups experiencing growth, this creates budget unpredictability. You might be paying $1,000/month one quarter and $4,000/month the next, simply because your product is succeeding.

Cheaper alternatives to LaunchDarkly, like Rollgate, avoid this problem entirely by pricing on SDK requests — a metric you can control and predict.

Feature Flag Tools Compared: Rollgate vs LaunchDarkly vs Alternatives

Here's a side-by-side comparison of the major feature flag platforms in 2026:

Feature	Rollgate	LaunchDarkly	Flagsmith	ConfigCat	GrowthBook
Free tier	500K req/mo	Limited trial	50K req/mo	10 flags	Unlimited (self-hosted)
Paid plans	From €39/mo	From ~$8,333/mo (est.)	From $45/mo	From $84/mo	From $99/mo
Pricing model	Per request (flat)	Per MAU + seat	Per request + seat	Per config fetches	Per seat
SDKs	13 official	25+	18	12	8
Scheduled changes	All paid plans	Enterprise only	No	No	No
1-click rollback	All paid plans	Flag history only	Audit log	No	No
Self-hosted	Coming soon	No	Yes	No	Yes
EU data residency	Yes (Germany)	US-primary	Configurable	EU option	Self-hosted only
A/B testing	Yes (Pro+)	Yes (add-on)	No	No	Yes (core)
Real-time (SSE)	Yes	Yes	Yes	Polling only	Polling only

Note on competitor pricing: Prices change frequently. Check each vendor's website for current pricing. The estimates above are based on publicly available information as of March 2026.

Real Cost Comparison: 10K, 50K, 100K, 500K MAU

One of the biggest reasons teams look for a LaunchDarkly alternative is sticker shock at scale. Here's a realistic cost comparison across different growth stages, assuming a team of 10 developers:

MAU	Rollgate (est.)	LaunchDarkly (est.)	Flagsmith (est.)	ConfigCat (est.)	GrowthBook (est.)
10K	€39/mo	~$1,000/mo	~$45/mo	~$84/mo	~$99/mo
50K	€39-99/mo	~$2,500/mo	~$200/mo	~$200/mo	~$99/mo
100K	€99-119/mo	~$4,000/mo	~$400/mo	~$350/mo	~$99/mo
500K	€299-349/mo	~$10,000+/mo	~$1,200/mo	~$800/mo	~$200/mo

How to read this table: Rollgate prices are based on SDK requests, not MAU, so the correlation is approximate. A typical SPA polling every 30 seconds generates ~86K requests/user/month. With caching and SSE (which Rollgate supports), actual request volume is much lower. LaunchDarkly estimates are based on published pricing and community reports — actual costs depend on your contract.

The pattern is clear: at every growth tier, LaunchDarkly costs 5-30x more than alternatives. For a team at 100K MAU, the difference between Rollgate (~€99/mo) and LaunchDarkly (~$4,000/mo) is roughly $46,000/year.

That's not a rounding error — that's a senior developer's salary.

Why Rollgate Is the LaunchDarkly Alternative Built for Growing Teams

Rollgate was built by developers who got tired of paying five figures for a feature flag service. Here's what makes it different.

12 Official SDKs with Built-in Resilience

Every Rollgate SDK ships with circuit breakers, retry with exponential backoff, local caching, and graceful degradation. If the Rollgate API goes down, your flags keep working with cached values.

Here's a React example:

import { RollgateProvider, useFlag } from '@rollgate/sdk-react';

function App() {
  return (
    <RollgateProvider apiKey="rg_client_your_key">
      <Dashboard />
    </RollgateProvider>
  );
}

function Dashboard() {
  const showNewDashboard = useFlag('new-dashboard', false);

  if (showNewDashboard) {
    return <NewDashboard />;
  }
  return <LegacyDashboard />;
}

And on the backend with Node.js:

import { RollgateClient } from '@rollgate/sdk-node';

const client = new RollgateClient({
  apiKey: process.env.ROLLGATE_SERVER_KEY,
  enableSSE: true, // real-time updates
});

await client.initialize();

app.get('/api/pricing', (req, res) => {
  const newPricing = client.isEnabled('new-pricing-model', {
    id: req.user.id,
    attributes: { plan: req.user.plan, country: req.user.country }
  });

  if (newPricing) {
    return res.json(calculateNewPricing(req.user));
  }
  return res.json(calculateLegacyPricing(req.user));
});

Scheduled Changes as a First-Class Feature

Unlike LaunchDarkly where scheduling is buried in enterprise plans, Rollgate makes scheduled changes available on every paid plan. Set enable_at and disable_at directly from the dashboard or API:

# Schedule a flag to enable at midnight UTC on launch day
curl -X POST https://api.rollgate.io/api/v1/projects/:id/flags/:flagId/schedule \
  -H "Authorization: Bearer $ROLLGATE_SERVER_KEY" \
  -d '{"enable_at": "2026-04-01T00:00:00Z"}'

You can also schedule a maintenance window — enable at midnight, disable at 6am — all from the dashboard without writing any code.

Gradual Rollouts Without Complexity

Rollgate supports percentage-based gradual rollouts on every plan. Roll a feature out to 5% of users, monitor your metrics, then ramp to 25%, 50%, and 100%. If something goes wrong at any stage, roll back instantly to the previous percentage.

LaunchDarkly supports this too, but it's part of their premium pricing. With Rollgate, gradual rollouts are available starting from the free tier.

Flat, Predictable Pricing

Rollgate pricing is based on SDK requests, not MAU. You know exactly what you'll pay:

Plan	Monthly	SDK Requests	Projects	Team Members
Free	€0	500K/mo	3	3
Starter	€39-45/mo	1M/mo	5	5
Pro	€99-119/mo	3M/mo	10	15
Growth	€299-349/mo	12M/mo	Unlimited	50

A team polling every 30 seconds generates about 86K SDK requests per month per client. Even at scale, Rollgate costs a fraction of LaunchDarkly.

What LaunchDarkly Does Better

Let's be honest — LaunchDarkly is the market leader for a reason. If you're evaluating alternatives, you should know where LaunchDarkly genuinely excels:

Mature Ecosystem and Integrations

LaunchDarkly has 25+ official SDKs covering virtually every language and framework. They also have deep integrations with tools like Jira, Slack, Datadog, Terraform, and dozens more. If you need a Haskell SDK or a Terraform provider on day one, LaunchDarkly has it.

Rollgate covers the 12 most-used platforms, which handles 95%+ of teams. But if your stack includes niche languages, verify SDK availability first.

Enterprise Features

LaunchDarkly offers features built for large enterprise organizations: approval workflows, custom roles with granular permissions, audit log exports, SCIM provisioning, and SSO with every major identity provider. If you have a 200-person engineering org with strict compliance requirements, these features matter.

Rollgate covers team management, role-based access, and audit logging — enough for most teams — but doesn't yet match LaunchDarkly's enterprise governance depth.

Relay Proxy

LaunchDarkly's Relay Proxy lets you run a local proxy that caches flag data, reducing latency and providing an extra layer of resilience. This is particularly valuable in high-traffic environments or architectures with strict network policies.

Rollgate's SDKs handle resilience at the SDK level (circuit breakers, local cache, SSE streaming), but a dedicated relay proxy is not yet available.

Statistical Experimentation

LaunchDarkly's experimentation add-on includes statistical significance calculations, metric analysis, and guardrail metrics. If you're running high-stakes A/B tests where statistical rigor matters, LaunchDarkly's experimentation is more mature.

Rollgate offers A/B testing on Pro plans and above, but the statistical analysis tooling is still evolving.

Bottom line: If you're a Fortune 500 company with an unlimited budget and need every possible integration, LaunchDarkly is a safe choice. For everyone else, the question is whether those extras justify 10-30x the cost.

Migration from LaunchDarkly to Rollgate

Switching from LaunchDarkly doesn't have to be painful. Here's a practical migration path:

Step 1: Export Your Flags

Audit your current LaunchDarkly flags. Most teams discover that 30-50% of their flags are stale (old kill switches, completed rollouts, abandoned experiments). Migration is a good time to clean house.

For each active flag, note:

Flag key and type (boolean, string, multivariate)
Targeting rules and segments
Default values (on/off)
Which environments use it

Step 2: Create Flags in Rollgate

Recreate your active flags in the Rollgate dashboard. Rollgate supports the same flag types: boolean, string, number, and JSON. Targeting rules map directly — user attributes, segments, and percentage rollouts all work the same way.

Step 3: Swap the SDK

This is the core change. Here's how LaunchDarkly SDKs map to Rollgate equivalents:

LaunchDarkly SDK	Rollgate SDK	Package
`launchdarkly-js-client-sdk`	`@rollgate/sdk-browser`	Browser/SPA
`launchdarkly-react-client-sdk`	`@rollgate/sdk-react`	React
`@launchdarkly/node-server-sdk`	`@rollgate/sdk-node`	Node.js server
`launchdarkly-vue-client-sdk`	`@rollgate/sdk-vue`	Vue 3
`gopkg.in/launchdarkly/go-server-sdk.v5`	`github.com/rollgate/sdk-go`	Go server
`com.launchdarkly:launchdarkly-java-server-sdk`	`io.rollgate:sdk-java`	Java server
`launchdarkly-server-sdk` (Python)	`rollgate-sdk-python`	Python server
`launchdarkly_flutter_client_sdk`	`rollgate_sdk_flutter`	Flutter
`launchdarkly-react-native-client-sdk`	`@rollgate/sdk-react-native`	React Native

Step 4: Update Flag Evaluation Calls

The API surface is intentionally similar. Here's a typical before/after:

LaunchDarkly (React):

import { useFlags } from 'launchdarkly-react-client-sdk';

function MyComponent() {
  const { newCheckout } = useFlags();
  return newCheckout ? <NewCheckout /> : <OldCheckout />;
}

Rollgate (React):

import { useFlag } from '@rollgate/sdk-react';

function MyComponent() {
  const newCheckout = useFlag('new-checkout', false);
  return newCheckout ? <NewCheckout /> : <OldCheckout />;
}

The main differences: Rollgate uses useFlag('key', defaultValue) instead of destructuring from useFlags(). This makes default values explicit and avoids issues with undefined flags.

Step 5: Run Both in Parallel (Optional)

For critical flags, you can run both LaunchDarkly and Rollgate simultaneously during a transition period. Evaluate flags from both services and log any discrepancies. Once you're confident the values match, remove the LaunchDarkly SDK.

Step 6: Clean Up

Remove LaunchDarkly SDK packages, delete environment variables, and update your CI/CD pipeline. Cancel your LaunchDarkly contract (check your billing cycle — many contracts auto-renew).

Most teams complete the migration in 1-3 days for small projects and 1-2 weeks for larger codebases with multiple services.

When to Choose Each Alternative

Choose Rollgate if:

You want flat, predictable pricing without MAU penalties
Scheduled releases and instant rollback are core requirements
You need GDPR compliance with EU-hosted infrastructure (Germany)
You're a startup or mid-size team (5-50 developers) shipping fast
You want resilient SDKs with circuit breakers and local caching out of the box
You care about gradual rollouts as part of your release process

Choose LaunchDarkly if:

You're an enterprise with budget for $25K+/year and need maximum integrations
You need 25+ SDKs including niche languages (Haskell, Erlang, Lua, etc.)
You need built-in experimentation with statistical significance
You require enterprise governance: approval workflows, SCIM, custom roles
You need the Relay Proxy for latency-sensitive, high-traffic architectures

Choose Flagsmith if:

You need to self-host today and want an open-source option (MIT license)
You want remote config in addition to feature flags
You need an open API and want full control over your flag infrastructure
You're comfortable managing your own infrastructure and upgrades

Choose ConfigCat if:

You have a small team with very few flags and simple targeting needs
You primarily need simple boolean toggles without scheduling or rollback
You want a no-frills tool that does the basics well at a reasonable price
Polling-based updates (no real-time SSE) are acceptable for your use case

Choose GrowthBook if:

A/B testing and experimentation are your primary use case, not feature management
You want to self-host and connect your own data warehouse (BigQuery, Snowflake, etc.)
You need Bayesian statistical analysis built into the platform
Feature flags are secondary to your experimentation workflow

FAQ

Is Rollgate production-ready?

Yes. Rollgate has been running in production since 2025. The platform handles millions of SDK requests, is hosted on EU infrastructure (Hetzner, Germany), and has built-in resilience at every layer — from the API (health checks, graceful degradation) to the SDKs (circuit breakers, retry logic, local caching). You can try the live demo to see the dashboard and evaluate flags in real time.

How long does migration from LaunchDarkly take?

For most teams, 1-3 days for a small project (one service, a few flags) and 1-2 weeks for larger codebases with multiple services and environments. The SDK APIs are intentionally similar, so the code changes are mostly find-and-replace. The longest part is usually auditing and cleaning up stale flags, which you should do anyway.

Does Rollgate support Server-Side Rendering (SSR)?

Yes. The @rollgate/sdk-node package supports server-side flag evaluation, which integrates with Next.js, Nuxt, SvelteKit, and any other SSR framework. You can evaluate flags on the server and pass them to the client as initial props, avoiding layout shifts and flicker. The Node SDK supports SSE for real-time updates, so flag changes propagate without redeployment.

How does Rollgate pricing compare to LaunchDarkly for a growing startup?

A startup with 50,000 MAU would pay approximately $2,500/month with LaunchDarkly. With Rollgate, the same team would pay €39-99/month depending on SDK request volume. That's a difference of roughly $28,000/year. See the full pricing comparison for details.

Can I use Rollgate with my existing analytics stack?

Yes. Rollgate's SDKs emit events that you can forward to your existing analytics tools (Segment, Mixpanel, PostHog, etc.). Flag evaluations include context about which variant was served, making it easy to correlate feature flags with product metrics.

Get Started

Rollgate's free tier includes 500K requests per month, 3 projects, all 13 SDKs, and unlimited flags. No credit card required.

If you're evaluating a LaunchDarkly alternative, create a free account or try the live demo to see it in action.

I'm building Rollgate, a feature flag platform for developers. If you have questions about feature flags, drop them in the comments — happy to help!

What Are Feature Flags? A Complete Guide for 2026

Domenico Giordano — Fri, 03 Apr 2026 12:55:13 +0000

I've been using feature flags for years, and I'm still surprised how many teams ship code without them. Whether you're a solo dev or on a 50-person team, feature flags change how you think about deployments. This is the guide I wish I had when I started — practical, with real code examples in 5 languages.

What Are Feature Flags?

Feature flags (also called feature toggles or feature switches) are a software development technique that lets you enable or disable functionality in your application without deploying new code. Instead of shipping a feature directly to all users, you wrap it behind a conditional check that can be toggled on or off remotely.

At its simplest, a feature flag looks like this:

if (featureFlags.isEnabled('new-checkout')) {
  showNewCheckout();
} else {
  showOldCheckout();
}

The key difference from a regular if statement is that the flag's value is controlled externally — through a dashboard, API, or configuration service — not hardcoded in your source code. This separation of deployment from release is what makes feature flags so powerful for modern engineering teams.

Feature flags have become a core practice at companies like Netflix, GitHub, Google, and Spotify. They're not just a convenience — they're infrastructure that enables continuous delivery, experimentation, and operational safety at scale.

Feature Flags vs Feature Toggles vs Feature Switches

If you've been researching this topic, you've probably seen all three terms used interchangeably. Here's the short answer: they're the same thing.

Feature flag is the most widely used term, especially in North America and in the context of SaaS platforms.
Feature toggle was popularized by Martin Fowler's influential article on feature toggles and is common in European engineering circles.
Feature switch is less common but still used, particularly in mobile development and gaming.

Some teams draw subtle distinctions — for example, using "toggle" for simple on/off switches and "flag" for flags with targeting rules and percentage rollouts — but in practice, the industry treats them as synonyms. Throughout this guide, we'll use "feature flag" as the primary term.

What matters is not the name but the capability: decoupling code deployment from feature release so you can control what users see without redeploying your application.

Why Use Feature Flags?

Feature flags solve several problems that every growing engineering team faces:

Ship Faster, Break Less

Without feature flags, deploying code means releasing it to everyone. This creates pressure to batch changes into large releases, which are riskier and harder to debug. Feature flags decouple deployment from release. You can merge code to main, deploy it to production, and only enable it when you're ready.

This is the foundation of trunk-based development — a practice where all developers commit to a single branch and use feature flags to hide work-in-progress. No more long-lived feature branches, no more merge conflicts, no more "integration hell." If you're curious about how this compares to branching strategies, check out our guide on feature flags vs feature branches.

Gradual Rollouts

Instead of flipping a switch for 100% of users, you can roll out a feature to 1%, then 5%, then 25%, then 100%. If something goes wrong at 5%, you turn it off — no rollback, no hotfix, no downtime.

Gradual rollouts give you confidence. You can observe real-world behavior with a small audience before committing to a full release. For a deep dive on implementation strategies, see our gradual rollouts guide.

Kill Switches

Production incidents happen. A feature flag gives you an instant kill switch. Instead of reverting a commit, waiting for CI, and redeploying, you toggle a flag and the problematic feature is disabled in seconds.

The difference between a 30-second recovery and a 30-minute recovery is enormous — both for user experience and for your on-call team's stress levels.

A/B Testing

Feature flags are the foundation of experimentation. Show variant A to 50% of users and variant B to the other 50%, then measure which performs better. This is how companies like Netflix, Uber, and Spotify make data-driven product decisions.

With multivariate flags, you can test more than two variants simultaneously — different copy, layouts, pricing displays, or algorithms — and let data guide your decisions. Learn more about combining A/B testing with feature flags.

User Targeting

Want to enable a feature only for beta testers? Or only for users on the Pro plan? Feature flags with targeting rules let you control exactly who sees what, based on user attributes like email, plan, country, or custom properties.

Scheduled Releases

Some features need to go live at a specific time — a marketing campaign, a product launch, or a compliance deadline. Feature flags with scheduling let you set the exact moment a feature activates without anyone staying up at midnight to press a button. We cover this in detail in our scheduled releases guide.

Types of Feature Flags

Not all feature flags are the same. Understanding the different types helps you use them effectively:

Release Flags

The most common type. Used to hide incomplete features in production. Short-lived — removed once the feature is fully launched. These flags enable trunk-based development by letting you merge partially complete work without exposing it to users.

Ops Flags

Used for operational control. Kill switches, circuit breakers, and maintenance modes. These tend to be long-lived and are critical for system reliability. Examples include disabling a non-essential service during peak load or switching to a fallback provider when a third-party API is down.

Experiment Flags

Used for A/B tests and multivariate experiments. They assign users to variants and track metrics. Removed after the experiment concludes and a winner is chosen.

Permission Flags

Control access to features based on user attributes — plan tier, role, geography. Often long-lived, acting as a dynamic permission system. For example, showing advanced analytics only to Pro plan users, or enabling GDPR-specific data handling for EU users.

How Feature Flags Work: Architecture Deep Dive

Understanding the architecture behind feature flags helps you make better decisions about implementation. Here's how a typical feature flag system works end to end:

┌─────────────┐     ┌──────────────────┐     ┌─────────────┐
│  Dashboard   │────>│  Flag Service    │────>│  Database   │
│  (Web UI)    │     │  (API Server)    │     │  (Postgres) │
└─────────────┘     └──────────────────┘     └─────────────┘
                           │
                    ┌──────┴──────┐
                    │             │
               SSE/Polling    REST API
                    │             │
              ┌─────v─────┐ ┌────v──────┐
              │ Client SDK │ │ Server SDK│
              │ (Browser)  │ │ (Node/Go) │
              └─────┬─────┘ └────┬──────┘
                    │             │
              ┌─────v─────┐ ┌────v──────┐
              │ Your App   │ │ Your API  │
              │ (Frontend) │ │ (Backend) │
              └───────────┘ └───────────┘

The Flag Service

At the center is the flag service — the API that stores flag definitions, targeting rules, and percentage allocations. This is where the logic lives: "Enable new-pricing for 20% of users in the US who are on the Pro plan." The service evaluates rules and returns flag states for a given user context.

Client-Side vs Server-Side Evaluation

There are two fundamental approaches to flag evaluation:

Server-side evaluation — Your backend SDK sends the user context to the flag service (or evaluates locally with a cached ruleset) and returns the computed flag values. This is more secure because targeting rules and flag logic never leave your server.

Client-side evaluation — The browser SDK receives the evaluated flag values from the flag service (not the raw rules). The client knows what's enabled for the current user but doesn't see other users' configurations or your targeting logic.

Most production setups use both: server-side SDKs for backend logic and API responses, and client-side SDKs for UI rendering.

Polling vs Streaming

How does your SDK know when a flag changes?

Polling — The SDK periodically checks the flag service for updates (e.g., every 30 seconds). Simple to implement, but introduces latency. If you toggle a flag, it might take up to 30 seconds to propagate.

Streaming (SSE/WebSocket) — The flag service pushes updates to connected SDKs in real-time via Server-Sent Events or WebSockets. Changes propagate in milliseconds. More complex to operate, but critical for kill switches where seconds matter.

Most feature flag platforms support both, letting you choose based on your latency requirements.

The SDK Pattern

Modern feature flag SDKs follow a consistent pattern regardless of language:

Initialize with a client key and optional user context
Cache flag values locally (in memory, localStorage, or disk)
Evaluate flags synchronously from the local cache
Sync with the flag service in the background (polling or streaming)
Emit events for analytics and experimentation tracking

This means flag evaluation is fast (local cache lookup) and resilient (works even if the flag service is temporarily unavailable).

Feature Flags in Different Languages

Feature flags work across any language and framework. Here's what the integration looks like in practice:

JavaScript / React

import { useFlag } from '@rollgate/sdk-react';

function PricingPage() {
  const showNewPricing = useFlag('new-pricing-page');

  if (showNewPricing) {
    return <NewPricingLayout />;
  }
  return <CurrentPricingLayout />;
}

Node.js

import { RollgateClient } from '@rollgate/sdk-node';

const client = new RollgateClient({
  apiKey: process.env.ROLLGATE_SERVER_KEY,
});

app.get('/api/recommendations', async (req, res) => {
  const useNewAlgorithm = await client.isEnabled('new-recommendations', {
    userId: req.user.id,
    attributes: { plan: req.user.plan },
  });

  const results = useNewAlgorithm
    ? await newRecommendationEngine(req.user)
    : await currentRecommendationEngine(req.user);

  res.json(results);
});

Python

from rollgate import RollgateClient

client = RollgateClient(api_key=os.environ["ROLLGATE_SERVER_KEY"])

@app.route("/api/search")
def search():
    user_context = {"userId": current_user.id, "attributes": {"plan": current_user.plan}}

    if client.is_enabled("new-search-engine", user_context):
        return new_search(request.args["q"])
    return legacy_search(request.args["q"])

Go

package main

import "github.com/rollgate/sdk-go"

func handleRequest(w http.ResponseWriter, r *http.Request) {
    ctx := rollgate.UserContext{
        UserID:     r.Header.Get("X-User-ID"),
        Attributes: map[string]interface{}{"plan": "pro"},
    }

    if client.IsEnabled("new-dashboard", ctx) {
        serveNewDashboard(w, r)
    } else {
        serveCurrentDashboard(w, r)
    }
}

Java

import io.rollgate.sdk.RollgateClient;
import io.rollgate.sdk.UserContext;

RollgateClient client = new RollgateClient(System.getenv("ROLLGATE_SERVER_KEY"));

UserContext context = UserContext.builder()
    .userId(currentUser.getId())
    .attribute("plan", currentUser.getPlan())
    .build();

if (client.isEnabled("new-payment-flow", context)) {
    return processWithNewFlow(order);
} else {
    return processWithCurrentFlow(order);
}

The pattern is the same everywhere: initialize a client, pass user context, and evaluate a flag. The SDK handles caching, syncing, and resilience under the hood.

Feature Flag Use Cases

Feature flags are versatile. Here are the most common real-world scenarios where teams use them:

Dark Launches

Deploy a feature to production without any user seeing it. The code is live, but the flag is off. This lets you verify that deployment works — database migrations ran, services connect, no errors in logs — before any user is exposed to the change. When you're confident, you flip the flag for a small group.

Dark launches are especially valuable for major infrastructure changes. You can deploy a new payment provider integration, test it with internal transactions, and gradually shift real traffic without any public announcement.

Beta Programs and Early Access

Create a segment of beta users who opt in to see new features before general availability. This gives you real feedback from motivated users without the risk of a full release. Flag targeting rules make this trivial: target users where beta_program = true or where the email ends with @yourcompany.com.

Trunk-Based Development

In trunk-based development, all developers commit to main (or a single trunk branch). Feature flags hide incomplete work so it can be merged without breaking the application. This eliminates long-lived feature branches, reduces merge conflicts, and keeps the codebase in a continuously deployable state.

The workflow: create a flag, wrap your work-in-progress code behind it, merge to main, deploy. The flag stays off until the feature is complete and tested. Read more about feature flags vs feature branches and why many teams are making this switch.

Canary Releases

A canary release routes a small percentage of traffic to the new version while the majority stays on the current version. If the canary shows elevated error rates or latency, you pull it back. Feature flags enable canary releases at the application level — no need for infrastructure-level traffic splitting.

Operational Kill Switches

Every external dependency in your system should have a kill switch. If your recommendation engine depends on a third-party ML service, wrap it in a flag. When that service has an outage, disable the flag and fall back to a simpler algorithm. Your users see slightly less personalized results instead of an error page.

Entitlement Management

Use feature flags as a dynamic permission layer. Free users see the basic editor; Pro users see the advanced editor with collaboration features; Enterprise users see admin controls and audit logs. When a user upgrades their plan, their flag evaluations update in real time — no code change needed.

Compliance and Regional Features

Some features are only legal in certain regions, or need to comply with specific regulations. Feature flags targeting by geography let you enable GDPR consent flows for EU users, disable certain data collection in California for CCPA compliance, or roll out features region by region to meet local requirements.

Feature Flag Lifecycle

Every feature flag should follow a defined lifecycle. Flags that linger without clear ownership become technical debt. Here's the lifecycle that high-performing teams follow:

1. Planning

Before creating a flag, define its purpose, type, and expected lifetime. A release flag for a new checkout flow might have a two-week lifespan. An ops flag for a circuit breaker might be permanent. Document this upfront.

2. Creation

Create the flag in your dashboard with a descriptive name, a description of its purpose, and an owner. Use a consistent naming convention across your team — feature.checkout-v2, ops.disable-recommendations, experiment.pricing-page-layout.

3. Implementation

Wrap the relevant code paths with the flag check. Keep the flag's scope as narrow as possible — one flag should control one feature, not five. Test both the on and off states.

4. Rollout

Enable the flag progressively. Internal users first, then beta testers, then 5% of production traffic, then wider. Monitor error rates, latency, and business metrics at each stage. Our gradual rollouts guide covers specific strategies.

5. Full Release

Once you're confident, enable the flag for 100% of users. But you're not done yet.

6. Cleanup

This is the step most teams skip — and it's the most important for long-term codebase health. Once a flag has been at 100% for a defined period (one to two weeks is common), remove it:

Delete the flag evaluation from your code
Remove the else branch (the old code path)
Delete the flag from your dashboard
Update any tests that referenced the flag

Set a calendar reminder or use your flag service's stale flag detection to ensure cleanup happens. A codebase with 500 stale flags is a codebase no one wants to touch.

Common Feature Flag Mistakes

Feature flags are powerful, but misuse leads to real problems. Here are the mistakes we see most often:

Never Cleaning Up Flags

The most common mistake by far. Teams add flags but never remove them. Six months later, no one knows if temp-fix-checkout-2024 is still needed. The code has two paths, both partially tested, and removing either feels risky. Prevent this by assigning an owner and an expiry date to every flag at creation time.

Flag Sprawl

Creating too many flags without governance leads to combinatorial complexity. If you have 20 flags, there are potentially over a million unique combinations of flag states. Testing all of them is impossible. Keep your active flag count manageable and archive flags aggressively.

Testing Only the Happy Path

If your code has a feature flag, it has two code paths. Many teams only test the new path (flag on) and neglect the old path (flag off). When the flag is toggled off in an emergency, the fallback is broken because no one tested it.

Nesting Flags

Avoid situations where one flag's behavior depends on another flag's state. if (flagA && flagB) quickly becomes if (flagA && flagB && !flagC), and suddenly your application behavior is impossible to reason about. If you find yourself nesting flags, it's a sign your flag design needs simplification.

Using Flags for Permanent Configuration

Feature flags are for temporary conditions. If something will never be removed — like a config value for page size or a timeout duration — use application configuration, not a feature flag. Conflating the two leads to a flag system bloated with pseudo-config values.

Not Monitoring Flag Impact

Toggling a flag without monitoring is flying blind. Always have dashboards or alerts that correlate flag state changes with key metrics (error rate, latency, conversion). If you enable a flag and errors spike, you need to know immediately.

Feature Flag Best Practices

Keep Flags Short-Lived

Every feature flag is technical debt. Once a feature is fully rolled out, remove the flag and the conditional code. Stale flags clutter your codebase and confuse new team members.

Name Flags Descriptively

Use clear, consistent naming. enable-new-checkout-flow is better than flag-42 or test. Include the feature area and purpose in the name.

Use a Feature Flag Service

Managing flags through config files or environment variables works for a handful of flags but doesn't scale. A dedicated service gives you a dashboard, audit logs, targeting rules, and real-time updates without redeployment.

Test Both Paths

If your code has a feature flag, you have two code paths. Test both. Ensure the application works correctly whether the flag is on or off.

Monitor Flag Usage

Track how many users are seeing each variant. Monitor error rates and performance metrics per flag state. This helps you catch issues early during rollouts.

Set Ownership and Expiry

Every flag should have an owner (a person or team) and an expected removal date. Review stale flags weekly. If a flag has been at 100% for more than two weeks and no one can explain why it's still there, it's time to clean it up.

Feature Flag Tools: The Landscape

There are several feature flag platforms available, ranging from open-source to enterprise SaaS. Here's a brief overview to help you evaluate:

LaunchDarkly — The established market leader with enterprise features, strong SDKs, and a mature platform. Well-suited for large organizations. Pricing starts high and scales with seat count and monthly active users (MAUs), which can get expensive quickly. See our LaunchDarkly alternative comparison for a detailed breakdown.

Flagsmith — Open-source with a hosted option. Good flexibility, supports self-hosting. The interface can feel complex for smaller teams, and some advanced features require the enterprise tier.

ConfigCat — Simple and affordable. Good for teams that want basic flag management without the complexity of a full experimentation platform. Limited targeting and analytics compared to other options.

GrowthBook — Open-source, strong focus on A/B testing and experimentation. Great if experiments are your primary use case. The feature flagging capabilities are secondary to the experimentation engine.

Rollgate — Built for teams that want a fast, developer-focused flag platform without enterprise pricing. First-party analytics, multi-environment support, and SDKs for all major languages and frameworks. Transparent pricing with a generous free tier. For a detailed pricing comparison across platforms, see our feature flags pricing comparison.

The right tool depends on your team size, budget, and requirements. What matters most is that you use something — even a simple implementation is better than no feature flags at all.

Getting Started with Feature Flags

If you're new to feature flags, start simple:

Pick a feature flag service — Choose one that fits your stack and budget. You can try Rollgate for free or explore the live demo to see how it works.
Install the SDK for your tech stack — most platforms have SDKs for JavaScript, React, Node.js, Python, Go, and more.
Create your first flag and wrap a small, low-risk feature — maybe a UI change or a new notification.
Practice the cycle: create flag, deploy code, enable for internal users, monitor, full rollout, clean up.
Establish team conventions — naming patterns, ownership rules, and cleanup cadence.

The learning curve is gentle. Most teams have their first flag in production within an hour.

Conclusion

Feature flags are more than just if/else statements. They're a deployment strategy, a safety net, and an experimentation platform rolled into one. Whether you're a solo developer or part of a large engineering team, feature flags help you ship faster, recover from incidents in seconds, and make product decisions backed by real data.

The pattern is simple — wrap code behind a conditional, control it remotely — but the impact on your delivery velocity and operational confidence is profound. Teams that adopt feature flags consistently report shorter release cycles, fewer production incidents, and more experimentation.

If you're ready to get started, create a free Rollgate account or explore the interactive demo to see feature flags in action.

I'm building Rollgate, a feature flag platform for developers. If you have questions about feature flags, drop them in the comments — happy to help!

I Built Privacy-First Developer Tools That Run 100% in Your Browser

Domenico Giordano — Thu, 11 Dec 2025 23:02:59 +0000

The Problem

Every time I needed to format JSON or encode Base64, I had to use online tools that uploaded my data
to unknown servers. For sensitive data, this felt wrong.

The Solution

I built THEJORD - a collection of developer tools where everything runs client-side. Your data
never leaves your browser.

🔗 Try it: thejord.it

What's Included

JSON Formatter & Validator - Format, validate, beautify with syntax highlighting
PDF Tools - Merge, split, compress PDFs using WebAssembly (no server!)
Base64 Encoder/Decoder
Hash Generator - MD5, SHA-1, SHA-256, SHA-512
Regex Tester - Live highlighting and match groups
Cron Expression Builder
Diff Checker
UUID Generator
And more...

Tech Stack

Next.js 16 with Turbopack
React 19
TypeScript
Tailwind CSS
WebAssembly for PDF processing

Why Privacy Matters

When you paste code or data into online tools, you're trusting that:

The server doesn't log your data
The connection is secure
The company won't be breached

With client-side processing, none of this matters - your data stays on your machine.

Try It Out

👉 thejord.it

Would love to hear your feedback! What tools would you like to see added?