Skip to content

Prototypes as the spec

Company
Personal
Year
2025–2026
Role
Designer + builder
Focus
AI, Workflow, Desktop

How working prototypes replaced Figma as the engineering handoff spec — and closed deals along the way.

Working prototypes shipped
~50
Production slice from one prototype
8 PRs
CEO demo, 400-hotel chain
24 hrs
Built the same way
This site

Overview

In February 2026, the CEO asked for a demo for a 400-hotel chain. The sales call was in 24 hours. I shipped a working prototype that night: a QR → review → tipping flow, localized and in their brand. The next morning I iterated the payment and review routing while the sales cycle ran.

The CEO asked for a demo, with the sales call 24 hours away. A working prototype of the flow shipped that night, and its payment and review routing were iterated the next morning.

  1. Scan QR
  2. Leave a review
  3. Tip
Fig. 1A working flow, not mocks, built for a sales call in 24 hours

That turnaround isn't a party trick — it's how I work. In my last year at Canary I shipped roughly 50 working prototypes on a personal hub, and they repeatedly replaced Figma as the engineering handoff spec. This page is the receipts.

Shipped from the Prototype

In July 2026, a segmentation redesign shipped to production as an 8-PR vertical slice built directly from my prototype. The PM linked the prototype as engineering's source of truth — at one point unblocking engineers mid-build by sharing the live prototype URL while I was on a plane.

No redlines, no spec doc, no handoff meeting. The engineers built what the prototype had already proved: real interactions, real edge cases, real copy. When the spec is something you can click, the ambiguity that normally fills a sprint of back-and-forth just isn't there.

Static handoff and prototype as spec, compared stage by stage
Static handoffPrototype as spec
Static mocksLive prototype
Real interactionsReal edge casesReal copy
RedlinesPM linked it as engineering's source of truth (replaces redlines, spec doc and handoff meeting)
Spec doc
Handoff meeting
A sprint of back-and-forthLive link unblocked engineers mid-buildShared from a plane
Build8-PR vertical sliceIn production · Jul 2026
Fig. 2One clickable spec replaced redlines, spec doc and handoff meeting

The Code Is the Design

When a European hotel chain named a service-request integration their #1 deal-blocking feature, I designed the guest service-request flow as working code instead of static mocks: a 5-step wizard engineers built production from directly.

The design brief shipped with evidence tables and a funnel-completion target above 60%, but the artifact that mattered was the running flow. The pattern extended again in July 2026 to a second service-request integration, covering a meaningfully larger share of the ticketing base.

Scaling the Practice

The prototypes live on one Next.js hub — a searchable landing grid across 19 feature areas, automated thumbnails, shared design-system components, and per-feature decision logs. Sales pulled demos from it. Marketing pulled screenshots. PMs linked it in tickets.

  1. Search
  2. 19 feature areas
  3. Automated thumbnails
  4. Decision log per feature

Pulled from the hub

  • Sales: Demos
  • Marketing: Screenshots
  • PMs: Links in tickets
  • Engineering: Handoff spec
Fig. 3One hub of ~50 prototypes that other teams pulled from

In February 2026 I wrote the org's “Prototyping with Claude” playbook — repo architecture, prompting principles, guardrails, and the MCP toolchain — so the practice wouldn't stay a one-person trick. Exec leadership named me ahead of the org's adoption curve at the March 2026 EPD All Hands, and I mentored designers, PMs, and marketing designers on the workflow.

The Practice Underneath

None of this is a magic prompt — it's an environment. Claude Code runs in the terminal next to my editor, with persistent per-project memory: every project carries a CLAUDE.md with its conventions, gotchas, and current state, so each session picks up where the last one left off.

MCP integrations connect it to my actual tools — Linear, Slack, Notion, Figma, Todoist, Gmail — so morning triage happens in one conversation instead of six tabs. And a running lessons.md turns every mistake into a one-line rule tied to a specific failure, so errors don't repeat across sessions. It compounds.

MCP
  • Linear
  • Slack
  • Notion
  • Figma
  • Todoist
  • Gmail

Connected in every session

Claude Code
CLAUDE.md
Conventions, gotchas, current state
lessons.md
Each mistake becomes a one-line rule
  1. Session 1 — loads CLAUDE.md and lessons.md.
  2. Session 2 — starts with the previous session's memory and rules, and adds to both.
  3. Session 3 — starts with everything so far and adds a new rule.
Fig. 4Each session starts with what the last one learned

This portfolio is the same practice pointed at a personal project — the scroll animations, the theme system, the chat bar you might be using right now. I design every decision; AI removes the distance between the idea and the working thing.

What I've Learned

Where AI helps most

Scaffolding and boilerplate, debugging and tracing errors, exploring unfamiliar codebases, translating design decisions into code, automating repetitive workflows, and maintaining context across long-running projects.

Where human judgment is irreplaceable

Taste, prioritization, knowing what to cut, understanding user psychology, navigating ambiguity, making tradeoffs between competing goals, and deciding when something is good enough to ship.

The compound effect

The biggest value isn't any single interaction — it's the accumulation. Persistent context means each session builds on the last. Logged lessons mean the same mistakes don't repeat. Connected tools mean less time gathering context and more time making decisions. It's a practice, not a prompt.