why your saas needs feature flags for its open-source sibling
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.
the trust asymmetry of open core
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.
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.
- 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.
see this on your own repo
tier·dev turns the open-source / saas difference into per-tier feature flags — one repo, generated config, no sdk.
faq
- 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.