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.
- Scan QR
- Leave a review
- Tip
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 | Prototype as spec |
|---|---|
| Static mocks | Live prototype Real interactionsReal edge casesReal copy |
| Redlines | PM linked it as engineering's source of truth (replaces redlines, spec doc and handoff meeting) |
| Spec doc | |
| Handoff meeting | |
| A sprint of back-and-forth | Live link unblocked engineers mid-buildShared from a plane |
| Build | 8-PR vertical sliceIn production · Jul 2026 |
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.
- Search
- 19 feature areas
- Automated thumbnails
- Decision log per feature
Pulled from the hub
- Sales: Demos
- Marketing: Screenshots
- PMs: Links in tickets
- Engineering: Handoff spec
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.
- Linear
- Slack
- Notion
- Figma
- Todoist
- Gmail
Connected in every session
- Session 1 — loads CLAUDE.md and lessons.md.
- Session 2 — starts with the previous session's memory and rules, and adds to both.
- Session 3 — starts with everything so far and adds a new rule.
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.