tier·dev helps founders and teams manage and synchronize the open-source and paid saas versions of their product. connect a repo, define your tiers, set feature flags per tier — and stop maintaining a fork of your own product.
the moment your open-source project grows a paid saas edition, the codebase splits. an enterprise branch here, a private fork there — and every fix now ships twice, or doesn't. founders, maintainers, and small teams burn their best hours keeping versions in sync instead of building.
keep one repo. name your tiers — open-source, saas, pro — and describe the difference between them as feature flags. tier·dev resolves every flag per tier and generates the config your build reads. the divergence is now a json file, not a fork.
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.
the usual way to ship an open-source and a paid version is a long-lived fork or an enterprise branch — and then a slow bleed of cherry-picks, merge conflicts, and 'which branch has that fix?'. tier·dev replaces the fork with a list of named tiers on one repo.
every tier sees the same code. the difference between open-source and saas becomes data — a set of flag values per tier — instead of a diff you have to maintain by hand.
create a flag once, then set its value per tier: on for saas, off for open-source, on for pro. defaults cover the tiers you don't override, so a new tier inherits sensible behaviour on day one.
the dashboard shows the whole matrix at a glance — every flag, every tier, every resolved value — so 'what does the open-source build actually include?' is a lookup, not an archaeology dig.
connect github with one oauth click and pick the repository each set of tiers and flags belongs to. flags live alongside the repo they describe, not in a disconnected spreadsheet.
for every flag, tier·dev generates language-agnostic config — json and yaml per tier, plus a drop-in code snippet — so integrating a flag is copy, paste, commit.
{
"tiers": {
"open-source": {
"PRO_DASHBOARD_ENABLED": false,
"COMMUNITY_TELEMETRY": true
},
"saas": {
"PRO_DASHBOARD_ENABLED": true,
"COMMUNITY_TELEMETRY": false
}
}
}tier·dev touches repo metadata only — never your source. flags resolve to plain json, yaml, or a dependency-free code snippet you commit yourself, so the open-source community that clones your repo gets a working build with nothing proprietary hiding in it.
connect a repo, define open-source and saas, flip your first flag — about two minutes, no sdk.