Unleash

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 a feature flag service that replaces Unleash: flags evaluated in my own applications, changed without a deploy, and never the reason a request is slow.

STACK
- Node 20+ with Fastify for the admin and the API
- SQLite through better-sqlite3, WAL mode
- A tiny SDK per language you need, starting with one for Node and one for the browser
- Caddy in front. One process; this is not a system that needs three

THE DATA MODEL
- projects: id, name, key
- environments: id, project_id, name, is_production, sort
- flags: id, project_id, key, description, kind, archived_at, created_at, created_by
- flag_states: flag_id, environment_id, enabled, rollout_percent, updated_at, updated_by
- segments: id, project_id, name, constraints_json
- flag_segments: flag_id, environment_id, segment_id, variant
- variants: id, flag_id, name, weight, payload_json
- overrides: id, flag_id, environment_id, user_key, variant, note, expires_at
- audit: id, flag_id, environment_id, before_json, after_json, actor, created_at — append only, never edited
- Flag kinds: release, experiment, operational, permission. The kind decides what the interface nags you about

EVALUATION, WHICH IS THE PART THAT MUST NOT BE WRONG
- Deterministic bucketing: hash of (flag key + user key) into 0..99, compared against the rollout percent. The same user gets the same answer on every machine, forever, with no shared state
- Order of decision, and write it in a comment because everybody argues about it: archived, then kill switch, then explicit override, then segment match, then percentage rollout, then default
- Variants split the bucket space by weight, and weights must total 100 or the save is refused
- Every evaluation returns the value and the reason it got that value. The SDK exposes the reason; the interface shows it for a given user key
- Never evaluate on the server per request from the client: the SDK holds the whole rule set in memory and re-evaluates locally

THE SDK CONTRACT
- Fetch the rule set once at start, then poll or stream changes; keep serving the last known set when the service is unreachable
- A flag that has never been seen returns the default the caller passed, never an exception, never a network wait
- Local evaluation only: no request per check, no round trip in a hot path
- A bootstrap file the application can ship with, so the first evaluation before the first fetch is still right
- Expose a hook so the host application can record which flag it evaluated and to what — the numbers that matter live in their analytics, not here

CHANGING A FLAG
- One switch per environment, and production is visually separated from the others because that is the one that pages somebody at night
- Percentage rollout with a slider that says how many users that is, from the last week's traffic
- Scheduled changes: turn this on at a time, turn it off after an hour
- A required note on any production change, and the note is in the audit row
- Undo: every change can be reverted to the previous state in one click, which is just applying the before side of the audit row

KEEPING IT CLEAN
- Flags rot. Show age, last evaluation, and whether it has been at 100% for more than N days, and offer to archive
- An archived flag returns its default and warns in the SDK logs, so removing the code is a separate step from turning it off
- Search by key, by owner, by kill-switch status
- Export the whole rule set as JSON, and import it into another environment

ACCESS
- Server tokens read the whole project; client tokens read only what is marked public, because a browser token is a public token
- Roles: admin, editor per environment, viewer
- Every token's last use recorded, so an unused token can be found and deleted

THE INTERFACE
- One page listing flags with their state per environment as a row of switches
- The flag page: state, rules, variants, audit, and a box to test a user key against the current rules
- Dark and light, one accent, and production changes coloured distinctly from the rest

OPERATIONS
- .env: DATABASE_PATH, ADMIN_PASSWORD_HASH, TOKEN_SECRET, BASE_URL
- Migrations on boot, each once
- The rule-set endpoint answers from memory and is cached with an ETag; a thousand SDK instances polling must not touch the database
- Nightly backup off the machine, and a restore script
- Health endpoint, and a metrics endpoint with evaluation counts per flag

WHAT MATTERS MOST
Deterministic bucketing and the SDK's offline behaviour are the product. Write those two first and test that the same user key lands in the same bucket across processes and restarts; an inconsistent rollout is worse than no rollout, and a flag service that can take an application down with it will be removed the first time it does.

Give me the repository, the Node and browser SDKs, migrations, .env.example, a seed project with three flags, and a README with deploy steps behind Caddy.