generic flag platforms think in percentage rollouts and a/b tests. open-core products need something simpler and stricter: the same codebase, shipped as an open-source version and a paid saas version, with an explicit, versioned record of what differs. that record is tier·dev.
sign in and connect a github repository with one oauth click — gitlab works too. tier·dev reads repo metadata only; your code never leaves your git provider.
name the versions you actually ship — open-source, saas, pro. tiers are just labels on the same codebase, not branches you'll have to merge later.
create a flag like PRO_DASHBOARD_ENABLED, set it on for saas and off for open-source, and paste the generated json, yaml, or code snippet straight into your repo.
tier·dev generates tiers.json, tiers.yaml, and a dependency-free flags.ts for every flag you define. copy one into your repo, set PRODUCT_TIER per build, and each distribution enables exactly its own features. your ci doesn't call us; the config is yours.
{
"tiers": {
"open-source": {
"PRO_DASHBOARD_ENABLED": false,
"COMMUNITY_TELEMETRY": true
},
"saas": {
"PRO_DASHBOARD_ENABLED": true,
"COMMUNITY_TELEMETRY": false
}
}
}no enterprise branch to rebase, no fork to babysit, no release-day cherry-pick marathon. the difference between tiers is a config file that regenerates in one click.
fix a bug once and it lands in every tier on the next build — because every tier builds from the same commit. shipping a saas hotfix no longer leaves the community version behind.
an explicit flag check reads better than a 600-line diff between branches. anyone on the team can answer 'is sso in the open-source build?' by reading the matrix, not the git log.
different labels — open core, freemium, community edition — same underlying problem: one product, multiple offerings, and a codebase that wants to split in two.
you open-sourced the core to win trust and adoption, and you sell the hosted version with pro features. tier·dev keeps the paid difference explicit — billing hooks, sso, the pro dashboard — without splitting the repo your community contributes to.
your project pays its way through a cloud edition. define 'community' and 'cloud' tiers, flag the cloud-only features, and ship both from main. contributors see honest code; the cloud build flips its flags at deploy time.
you ship a free tier and paid tiers of the same app and nobody wants to own 'the branch sync'. one matrix shows every flag across free, pro, and enterprise — and the generated config is the single source of truth in ci.
free in early access. connect a repo and flip your first per-tier flag in about two minutes.