can I use tier·dev and LaunchDarkly together?

Yes, and it's a common end-state: tier flags decide what each edition contains; the runtime tool runs experiments inside the paid edition. Keep edition decisions out of the runtime tool so your open-source build never depends on it.

what about open-source flag tools like Unleash or Flagsmith?

They're runtime evaluation engines you self-host — closer to LaunchDarkly's job with different operations. They still don't model editions as first-class tiers or emit committed per-edition config, which is the part open-core packaging actually needs.

is tier·dev a kill switch?

No. A kill switch needs runtime delivery measured in seconds. tier·dev changes ship like code changes — deliberately. If you need both speeds, that's the two-layer setup above.

comparison

tier·dev vs LaunchDarkly: which feature flags fit an open-core product?

the verdict

LaunchDarkly is built for runtime experimentation — percentage rollouts, A/B tests, kill switches served by an SDK over the network — while tier·dev is built for edition packaging: per-tier flag values for open-source, saas, and pro editions of one codebase, resolved into committed JSON/YAML/code config with no runtime SDK, which is the shape an open-source distribution can actually ship.

connect a repo →

Both products say 'feature flags' on the box, which is exactly why teams pick the wrong one. The question that decides it: are your flags decisions about *what a running system shows a user right now*, or decisions about *what a distribution of your codebase contains*?

Runtime experimentation and edition packaging are different jobs with different constraints — and the open-source half of an open-core product imposes the hardest constraint of all: whatever mechanism you choose has to keep working for a stranger who clones your repo with no account, no API key, and no network.

3 formatstier·dev resolves every flag per tier into committed JSON, YAML, or dependency-free TypeScript — nothing to install, nothing to call at runtime

connect a repo →about tier·dev

tierdev.ogbuilds.ai/repos/acme-analytics/flags

tier·dev

dashboardconnect

+ new flag

flag name

PRO_DASHBOARD_ENABLED

default state

offon

per-tier overrides

open-sourceinherit default (off)

saason

proon

save changes

jsonyamltypescript

copy

{
  "tiers": {
    "open-source": {
      PRO_DASHBOARD_ENABLED: false
    },
    "saas": {
      PRO_DASHBOARD_ENABLED: true
    },
    "pro": {
      PRO_DASHBOARD_ENABLED: true
    }
  }
}

commit this file — no runtime sdk, no vendor callregenerates on save

where this happens in the app

the structural difference vs runtime flag platforms: tier·dev's output is committed config — json, yaml, or dependency-free code — not an sdk call in your request path.

1one default plus per-tier overrides — packaging decisions, not per-user targeting rules.
2three formats, same resolved values; the open-source clone of your repo needs no account or key.
3no vendor in the hot path: the config regenerates on save and ships inside your repo.

the shape of the problem decides the tool

A LaunchDarkly-style platform evaluates flags per user, per request, against targeting rules — which requires an SDK in your process and a vendor in your request path. That's the right trade for experimentation: rules change hourly and you want them live without a deploy.

Edition packaging changes on pricing-page time, not request time. The values belong in version control, where a flag flip is a one-line PR someone reviews — and where the open-source build resolves its flags from a file that ships inside the repo itself.

what the open-source edition can't tolerate

Putting a commercial flag SDK inside an open-source distribution leaks your vendor choice into every clone, makes first-run depend on someone else's uptime, and asks contributors to develop against flags they can't see. Committed config has none of those failure modes — it diffs, it reviews, and it works offline.

Plenty of teams run both layers happily: tier·dev decides what each edition contains, and a runtime tool experiments within the paid edition. The boundary is healthy because the jobs are different.

tier·dev vs LaunchDarkly at a glance

	tier·dev	LaunchDarkly
built for	edition packaging (open-source / saas / pro)	runtime experimentation + rollouts
flag resolution	per tier, at build or boot, from committed config	per user, per request, via SDK + network
runtime dependency	none — generated JSON/YAML/code in your repo	vendor SDK in-process, flag delivery network
works in a cloned OSS repo	yes — the config ships with the code	no — needs an account, key, and connectivity
change review	git diff on tiers.json, PR approval	dashboard audit log
targeting rules / % rollouts	no — tiers only, by design	yes — its core strength
price to start	free in early access	per-seat / MAU pricing

frequently asked

can I use tier·dev and LaunchDarkly together?: Yes, and it's a common end-state: tier flags decide what each edition contains; the runtime tool runs experiments inside the paid edition. Keep edition decisions out of the runtime tool so your open-source build never depends on it.
what about open-source flag tools like Unleash or Flagsmith?: They're runtime evaluation engines you self-host — closer to LaunchDarkly's job with different operations. They still don't model editions as first-class tiers or emit committed per-edition config, which is the part open-core packaging actually needs.
is tier·dev a kill switch?: No. A kill switch needs runtime delivery measured in seconds. tier·dev changes ship like code changes — deliberately. If you need both speeds, that's the two-layer setup above.

Last updated June 12, 2026

more on tier·dev

tier·dev — git-integrated feature flags for open-source + saas tiers →

ready to try tier·dev?

connect a repo →