LaunchDarkly

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me feature flags that replace LaunchDarkly — and know what makes this ALMOST.

Flags in a file are trivial. What is not is **staying correct and fast when your own flag service is unreachable**, and **a kill switch that takes effect in seconds rather than at the next poll**. Those two properties are what let a team put a flag in a hot path and trust it. Get them right and this is genuinely yours; get them wrong and you have added a single point of failure to every request.

STACK
- Node 20+ with Fastify for the control plane
- SQLite through better-sqlite3, WAL mode
- A small SDK per language you use, evaluating locally
- Caddy in front

THE DATA MODEL
- flags: id, key, kind, description, default_value, variations_json, is_active, is_permanent, created_at, archived_at
- environments: id, name, key — development, staging, production, each with its own rules
- rules: id, flag_id, environment_id, position, condition_json, variation, rollout_json — evaluated in order, first match wins
- segments: id, key, condition_json — a named audience reused across flags
- targets: flag_id, environment_id, unit_id, variation — individual overrides, which is how you turn something on for one customer
- audit: id, actor_id, flag_id, environment_id, before_json, after_json, at — append-only. A flag change is a production change and deserves the same record as a deploy
- evaluations: sampled counts per flag per variation, not one row per evaluation

FAILING SAFE, WHICH IS THE FIRST HARD PART
- The SDK holds the whole rule set in memory and evaluates locally. No network call in the request path, ever
- On start it loads from a local cache file first, then updates from the service. If the service is down at boot, the application still starts with the last known rules
- If the service is unreachable, evaluation continues with what it has, indefinitely, and reports staleness rather than falling back to defaults. Falling back to defaults during an outage is how a flag service takes your application down with it
- A hard-coded default in the calling code as the last resort, for the case where a flag is genuinely unknown
- The rule set contains no personal data — it is conditions over attributes, and the attributes stay on your side

FAST UPDATES, THE SECOND
- Server-sent events push the updated rule set to every connected SDK. One connection, no protocol to write, and it reconnects itself
- A poll on a slow interval as a fallback, so a proxy that eats event streams degrades to seconds-to-minutes rather than to nothing
- The payload is the whole rule set, small and versioned, with an ETag. Sending diffs is a premature optimisation that makes recovery harder
- Measure the time from clicking off to the last server evaluating off. That number is what a kill switch is worth, and it should be single-digit seconds

EVALUATION
- Deterministic bucketing: hash the unit key with the flag key and a salt. The same user always gets the same variation, on the server, in the browser, everywhere, with no coordination
- Percentage rollouts that are stable when the percentage changes — a user in the first ten per cent stays in when it becomes twenty
- Conditions over attributes you pass in: plan, country, version, anything. Evaluated by the SDK from the rules, never by asking the service
- Prerequisites, so a flag can depend on another, with cycle detection at save time

DISCIPLINE, WHICH DECIDES WHETHER THIS HELPS
- Every flag has an owner and an intended lifetime. Temporary flags are the point; a codebase with four hundred permanent ones is a codebase nobody can reason about
- A report of stale flags — unchanged for months, or fully rolled out — and a nudge to remove them
- A code search integration listing where each flag is referenced, so removal is a small task rather than an archaeology exercise

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, SDK_KEY_SALT
- Migrations on boot, each once; nightly backup off the machine
- The control plane should be independent of the applications it serves — if they share a database, they share an outage
- Health endpoint reporting connected SDKs and the newest rule version

WHAT MATTERS MOST
Local evaluation with a cached rule set, and the kill switch latency. Turn the flag service off entirely and confirm every application keeps serving correctly; that test is the whole point.