Won't publishing the boundary help competitors clone our paid tier?

Your paid tier was never secret — it's on your pricing page. The matrix adds engineering precision, not strategic leakage, and the community goodwill is worth more than the obscurity.

What if the community flips the paid flags on themselves?

Self-hosters who flip flags were never your customers — they're your power users. What you sell is hosting, SSO that's supported, updates, and someone to call. Open-core economics survive honesty.

Does this replace a license boundary like BSL or Elastic-style terms?

No — licenses govern rights, flags govern behaviour. Many open-core companies use both: a permissive core, a licensed private module, and flags as the operational seam.

Why your SaaS needs feature flags for its open-source sibling

the short answer

Because the alternative is ambiguity, and ambiguity erodes both sides of an open-core business: the community stops trusting what the open-source edition includes, and your own team stops knowing what the saas actually sells. Per-tier flags make the boundary explicit, versioned, and cheap to maintain — a contract both audiences can read.

An open-core business asks two audiences to trust the same codebase: a community that wants the free edition to be genuinely useful, and customers who want the paid edition to be genuinely worth it. Every undocumented difference between editions taxes one side or the other — hidden limitations feel like bait-and-switch to the community; vague differentiation feels like weak value to buyers.

A flag matrix is the cheapest trust instrument you can ship. It states the boundary in data: COMMUNITY_TELEMETRY on for open-source and off for saas, SSO_SAML_LOGIN the reverse. No archaeology, no folklore.

60%of open-source maintainers describe themselves as unpaid hobbyists — sustainable open-core funding depends on a paid tier whose boundary the community accepts as fair.Source: Tidelift State of the Open Source Maintainer Report, 2023

Flags keep the sibling honest in both directions

The discipline cuts both ways, and that's the point. The open-source build resolves its flags from committed config — so what the community ships is exactly what the matrix says, with no hosted-only magic leaking in.

The saas build is the same code with different values — so 'works locally, broken on cloud' bugs shrink to config diffs. And moving a feature between editions is a reviewable one-line change, which forces the pricing conversation to happen in the open (internally) instead of by code drift.

The failure stories flags prevent

Every open-core maintainer collects the same incidents: the contributor who built against the public repo and hit an invisible saas-only assumption; the enterprise prospect who asked 'what exactly do we get over self-hosting?' and got four conflicting answers; the well-meaning PR that accidentally exposed a paid feature because nothing marked it as paid. Each is a boundary question answered by vibes instead of data.

With per-tier flags the answers are mechanical. What does self-hosting include? Read the open-source column. What do you sell? Diff the saas column against it. Is this feature paid? It has a flag, and the flag has values.

Starting without ceremony

You don't need a migration to begin — you need your next divergent feature. Flag it, set per-tier values, commit the generated config, and let the matrix grow one honest row at a time. tier·dev makes that loop a two-minute task: connect the repo, define open-source and saas, create the flag, copy the snippet.

frequently asked

Won't publishing the boundary help competitors clone our paid tier?: Your paid tier was never secret — it's on your pricing page. The matrix adds engineering precision, not strategic leakage, and the community goodwill is worth more than the obscurity.
What if the community flips the paid flags on themselves?: Self-hosters who flip flags were never your customers — they're your power users. What you sell is hosting, SSO that's supported, updates, and someone to call. Open-core economics survive honesty.
Does this replace a license boundary like BSL or Elastic-style terms?: No — licenses govern rights, flags govern behaviour. Many open-core companies use both: a permissive core, a licensed private module, and flags as the operational seam.

Published June 4, 2026 · Last updated June 16, 2026