Build vs buy: what a homegrown feature flag system actually costs

Every feature flag system starts the same way, and it starts right.

You need to ship a half-finished feature without holding up the release, so you add a boolean. An env var, a row in a config table, a constant behind an if. Eleven minutes, and it works.

That is the right call. Nobody should buy a platform to hide one unfinished checkout page.

The cost shows up later. Not in the eleven minutes - in everything that gets asked of it next.

Months 1 to 3: it works

Three or four booleans in config. Changing one needs a deploy, which is fine, because you deploy most days. Nobody has complained. Building was obviously right.

Months 4 to 6: three requests

They arrive in this order, more or less.

“Can we turn it on for one customer?” Sales promised a prospect. Your boolean becomes a lookup: flag plus account ID. You add a list. Fine.

“Can we give it to 10% first?” Someone got burned by a bad release. Now you need stable bucketing - the same user has to get the same answer every time, or the UI flickers. You write a hash over the user ID. Takes a day, and it is a fun day.

“Can I change it without a deploy?” This one changes everything. Flags move out of the deploy pipeline and into runtime state. Runtime state means a datastore. A datastore on every evaluation means caching. Caching means invalidation.

You are building a distributed config system now. You did not mean to.

Months 7 to 12: it is a product

A year in, most homegrown systems have picked up:

• An admin UI, because running SQL to flip a boolean got old, and product needs access without shipping code.
• A cache, because a flag check was costing a database round trip on a hot path.
• An audit trail, usually written the week after nobody could say who turned what on.
• A second SDK, because the frontend or the mobile app needs the same flags and your first one assumed server-side Ruby.
• A rule format, which starts as if account_id in list and ends as an expression language nobody wrote down.

None of it was planned. Each piece was two days. Together they are a product with no owner, no roadmap, a handful of tests, and one person who understands it.

That last part is the bill.

Months 13 to 24: two things you find out

Everything depends on it. Every service reads flags. So when the flag service is slow, everything is slow. When it is down, you find out whether you fail open or fail closed - a decision most teams never actually made. You make it at 3am instead.

The person who built it leaves. Now on-call covers a bespoke distributed system with no docs, no Stack Overflow, and nobody to ring. Every new hire has to learn it, and it teaches them nothing they can take anywhere else.

The numbers

This is a model, not data from your codebase. It assumes a loaded engineer cost of $120,000 a year - about $58 an hour - and hours on the low side. Swap in your own.

That is year one, before the incident you have not had yet. Year two is less building and more maintenance, and it never hits zero.

Our Team plan is $99 a month. $1,188 a year, or $990 if you pay annually.

The gap is not really the point. Those hours went somewhere other than your product. That is the point.

When you should build it

Most vendor comparisons skip this bit.

Build if you have fewer than about five flags and expect that to hold, a deploy to change one is fine, no non-engineer needs access, you run one language on one platform, and nothing needs auditing.

That is a lot of teams. For them a config file is not just good enough, it is better: fewer moving parts, nothing to pay for, no network call.

Also build if flag evaluation is part of what you sell. If you are building an experimentation company, do not buy an experimentation engine.

Buy when any of these turns up: non-engineers need to flip flags, you need changes without deploys, you need percentage rollouts or per-customer targeting, you have a second language or platform, or someone asked “who turned that on?” in an incident review.

There is one clear signal. The first time someone proposes building an admin UI for your flags, you have crossed the line. That is where a config file turns into a product.

If you do buy

The pricing models differ more than the features do.

• Per seat means you will end up rationing access. The people who most need to kill a flag at 2am are often the ones without a seat.
• Per MAU means the bill grows when the product works. Rough on consumer apps, where most monthly actives never pay you anything.
• Per request is the easiest to predict, as long as the allowance is honest and going over starts a conversation rather than an invoice.

Whatever you pick, check for SDKs in every language you actually run, an audit trail, percentage rollouts with stable bucketing, a kill switch, and some way to find dead flags. After not having flags at all, the next worst thing is having four hundred of them and no idea which ones still matter.

Featureflow is flat-priced: unlimited seats on every paid plan, no MAU metering, free tier, no card. If you are maintaining your own system and want a second opinion on whether it is worth replacing, contact us - we will tell you if the answer is keep it. If you are an early-stage startup, there is a discount.