What are feature flags and A/B testing?
Feature flags are switches that control which features are visible to which users — without requiring a code deployment. You can turn a feature on for 5% of users to observe its impact, enable it only for beta testers, or instantly disable a buggy feature in production without a rollback.
A/B testing is the specific use of feature flags to compare two variants — show half your users the existing checkout flow, show the other half a redesigned one, measure which converts better. The split, the targeting rules, and the measurement are all managed through the flag configuration.
Together, they decouple deployment from release. Code goes out to production continuously, but features go live on your terms.
When does your app need it?
- You want to roll out new features gradually rather than all-at-once, to catch issues early
- You're running conversion experiments — testing CTAs, pricing display, onboarding steps
- You have a beta programme and want to give specific users early access to new features
- You need a kill switch: the ability to instantly disable a feature if something goes wrong in production
- You're deploying to enterprise customers who require controlled rollouts under their contract
- Different users are on different plans and should see different feature sets
How much does it cost?
Adding feature flags and A/B testing typically adds 5–11 hours of development — roughly $1,000–$2,000 AUD.
Lower end: A simple feature flag implementation using a managed service (Flagsmith, PostHog, or LaunchDarkly) — integrate the SDK, define a handful of flags, wire targeting rules to user attributes. Manageable in a day.
Higher end: Custom flag evaluation logic, complex targeting rules (by plan, region, user cohort, random percentage), A/B test result tracking integrated into your analytics pipeline, flag management UI for non-developers, and audit logging of flag changes. Also includes the work to instrument your existing codebase with flag checks at meaningful decision points.
How it's typically built
The most common approach is a managed feature flag service. PostHog is popular because it combines feature flags with product analytics — you can create a flag, target a user segment, and measure the outcome in the same tool. Flagsmith is open-source and self-hostable. LaunchDarkly is the enterprise-grade option with more sophisticated targeting and a higher price point.
Custom implementations typically store flag definitions and targeting rules in a database, with a simple evaluation function that runs on each request. This avoids per-seat SaaS costs but requires more initial build work and ongoing maintenance.
On the frontend, flag checks wrap components or route handlers: if (flagEnabled('new-checkout', user)) { ... }. On the backend, they gate API behaviour. The key discipline is removing flag code once a rollout is complete — flag debt accumulates quickly.
Questions to ask your developer
- Do you need a managed service or a custom implementation? Managed services get you running fast; custom avoids ongoing SaaS costs. The tipping point depends on your user volume.
- Who needs to manage flags? If non-developers need to control flags, you need a decent UI — most managed services provide this.
- How will A/B test results be measured? Flags create the experiment; something else (analytics, your database) has to measure the outcome.
- How will old flags be cleaned up? Accumulating dead flag code is a real maintenance cost — establish a process from day one.
- Do you need flag state to be consistent for a user across sessions? Sticky targeting (user always sees the same variant) requires persistent assignment storage.
See also: Analytics setup · User onboarding flow · App cost calculator