Using AI to finally build a game I could only sketch a decade ago, taking a solo side-project from wireframe to a live production app in a month.

The Challenge: Take a game idea I'd sketched a decade ago and shelved because the build was beyond my skills, and ship it solo as a production web app. That meant building the brand, design system, product rules and a working backend from a solid wireframe foundation.

My Role: Concept, brand and logo, game rules, UX/UI design, prototype, playtesting and product direction. I worked with Claude Design for the design system and prototype, and Claude Code for the build. I managed the whole path from wireframe to live product.

Impact:

Wireframes to live product in about a month of early mornings. My previous app, Kaiku, took several months of full manual design in Figma, then a build in Builder.io.
Live now at lastonestanding.one with a working F1 game. Premier League and iPhone versions are next.
A two-stage playtest, first with 5 friends and then with 10+, caught real production bugs before they could put off the wider group.
A repeatable feature loop: user feedback to live feature in around three days of before-and-after-work sessions.

Ways of working: Solo, AI-paired throughout.

Brand: sketching and DALL-E exploration.
Design system and prototype: Claude Design.
Production build: Claude Code.
Backend: Supabase and Fly.io.

TA game I designed twice, ten years apart

Last One Standing started as a WhatsApp game with mates. Pick a winning team each week, get it wrong and you're out, and the last person standing takes the pot. At one company the kitty rolled up to £4k. I wireframed it a decade ago but couldn't build it. The tools weren't there, and neither was I.

A strong foundation, but everything still to build

The wireframes weren't rough. I'd thought the whole flow through: a navless app built around getting people through one clean flow rather than clicking round menus. The structure was there. I didn't have a dev team, a design system, or high-fidelity screens beyond a few I'd build myself.

The task wasn't starting from nothing. It was taking a solid structural foundation and turning it into a brand and a production-grade design system, good enough to put in front of real players with real stakes.

What changed since my last app

With Kaiku, I designed everything myself in Figma: a full design system, wires, flows and complete UI, before any of it was built. I then built it in Builder.io. It worked, but the design phase alone took months.

This time I made a deliberate call. I designed just three high-fidelity screens, the ones that best captured the brand and core function, and used them alongside the wireframes to test how far Claude Design could take it. Could it extrapolate a full design system and every screen the app needed from three screens and a thought-through flow?

It could. In places it pushed further than my own mocks, adding component states and layout decisions I hadn't specified. That freed me to spend my time on the game rules, the functionality and the product thinking.

Brand: AI got the idea out fast, but the mark is mine

Sketches and DALL-E explorations shaped the brand, including a logo built around a podium, with people climbing towards the top. I refined the final mark by hand rather than taking it from AI output.

Working as a design director

The best way to describe how I worked with Claude Design is as a design director. My starting point was to share an initial idea of the design and see what came back. Then I pushed it.

The most effective way to push was to explain what I needed and why, using verbs and descriptors that captured the brand. I'd say things like "this moment should feel decisive" or "this should feel like a podium being climbed, not a form being filled in". Feedback like that gave the AI the intent behind the design, not just the instruction. It produced better results than prescriptive notes like "make it bigger" or "move it left", and it kept new features in keeping with the rest of the app.

That's where the "95% there" comes from. It wasn't a magic first pass. It was me giving direction and rationale, and the AI iterating on it. The last 5% was my judgement: taste, edge cases and rules.

Design system as the foundation

Claude Design generated components, brand guidelines and a design system that would have taken me months to build in Figma. Once the brand and system were solid, I could stop worrying about consistency and focus fully on functionality and game rules.

I'd sketched a payment and bet flow early on but stepped back from it deliberately. Doing it properly (compliance, trust signals, real money handling) would have stalled the project before it proved itself. I phased it out: get the game mechanics right and live first, then return to payments with a proven product to design around.

From prototype to production

Handing the Claude Design package to Claude Code felt like starting again at first. A flat HTML prototype isn't a shippable app. But it soon became a working partnership: set tasks, framework first, then component detail, then game rules, then backend.

What took months with Kaiku took about a month of early mornings here.

Testing in two waves

I launched in two stages to keep the feedback useful:

Soft launch with 5 friends. This small group found the main bugs early, with few voices in the room.
Secondary launch to 10+. By then the biggest issues were fixed, so the wider group had a smooth experience and didn't lose interest.

Real play caught bugs that no code review would have: a pick showing the wrong colour, a "reigning champion" badge firing when nobody had won yet, and picks staying open after a new game started.

The new loop: from user feedback to live feature in three days

With the design system in place, the process for adding features got much shorter:

Get reactions from the group.
Decide on a feature.
Sketch it and screenshot it.
Give Claude Code the screenshot and a plain-English explanation of what it does and why.
Review, direct and refine, with me acting as design director.
Ship.

That's user research to live feature in around three days of before-and-after-work sessions.

Going straight to build also changed how I design. The feature is in my hands almost immediately, so I can feel the edge cases and the parts of the flow that don't work, far sooner than I would in a static mock. I'm testing the real thing, not a picture of it.

Design and build are merging

What I've learned is that designer and front-end developer roles are starting to merge. In a traditional process, the design is one artifact and the build is another, with a lossy handover between them. Here, the artifact is the live work. It starts as a sketch or prototype and becomes production code without being rebuilt, and design and dev can both feed into the same piece.

What stays distinctly design is direction: knowing what the product should feel like, giving feedback with the reasoning behind it, and spotting when something is off.

[Image: a diagram comparing "design then handover then build" with a single artifact evolving from sketch to live code]

What shipped

A React Native Web (Expo) PWA on Supabase and Fly.io, with:

a custom component library and sport-specific theming
a full motion spec with exact durations, easings and keyframes
an eight-template transactional email system
built for handoff to a real engineering pipeline, not just a portfolio render

What I'd do differently

Shared reference docs. I'd keep shared reference docs in GitHub as the single source of truth that both Claude Design and Claude Code read from and update. Right now a decision made in one doesn't reflect in the other. That's fine solo but risky as soon as a second person joins.
A shared canvas. I'd find a substitute for Figma's zoomed-out, whole-board view for working with another designer or a PO. Prototyping tools lose that shared space.

Takeaway

The idea didn't change in ten years. What changed was how much of the craft I could hand off without losing the judgement calls that matter.

Last One Standing