You Could Build Your Own Feature Flags in a Weekend. Then Comes Month Six.

Every time a feature flag vendor changes its pricing, the same reply shows up underneath the announcement. Someone, usually senior engineers with good track records, say something like: “Why pay for this at all? It’s an if-statement behind an API. Build it in a weekend with an LLM and host it on Cloudflare.”

They’re not wrong. That’s the uncomfortable part. A single boolean you can fetch over HTTP really is a weekend project, and with an AI coding agent helping you it might be an afternoon. I’ve spent the past two years building a feature flag service and I’m telling you the first version is genuinely easy.

So if it’s that easy, why does RocketFlag exist? Because the weekend project isn’t the thing you end up maintaining. The thing you end up maintaining shows up around month six, and nobody quotes you a price for that part up front.

I’ve built the whole thing. Here’s the work that the “weekend” estimate quietly leaves out.

The if-statement is the easy 20%

Your first version returns { "enabled": true } and you wire it into one service. It feels great. You’ve replaced a SaaS bill with a hundred lines of code.

Then reality arrives one requirement at a time.

You want the same flag to behave differently in staging and production, so now you need environments. You want to turn a feature on for just your QA team or a specific customer, so now you need cohorts and some way to target them. You want to roll a feature out to 10% of traffic and creep it up, so now you need percentage splits and a consistent bucketing algorithm so a given user doesn’t flip-flop on every request. Someone turns a flag on in prod at 2am during an incident and the next morning nobody can say who did it, so now you need an audit log. A new hire asks “which of these 140 flags are actually still in use?” and nobody knows, so now you need a way to track flag lifecycle.

None of that was in the weekend estimate. Each piece is small on its own. Added together they are a product, and you are now the team maintaining it.

The reliability question you have to answer yourself

Here’s one that’s easy to skip until it bites. When your flag service is slow or unreachable, what does the calling code do?

If you don’t answer that deliberately, the default answer is “your app waits, or throws.” A flag check sitting on a hot request path can quietly add latency to every single request, and an outage in your little weekend service becomes an outage in the product it was supposed to make safer. That’s the opposite of why you reached for flags.

The fix is caching with a sensible expiry, and a clear decision about what happens when the cache is cold and the service is down. RocketFlag’s SDKs cache flag values locally for a timeout you choose, so the common case never leaves your process and never adds network latency. When that timeout expires the SDK fetches a fresh value rather than serving you something stale, because a flag that’s silently out of date is its own category of bug. That’s a deliberate tradeoff, and the point is that it’s a tradeoff somebody has to think through. In the build-your-own version, that somebody is you, probably during the incident.

Flags rot, and cleanup is the part nobody builds

This is the one I’d push hardest on, because it’s the most common real-world complaint about feature flags and it has nothing to do with pricing.

Flags are meant to be temporary. You add one to de-risk a release, the release goes fine, and then the flag just… stays. The conditional branch around it stays. Six months later your codebase is full of dead if statements guarding features that shipped permanently long ago, and your flag list is a graveyard nobody trusts. People stop believing the list means anything, which defeats the purpose of having it.

A home-grown tool almost never gets cleanup tooling, because cleanup is boring and it’s never the thing on fire this week. So the debt just compounds.

This is where I’ll happily make the case for RocketFlag, because we built a feature specifically for this and I haven’t seen many small tools bother. It’s called Caretaker. It watches your flags and classifies them: healthy ones it leaves alone, but a flag that’s been pinned fully on or fully off for a month while still serving real traffic gets marked stale, and a flag that hasn’t been evaluated in 60+ days gets marked dormant, which usually means it’s already dead code. Flagged flags get a badge in the dashboard so they’re hard to ignore.

And then, since everyone’s reaching for AI coding agents anyway, Caretaker leans into it: it generates a removal prompt for the specific flag, with its config and history, that you paste straight into Cursor, Copilot, or Claude. The agent strips out the conditional branches and leaves the “feature on” path. You review it like any other pull request and delete the flag. If you’re not ready to remove one yet, you snooze it for 30, 60, or 90 days and it stops nagging you until then.

The irony isn’t lost on me. The same AI tooling people want to use to build their own flag service is the thing that makes ongoing flag cleanup finally painless. Building the toggle was never the hard part. Living with hundreds of them for years is.

So should you build it? Sometimes, honestly.

I’m not going to pretend the answer is always “buy.” If feature flagging is genuinely core to your product, if you have specific needs no tool covers, or if you have the appetite to own and maintain a small internal platform, then build it. Some teams should, and a few of the best feature flag companies started exactly that way.

But for most teams, flags are not the product. They’re plumbing that should be reliable, predictable, and boring. The real question isn’t “can I build this in a weekend.” You can. The question is whether a boolean-as-a-service deserves a permanent seat on your roadmap, taking attention away from the thing your customers actually pay you for.

That’s the calculation that the weekend estimate hides. The build is cheap. The ownership is not.

Where RocketFlag lands

RocketFlag is the buy-it-and-forget-it option. Cohorts, percentage rollouts, multiple environments, audit logs, SDKs for Node, React, and Go, and Caretaker keeping your flag list honest. One flat price: free for solo developers, A$79/month for teams with unlimited seats, unlimited flags and unlimited evaluations. No counting connections, no counting users, no metering. The bill doesn’t change shape when your architecture does, which means you can architect for resilience instead of for an invoice.

Build it if it’s core to you. If it isn’t, pay a predictable number, get your weekend back, and spend month six on your actual product.

— JK @ RocketFlag