An AI-first design process that won a national security pitch — and matured into a governed product.

Win a national security pitch with a full functional prototype built by four designers and zero engineers — then mature that prototype into eBCAS 2.0, a production-ready platform on a governed design system.

Two processes, one product

The work ran in two phases, and the story is the process maturing between them.

The first process optimized for one thing: a functional prototype good enough to win the pitch, in weeks. The second process traded that raw speed for governance — turning the prototype into eBCAS 2.0, a product built on a real, canonical design system. The interesting decisions live in the gap between them.

Phase 1 — the functional prototype

The brief grew mid-flight: from a slice of one module to a full working prototype for a room of senior civil servants and the agency's own engineering leadership — people who click into edge cases. We had weeks, not months, and multiple personas to cover.

Three build paths sat in front of me. The trade-off was real money against real time.

We inverted the source of truth: plan in Claude Code, build in code against our design system, refine in code, then push the refined screens to Figma via MCP. To move fast enough, the prototype stood on a forked Make Kit — roughly 35 components lifted from a vendor library at peak. It got the happy flows clickable in days. That was the right call to win the room, and a debt we knew we'd pay.

Design directions for the core interaction

The hardest part of the prototype wasn't a screen — it was the two-persona review loop: a Director-level reviewer reads a security programme submitted by a regulated entity, leaves observations on specific clauses, the entity responds, back and forth with an audit trail until approved or returned. The interaction is the design.

I explored three ways to hold that conversation before committing.

Inline annotations shipped because the reviewer's mental model is the document, not a task list — and field research at airports confirmed reviewers wanted to stay in the clause they were reading. The queue's triage strength came back later as a secondary view rather than the primary frame.

Phase 2 — maturing into eBCAS 2.0

We won. And winning is exactly when the forked-kit debt comes due. eBCAS 2.0 is the prototype brought under governance: the same flows, rebuilt on a canonical design system instead of a vendor fork.

This is the core trade-off of the whole project.

We're migrating on-touch — a screen comes under governance the next time anyone edits it — which spreads the cost instead of stopping the world. The right call, but I'd tell my past self to plan for it from week one rather than meet it at the finish line.

How the governed process holds together

The leverage in Phase 2 isn't a clever prompt — it's a Claude Code skill acting as the constraint layer between the AI and the design system. Three rules carry most of the weight.

Four of us shipped eBCAS 2.0 through GitHub with pull-request review; two PMs ran field research at airports in parallel, and pain points fed the flows the same week we heard them. I started solo and trained three designers as the velocity became visible — less here are our components, more here is how to think about working with AI.

Outcome — and what it cost

Leadership's reaction landed where we wanted it: this isn't a prototype, it's closer to production than we expected at this stage. We won. The proof was in the sequencing — engineer allocation began after the win, against frontend code engineers can extend rather than a clickable mockup they'd rebuild from scratch.

The win came with a bill, and it's the honest centre of this story: the speed that won the pitch was borrowed against a forked kit, and eBCAS 2.0 is us paying it back deliberately. The skill itself needed iteration too — the first session-mode lock was too restrictive, the first dependency walk missed icon libraries. Building this kind of skill is a design problem, not a one-time setup.