Explore
Feature Flags for MVPs: Gradual Rollouts Without the Complexity

Feature Flags for MVPs: Gradual Rollouts Without the Complexity

How to ship new features to a subset of users, run experiments safely, and roll back instantly — using tools you probably already have.

Feature Flags for MVPs: Gradual Rollouts Without the Complexity

Feature flags let you ship code to production without exposing it to all users. You can roll out a new feature to 10% of users, enable it only for beta testers, or turn it off instantly if something goes wrong — all without redeploying.

For larger teams, this requires dedicated tools like LaunchDarkly or Split. For MVP-stage products on Firebase, you already have a lightweight feature flag system available for free: Firebase Remote Config.

What Feature Flags Are and Why MVPs Benefit From Them

A feature flag is a conditional check in your code: "if this flag is enabled for this user, show the new feature; otherwise show the old behavior."

if (flags.newOnboarding) {
  return <NewOnboardingFlow />
} else {
  return <OldOnboardingFlow />
}

The flag value is controlled externally — from a dashboard or config service — not hardcoded. This separates deployment from release: you can deploy code at any time and release it to users when you're ready.

For MVPs, the most valuable use cases are:

  • Beta rollouts — enable a new feature for your 10 most engaged users before releasing to everyone
  • Safe experiments — test two versions of a flow and measure which converts better
  • Kill switches — if a feature is causing problems, turn it off instantly without a hotfix deploy
  • Early access programs — give specific users access to features before they're public

The Lightweight Approach: Firebase Remote Config as a Flag System

Firebase Remote Config is designed for A/B testing and configuration, but it works well as a feature flag system for MVPs. If you're already using Firebase, you get this at no extra cost.

You define parameters (your flags) in the Firebase console with default values. Your app fetches these values at startup. You can update the values in the console at any time, and apps pick up the changes within the configured fetch interval.

Setup in the Firebase console:

  1. Go to Firebase Console → Remote Config
  2. Add a parameter: key = new_onboarding_enabled, default value = false
  3. Click "Publish changes"

Implementing a Feature Flag in Nuxt: A Practical Example

// composables/useFeatureFlags.ts
import { fetchAndActivate, getRemoteConfig, getValue } from 'firebase/remote-config'

export const useFeatureFlags = async () => {
  const remoteConfig = getRemoteConfig(useFirebaseApp())
  remoteConfig.settings.minimumFetchIntervalMillis = 3600000 // 1 hour

  await fetchAndActivate(remoteConfig)

  return {
    newOnboardingEnabled: getValue(remoteConfig, 'new_onboarding_enabled').asBoolean(),
    betaDashboard: getValue(remoteConfig, 'beta_dashboard').asBoolean()
  }
}

Then use it in a page or component:

// In a page
const flags = await useFeatureFlags()

if (flags.newOnboardingEnabled) {
  // show new flow
}

For server-side rendering in Nuxt, fetch flag values in a server plugin or middleware and pass them through state so client and server render the same content.

Gradual Rollouts: Targeting Specific Users or Percentages

Firebase Remote Config supports conditions — rules that determine which value a user receives. You can target by:

  • User property — e.g., a custom property you set: remoteConfig.setUserProperties({ plan: 'beta' })
  • Percentage rollout — e.g., "10% of users get true, 90% get false"
  • App version — different flag values for different app versions
  • Country — enable features for specific geographies first

To set up a percentage rollout in the Firebase console:

  1. Open your Remote Config parameter
  2. Click "Add new condition"
  3. Select "User in random percentile" → set to 10%
  4. Set the flag value for that condition to true

Now 10% of users will see the new feature, 90% won't. You can gradually increase the percentage as you gain confidence.

When to Graduate to a Dedicated Tool

Firebase Remote Config is enough for most MVPs. Consider a dedicated feature flag tool when:

  • You need immediate flag changes without waiting for the Remote Config fetch interval
  • You want per-user flag targeting based on complex user attributes
  • You need flag evaluation server-side with low latency (Remote Config is designed for client-side)
  • You're running formal A/B experiments with statistical significance tracking

At that point, Unleash (open-source, self-hostable) and Flagsmith (generous free tier) are the best options before jumping to the cost of LaunchDarkly.

Common Mistakes When Flags Aren't Cleaned Up

Feature flags accumulate. Developers add flags during a risky release and forget to remove them once the feature is fully rolled out. Six months later, you have 20 flags in the codebase, half of which are always true and can be removed.

A few practices that prevent flag debt:

Name flags with intent and date — new_onboarding_enabled_2024_q3 makes it obvious this was temporary and when it was added.

Create a cleanup task when you create a flag — add a ticket or to-do at the same time as the flag: "Remove flag name once fully rolled out."

Audit flags quarterly — a 30-minute review of active flags removes the ones that are no longer serving a purpose.

Flag hygiene is one of those things that's easy to ignore until you're debugging a confusing behavior that turns out to be caused by an old flag nobody remembers adding.

If you want feature flags built into your MVP architecture from the start, let's talk.

Back to all articles