Use Case · Product

Feature flags on the Software Lifecycle Cloud

Feature flags on KERNSTACK are a table and a habit, not another SaaS: flag keys with their cohort rules live in a table your functions read at request time, rollout changes are row updates with an author and a timestamp, and exposure — who actually saw the variant — is logged into the same project that will judge the experiment. Stated plainly: this is the build-it-yourself pattern, for teams whose flagging needs are real but not a platform.

NoSQL TablesFunctions (WASM)Product Analytics
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

The engineering bottleneck with assembled stacks

Product managers ship to a named cohort first, and the flag SaaS that enables it becomes one more console, one more SDK on the critical path, one more bill — whose console nobody opens between incidents, and whose outage mode is a decision your vendor makes for you. Meanwhile the exposure data that proves a rollout worked sits in the vendor’s silo, away from the product outcomes it should be judged against.

Architecture on the Software Lifecycle Cloud

A flags table keyed by flag name carries the rule: off, on, or a cohort definition (tenant list, percentage bucket, region). Functions evaluate the rule from the row — cached briefly in-process — and write an exposure event next to the product’s own event tables. Changing a rollout is a row change through your admin surface, recorded with who and when; killing a bad flag is the same operation at higher speed.

The kill switch is the feature

Most flag value concentrates in one moment: something is wrong and a named person must turn it off now, from their phone, without a deploy. A table row delivers that — one update, effective on the next read — with the audit detail (who, when, previous value) that the incident review will ask for. Ceremony around the other 364 days is kept deliberately thin.

  • Evaluation happens in your functions; no third-party SDK sits in the request path
  • Exposure events land beside product outcomes, so rollout judgement uses one dataset
  • Every flag change carries author and timestamp — the incident review writes itself

When a flag platform honestly wins

Dozens of flags, non-engineer owners, targeting UIs, and cross-platform consistency are a real product — if that is your shape, rent it. The KERNSTACK pattern serves the common middle: a handful of consequential flags owned by the team that ships the code, where an extra vendor is heavier than the table it replaces.

FAQ

Frequently asked questions

On the next read of the row — effectively immediately, or within your handler’s brief in-process cache window if you add one. There is no deploy and no vendor sync between the decision and the effect.

Whoever your admin surface allows, with every change recorded by author and timestamp in the table itself. Non-engineers can be given a narrow admin page over exactly these rows — that page is an afternoon of work in the same project.

Yes. Rules are data: explicit tenant lists, hashed percentage buckets, region matches. Evaluation is deterministic from the subject key, so a user does not flicker between variants between requests.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Category PillarThe Software Lifecycle CloudWhy people and agents build, deploy, and operate on a single vertically integrated stack.Service · DataTablesServerless key-value and document tablesService · ComputeFunctionsGo WebAssembly HTTP handlersService · InsightAnalyticsProduct analytics on the same fabricIndustry SolutionFinTech Cloud SolutionsFinTech products on KERNSTACK keep the records money moves through — accounts, payment events, approvals, invoice files — in one declared project in a European zone. The pattern fintech teams actually need is rarely exotic: an event trail that cannot be quietly edited, approvals with names on them, retention that is enforced by a job, and a bill that does not require a finance engineer to interpret.Use Case · ProductExperiment assignmentAssignment is a pure function of the subject key and the experiment’s salt — stable across requests, no coordination needed. The function records the assignment row once and serves the variant; outcome handlers were already writing events, which now simply carry the experiment id the assignment returned. Analysis reads assignments and outcomes from neighbouring tables with the same keys.Use Case · AgenciesAgency client deliveryThe studio’s delivery shape is a template stack.json: gateway, functions or workers in the client’s stack languages, tables, buckets, and apps under one target per client, on European infrastructure the studio can name in the pitch. Previews run the same declaration; the client’s approval happens in the bound conversation with a live link. Every client’s meter is separate by construction — the studio sees delivery cost per client without allocation spreadsheets.Use Case · AgentsAgent operations consoleThe raw material already exists in the project: hosted git lists branches including agent/<id>, each agent branch maps to its environment, and every deploy begins as a plan a person approved. The console view arranges that material — branch, environment URL, plan summary, approval state — into the board engineering managers actually ask for, with conversations and board topics carrying the discussion around each run.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →