We're Building a Feature Flag Platform. Yes, We Know LaunchDarkly Exists.

Every time I talk about feature flagging, I get the same look. "Doesn't that already exist, like, a dozen times over?" Fair. There's LaunchDarkly, Flagsmith, Unleash, PostHog's flagging feature, a stack of self-hosted options, and a new one launching every few months. We started building Zenmanage anyway. Here's why, and what we've actually shipped so far.

The itch

For me it was never about matching a feature list. It was about simplicity: feature flagging that actually works, and nothing more complicated than it needs to be. Ship a change behind a flag, turn it on for 10% of users, turn it off fast if it breaks something. That's the whole job. Every feature we build has to earn its place by making that core job simpler, not by padding a comparison table against LaunchDarkly.

Simplicity also means not having to interrogate your own flags. I wanted a flag list where I could glance at any flag and immediately know what it's doing and why it exists — not stare at enable-v2-checkout-flow-temp wondering if it's safe to delete, or reconstruct the reasoning from a six-month-old Slack thread. If understanding a flag takes real effort, the tool has already failed at the one job it has.

Every existing tool got in the way of that. The big platforms are built for orgs with a platform team to own the integration — SSO, approval workflows, a pricing page that assumes you have 50 seats before you've shipped your first flag. All of that, before you've evaluated a single flag. The small, free, self-hosted options went the other way: nothing standing between you and your first flag, but you end up rebuilding targeting rules, rollout math, and an audit trail yourself the first time someone asks "who turned this off and when."

I didn't want either extreme. I wanted flagging that actually works, with just enough around it — targeting, rollouts, an audit trail — to support that, and nothing added just because a bigger platform has it.

Why compete in a market with a giant at all

A market with a dominant incumbent isn't a warning sign — it's proof someone already paid to validate the problem is real and worth solving. LaunchDarkly didn't invent the need for feature flags; it proved thousands of companies will pay for them. The question isn't whether the market exists. It's whether the incumbent is actually serving everyone in it.

They're not. Yes, LaunchDarkly has a free tier — but a free tier doesn't change how complex the tool is once you're actually using it. You're still in a platform built for organizations with a dedicated team to own the integration, just with a lower price tag on the door. Free doesn't mean simple. Above that tier, LaunchDarkly's pricing and packaging are built around enterprise contracts, not a solo dev or a five-person team trying to ship faster. That gap — teams who outgrew "just use an env var" but aren't ready for an enterprise procurement cycle, or the complexity that comes with one — is where we're building.

Our wedge

Three deliberate bets:

Great value: the right features, not every feature. Our Starter plan is $29/month with unlimited flags and unlimited users. No per-flag upsell, no per-seat tax for adding your third teammate. The only thing you actually pay for is usage — monthly active contexts (MACs) evaluated. That was a specific, debated decision: it's easy to make a pricing page look generous with a flag limit or a seat count, then quietly punish the customers who succeed with the product by making them pay every time the team or the product grows. One meter, tied to actual usage, felt more honest than three meters tied to headcount. But a fair price only means something if the product underneath it does what you actually need — which is why we'd rather ship the handful of features that cover almost every real use case than pad a comparison table.

Simplicity over surface area. We're not trying to match every LaunchDarkly feature on day one. We shipped percentage-based progressive rollouts, environment-scoped targeting rules, and scheduled flag publishing before we touched things like enterprise SSO, because those are the features that get used on a Tuesday, not the ones that close an enterprise deal.

Developer experience as the actual product. If the SDK is annoying to integrate, nothing else about the platform matters. So SDKs got disproportionate investment relative to team size.

What we've shipped

We went live in July 2025 with PHP and Laravel SDKs. Since then:

- JavaScript SDK (February 2026)
- Percentage and progressive rollouts (April 2026)
- Python SDK (June 2026)
- Go SDK (September 2026)
- Permissions and an immutable audit log (June 2026)
- Flag evaluation volume reporting, so you can actually see what's using your quota (August 2026)
- An MCP server, so flags can be managed from inside an AI coding assistant (August 2026)

We're now in the middle of a broader SDK push across the rest of the ecosystem — Go, Java, .NET, and more are in progress, prioritized by what people are actually asking for. Past that, we're not mapping out a long roadmap. We'd rather ship the next thing that keeps flags simple and legible than promise a feature list.

Honest risks

We're small — one engineer building the product, plus a couple of people helping run support — and infrastructure is a trust purchase: nobody wants to bet their release process on a company that might not exist in two years. We don't have an enterprise sales motion or an SOC 2 report yet. Some of the teams we're targeting will rightly wait until we've earned that trust before switching. And LaunchDarkly isn't standing still; they can out-execute us on raw feature count indefinitely if that turns out to be what matters most.

Our bet is that it isn't the only thing that matters — that simple, valuable feature flagging covers what almost everybody actually needs, and that price, unlimited flags and users, and not needing a sales call are worth more than a feature we'll probably never build. We're not trying to match every LaunchDarkly feature; we're betting most teams don't actually need them, and that staying legible matters more than chasing a feature-parity checklist against a company twenty (or more!) times our size.

If you use feature flags today: what made you pick your current tool, or what made you abandon one? I'd genuinely like to know what actually drives that decision for teams our size.