About two years ago, we were somewhere between scaling Plane’s cloud and planning our first commercial release. One foot in open source, the other in enterprise.
Everything looked smooth until a single question turned into a month-long rabbit hole.

How do we programmatically provision and maintain plan fidelity? In other words, how do we know which customer is entitled to which features?

That question, asked half-jokingly in a late-night Slack thread, became the start of one of the most foundational internal tools we’ve ever built—our in-house feature flagging and licensing product.
It now saves us nearly a million dollars a year, but money was never the driver.

It started when off-the-shelf tools fell short.

When we began planning feature rollouts for paid customers, we evaluated LaunchDarkly and PostHog, two of the most capable tools in the space. Both handled A/B testing and percentage rollouts well, but neither fit Plane's operating model. Our product runs across cloud, self-hosted, and fully air-gapped environments, including deployments with no outbound internet access.

This architectural difference created several practical issues. These tools required continuous calls to their own servers, could not represent workspace-based entitlements (who paid for what, within which workspace), and relied on syncing user data to a third-party system. Their pricing also scaled with MTUs, API requests, and service connections, making long-term costs unpredictable. Most importantly, they could not be included in our self-hosted or air-gapped editions.

We could have layered custom logic on top, but the effort and complexity would have outweighed the benefits. At that point, building our own system was the simpler path.

Why we built instead of bought

A large part of our customer base runs self-hosted deployments, often in regulated environments. Many of our customers operate in regulated industries where “connect to LaunchDarkly” is an instant non-starter. They cannot open outbound traffic, leak PII, or rely on a vendor’s uptime for their own software to function.

We built our own system not because we wanted another internal service but because control, compliance, and continuity were non-negotiable.

The seam that made it viable

Our approach changed when we discovered OpenFeature, an open standard for feature flagging that gave us a clear framework to build on. It defined the essentials — flags, segments, and their relationships — while giving us the freedom to design the logic that actually fit our product.

At the center of that logic sits what we call the license user: a pairing of user × workspace (and, in self-hosted, × instance). The same person can be on a Pro plan in one workspace and Business in another, and recognizing that distinction was what made the entire system work.

We extended the model with our own structures:

• Flags that can be Boolean or value-based (for example, 5 MB versus 100 MB upload limits),
• Segments that represent both plan tiers and feature test groups,
• Flag-Segments that determine which features belong to which segment, and
• License User Segments that map users to their appropriate entitlements.

Together, these layers let us manage everything from controlled betas to precise exceptions — granting a single Pro customer access to a Business-only capability or enabling an alpha feature like Nested Pages for just a handful of early users.

Why two services, not one

We built two independent systems to manage feature flagging and licensing:

• DISCO for Cloud
• Prime for self-hosted and air-gapped deployments.

DISCO manages feature flags and payments, while Prime handles encryption, entitlements, and license validation in environments that operate without external connectivity.

This separation keeps payment credentials such as Stripe keys out of customer images, prevents one environment’s issues from affecting another, and allows each edition to function on its own terms. On Cloud, Plane communicates with DISCO in both directions. In Self-Hosted deployments, the instance periodically polls Prime. In Air-Gapped setups, the process is entirely offline through encrypted license files.

The result is a modular design that strengthens security, simplifies maintenance, and ensures consistent behavior across every edition.

The bumps along the way

Like most internal systems, it took a few iterations to get it right.

Management and visibility.
Once the backend worked, the Sales team needed to grant one-off upgrades, Product wanted to run controlled rollouts, and Support needed a way to disable specific features. There was no interface for any of it. We adapted Django Admin to serve as our control panel, managing permissions, flags, and segments in one place. It’s now simple for a product manager to enable a feature for a few users without involving engineering.

Performance and caching.
The first version computed entitlements on every request, adding nearly 800 ms of latency per call. Introducing Redis with regional caching brought this down to around 60 ms, with automatic revalidation every three hours and manual cache clears for immediate updates.

Self-hosted synchronization.
Unlike Cloud deployments, self-hosted deployments can’t communicate with DISCO in real time. We built a lightweight monitor service that fetches encrypted flag payloads from Prime, stores them locally, and reconciles every five hours. If validation fails for more than seven days, the instance downgrades to the Free tier, ensuring continuity for users while preventing abuse.

Air-gapped operations.
Air-gapped environments have no network path at all. For them, we issue a version-bound, encrypted license file that customers upload to activate entitlements. Each upgrade requires a new file, which is why annual terms are practical. Quarterly encrypted log bundles allow compliance checks, fully offline.

What this changed inside Plane

Eighteen months in, the impact has been tangible across every function.

• Feature rollouts are predictable. New capabilities go through internal warm-ups, then selected beta workspaces, before reaching general availability—all from the same source of truth.
• Reliability has improved. No third-party outage can interrupt paid functionality.
• Revenue operations gained precision. Finance can adjust entitlements or grant exceptions without engineering involvement.
• Operations became simpler. Administrators manage permissions through Django rather than code changes.
• Costs stay flat. Infrastructure runs at roughly USD 100-200 compared to vendor estimates approaching USD 900,000–1,000,000 per year.

OpenFeature made the system possible; building and owning it made it sustainable.

Five reasons this decision will age well

1. Standards keep us flexible.
   Built on OpenFeature, the system stays portable. If we ever move to a managed backend, integration is straightforward.
2. One logic, every edition
   Cloud, self-hosted, and air-gapped deployments all run on the same entitlement model, ensuring parity and reducing maintenance overhead.
3. Costs remain predictable.
   Our expenses scale with infrastructure, not with a vendor’s MTU or request-based pricing.
4. Speed with safety
   Features can be tested internally, released gradually, and rolled back instantly—all under our control.
5. Billing and access are unified.
   DISCO connects payment flows directly to feature entitlements, eliminating the need for coupons, code forks, or manual exceptions.

The takeaway

Building our own feature-flagging system was a practical choice. The tools we evaluated couldn’t meet our requirements across Cloud, self-hosted, and air-gapped environments.

The outcome speaks for itself. We save close to a million dollars a year, avoid third-party outages, and maintain full control over pricing, compliance, and release cycles.

For us, owning this layer isn’t about independence for its own sake. It is about reliability and consistency across every edition of Plane.