PraxisAI
Sign in
Developer toolinghard

Feature flag service and SDK

Targeting rules, sticky percentage rollouts, an admin API with an audit log, and an SDK that evaluates locally and degrades safely.

Suggested effort
~5h focused work
Window
24 hours
Starts from
An empty repo
Stack
Your choice
Sign in to start this build →

Opens in a new tab. The clock starts when you press Start inside the environment, not before, and your workspace is kept while you step away.

Time window 24 hours. Suggested effort about 5 hours.

Context

Developers want to ship code dark and turn it on gradually: for internal users first, then 10% of customers, then everyone. Build a minimal feature-flag service and a client SDK.

Core requirements

  • Flags with a key, a description, an on/off kill switch, and ordered targeting rules: attribute match (for example country in [GB, IE], email ends with @acme.com) and percentage rollout.
  • An admin HTTP API to create, update and list flags (protected by an admin token from the environment).
  • An evaluation endpoint: given a flag key and a user context, return the variation and the reason (rule 2 matched, rollout 10%, default, flag off).
  • Percentage rollouts are deterministic and sticky: the same user always gets the same answer for the same flag, and raising 10% to 20% keeps the original 10% in.
  • A client SDK (in the same language) that fetches all flags once, evaluates locally, and refreshes on an interval.

Acceptance criteria

  • The evaluation engine is a pure function shared by the server and SDK, with table-driven unit tests.
  • A statistical test shows a 25% rollout over 10,000 synthetic users lands within 23% to 27%.
  • If the flag service is unreachable, the SDK keeps serving the last known flags, or caller-provided defaults if it never loaded; this is tested.
  • Every flag change is recorded in an audit log (who, when, before, after).

Stretch goals (optional)

  • Multivariate flags (strings or JSON variations).
  • Push updates to SDKs over SSE instead of polling.
  • A small admin UI.

Constraints

  • Any language. Suggested: TypeScript (Node) or Go, with SQLite for storage.

Deliverables (every project)

  • Source code committed in this repository (the grader diffs against the first commit).
  • README.md that replaces the stub, with: how to install, run and test it (copy-pasteable commands); the decisions and trade-offs you made; what you would do next with more time; and a short note on how you used the AI agent (what you delegated, what you checked or rewrote).
  • Automated tests that run with a single command (npm test, pytest, go test ./... or cargo test).
  • No secrets in the repository. Anything configurable reads from environment variables with safe defaults.

Ground rules

  • The 24-hour clock is a window, not a workload. Stop at roughly the suggested effort, then write down what you would do next. A small, finished, tested core beats a large unfinished one.
  • Use the AI agent as much or as little as you like: every prompt is recorded and the report shows how it was used. You are judged on the result and on whether you understood and verified what the agent produced.
  • The work is yours. PraxisAI uses it only to produce your assessment report.