Jikken: one rollout decision, four product surfaces

Case studyJikkenStudio start-up

Governing feature flags across four product surfaces

Feature flags start as simple switches, then become a policy read differently by engineers, product managers, application code and delivery pipelines. I designed and built Jikken to carry one rollout decision, unchanged, across a CLI, a dashboard, an SDK and a CI gate, and shipped the whole system myself in a matter of days.

A start-up of my practice: conceived, designed and built as my own product, not client work.

Launch the working prototype →

The product itself, live. Open it in a new tab.

What
A feature-flag governance system: one rollout decision, with its reason and audit trail, carried unchanged across a CLI, a dashboard, a typed SDK and a CI gate.
Who
Me, as designer and engineer, for engineers, product managers and release pipelines that share one rollout decision.
Why
Every switch that ships becomes a policy interpreted differently by engineers, product code and pipelines, and semantic drift between those readings is how an unsafe rollout still reaches production.
How
I built one deterministic engine, ran it in three runtimes, then used an AI-assisted workflow, directing and verifying every step, to take the product from specification to deployed in days.
Where
My own product, live at jk.experienceplus.ai: a CLI, a dashboard, an SDK and a Supabase edge function all built and deployed by me.
When
2026, over several days from specification to a deployed product.

Live

Visit

4

Product surfaces

1

Shared engine

0–6

Defined exit codes

Days

Spec to deployed product

These are facts of the build, not user outcomes. I've been the only user so far, ahead of anyone else trying it.

The Jikken CLI showing a proposed feature-flag change that would remove access from three users.
The flow begins in the CLI, where a conflict is explained and returned as a real process exit code.Open the live app at jk.experienceplus.ai

Product walkthrough

Follow one proposed targeting change through the whole system: the first conflict in the CLI, the review in the dashboard, the response from the SDK and the CI gate that stops the unsafe deployment.

AI-narrated product walkthrough, 81 seconds

The problem

Feature flags start as simple switches. At scale, each switch becomes a policy interpreted by engineers, product managers, application code and delivery pipelines. The risk is not only a bad configuration. It is semantic drift: a change can look safe in one interface, ambiguous in another, and still reach production because each surface tells a different story.

I designed Jikken as a governance product for that gap. Before a rollout ships, it evaluates a proposed change against a representative audience, shows who gains or loses access, and assigns an allow, hold or needs-review verdict. The decision, with its reason and audit trail, then carries through every place it is consumed.

One decision, four surfaces

Jikken's flag portfolio showing rollout exposure and governance status across a list of feature flags.
The flag portfolio makes rollout exposure and governance status scannable before a reviewer opens a change.
Jikken's flag simulation view showing an audience decision count and per-user reasoning.
The simulation view connects the high-level verdict to provenance and per-user reasoning.

Design decisions

Consistency is the feature I designed hardest for. Green always means included, red always means excluded, yellow always means needs review. The field rollout_percentage is spelled the same way in every surface, and exit code 1 always means conflict. A simulation ID links the human-readable interface to the machine response, so a reviewer and an automated pipeline can point at the same event without translating between systems.

  • A deterministic, seeded TypeScript engine shared across the browser, Node and Supabase edge runtimes
  • Transparent decisions with reasons, source rules, audience provenance and tamper-evident history
  • Role-specific interfaces that preserve one underlying vocabulary and decision model
  • Actionable validation that names the failing field and suggests how to recover
  • A coherence test suite that fails the build when colors, terms, exit codes or engine copy drift
Jikken's simulation history showing an expanded audit record and decision detail.
The history view preserves an attributable, searchable record of every verdict.
Jikken's settings page showing the active data source, environments and authentication configuration.
Workspace settings make infrastructure and authentication state explicit instead of implicit.

I didn't want the SDK to reduce a governance decision to an opaque boolean, so it returns a typed result: the simulation ID, the verdict, the exit code, an audience summary and recovery guidance. A caller that only needs a gate can call isSafeToDeploy(); a more sophisticated integration can inspect the complete contract. Either way, the interface meets the consumer at the level of detail it needs without changing what the decision means.

Jikken's SDK contract example using a typed client to evaluate whether a deployment is safe.
The SDK asks the same safety question from application code and maps it directly to process behavior.
Jikken's SDK response showing a conflict verdict, exit code and audience summary.
Automation receives structured data rather than being forced to parse presentation text.

How it is built

I built Jikken as a TypeScript monorepo with six workspaces: a dependency-free shared decision engine, a Commander.js CLI, a React dashboard, a typed SDK, a guided product presentation and a portfolio site. The same engine runs in three environments, the browser, Node and a Deno-based Supabase edge function, so the product never reimplements its most important decision at any boundary.

The engine

A deterministic core

The shared engine is pure and seeded: no clock, no randomness, no environment variable can change a verdict. A stable FNV-1a hash assigns rollout buckets, so identical inputs produce identical audience decisions and exit codes on every runtime.

The boundary

Browser, machine and pipeline boundaries

The dashboard uses the shared engine directly for instant feedback. An edge function exposes the same evaluation to the SDK and CI, authenticating machine and browser calls differently, and validating and capping every request at 500 users before it runs.

The guarantee

The thesis enforced in code

An integration suite makes coherence a release requirement: it checks that colors resolve to the same values everywhere, that CLI output matches the engine exactly, and that rollout_percentage keeps one spelling across the CLI, dashboard, SDK and shared types.

A continuous integration pipeline with the Jikken gate blocking a risky deployment.
The final surface consumes the same exit code and prevents an unsafe change from reaching production.

Built with an AI development workflow

I conceived, specified, designed, built, tested and deployed it end to end, with no separate product, design or engineering team. AI tools, including Claude Code, Codex and Gemma, worked as implementation collaborators inside a workflow I directed: write the specification, define the architecture and acceptance criteria, hand off bounded implementation tasks, inspect the running result, reject or revise anything incoherent, then verify the accepted work through code review, type checks, tests, builds and a direct walkthrough.

That workflow compressed the path from specification to deployed product to several days, but speed was never the definition of done. Human judgment set the product thesis, the system boundaries, the interaction model, the security posture and the release bar. Models accelerated production; I stayed accountable for every decision and for the integrated system that shipped.

What shipped

Jikken shipped as a working monorepo: a CLI, a React dashboard, a TypeScript SDK, a Supabase edge function, a GitHub Actions gate, a guided product presentation and integration tests that enforce coherence across all of it. The walkthrough above follows one targeting conflict from the terminal to the production gate.