Nobody Asks How You Got to Disney World: I Built a 75-Screen Product With Claude Design & Claude Code in 2 days

A month ago I wrote that Claude Design wasn't the Figma killer everyone expected. Then I designed and shipped an entire 75-screen product with it. Here's what changed my mind — and what didn't.

I run a design and engineering agency focused on cybersecurity. My team has shipped more than 70 products, and we live in Figma — we spend tens of thousands of dollars a year on it. So I'm fluent in the design side. But I also came up as a software engineer, and that combination is exactly why Claude Design appeals to me: I can design something with AI and then turn the concept into a real, production product without the usual handoff tax.

About a month ago I wrote a post arguing that Claude Design wasn't the Figma killer people were bracing for. I still agree with most of it. But Claude Design has come a long way, and I just ran an experiment that moved me. Let me start with where that earlier article holds up, then where it doesn't.

The HTML engine, revisited

The core argument last time was that Claude Design is, underneath, an HTML engine. Anthropic has been explicit that HTML is the way — they walked away from Markdown and leaned all the way in. That has consequences.

The one that bit me first: if your logo has special characters, it'll quietly swap them for text in the nearest matching font. For most people that's fine. For a design agency, where things have to be pixel-perfect, it isn't. You can solve it by handing over an actual vector logo — but then you're still designing that vector in Figma or Illustrator, which is the whole point I was poking at.

The other is hard front-end shapes. Dual-slanted, double-edged corners on a button? It drops them every single time. In fairness, that's a genuinely fiddly thing to pull off in code, so I'm not shocked. But it's a real limitation, and I'll come back to why it ends up mattering less than you'd think.

So I gave it a real build

Critiques are cheap, so I wanted to actually stress-test it. I set out to build something outside cybersecurity — not a Hello World, but a product with real complexity and enterprise-shaped problems I could measure against the way we build in Figma every day.

I landed on a pitch-deck sharing platform, because it scratches a problem I live with. We build a lot of decks; export them to PowerPoint and they turn to garbage, export to PDF and they balloon into flattened, unmaintainable image dumps. So: a lightweight tool that turns any PowerPoint or Figma deck into a clean, shareable PDF, then borrows the logic of web analytics to show who opened it, how long they spent per slide, with light AI flagging whether a slide is landing. The product itself isn't really the point here — it was the test track. If you are interested in the product, we launched it this week: https://deky.app

Starting at the destination

I gave Claude Design the thesis and said: let's start with the dashboard. I'm a visual thinker, so I start at the first point of real value, not onboarding. Solve the business problem first; circle back to onboarding once the hard parts work.

It immediately produced content, layout, vectors — a full dashboard that would have taken me hours to assemble and reason through by hand. One prompt. Then it gave me five distinct design directions, also in one prompt.

That's where it clicked. Figma is just the vehicle we use to get to Disney World.

The vehicle and the destination

If I told you my family went to Disney World this weekend, you'd ask what rides we went on and whether we had a good time. You would not ask how we got there. The destination is the point. The only time the vehicle comes up is when it's novel — if I said we took a self-driving Waymo and I slept the whole way, sure, you'd ask about that. But normally, nobody cares about the car.

Tools are the same. The whole design-tool category is quietly getting repriced in people's heads, because they're starting to see the tools as the vehicle, not the destination. That's not a knock on any of them. Framer still has real uses — FigJam might be the thing I reach for most right now, for brainstorming before I hand the ideas to Claude. But hand-building complex design systems with bespoke custom design is enormously time-consuming, and the ROI keeps dropping.

The fading craft

There's a bigger thing underneath this, and it's uncomfortable: the craft is fading. AI is taking over the part of design people used to do by hand.

I don't think this is new. It's the industrial revolution again. People used to make things by hand; then machines did it faster, cheaper, and more consistently, and on balance society came out ahead — things that used to be expensive became cheap. The cost was the craft. Artisan handwork didn't vanish, but it became a novelty rather than a business model.

And here's the thing about the destination: at the end of the day, your users mostly don't care whether a button has a perfect double-slanted corner — the exact detail Claude Design drops every time. They care whether the product works, whether it does what it says, whether it does it well. When it does, the software becomes transparent. The user stops fighting it. AI got me to that point fast.

Letting it build the kitchen sink

I decided to design every screen and every flow, even for capabilities I had no intention of building yet. There's a meme about this: traditional software starts with a few things and builds up; with AI you start with the kitchen sink and pull away. This meme is a perfect example of that:

That was exactly it. I let it run, and it wired up features I ultimately didn't ship — and it did a great job of it.

Worth being honest about my starting position: I build these products every day, and I've done it for almost 20 years. I already know which screens a product like this needs. I wasn't learning the domain — I was measuring how much faster AI could move through work I already understood.

The result: a complete product design, 75 screens, in about six to eight hours. Call it one day, with the usual distractions and one stop when I hit a token limit. One day for the entire product.

The part I don't think many people are doing yet

Here's the move I'm most proud of. By the end, Claude Design held the entire context of the product — every screen, every interaction, every flow. It was effectively a living requirements document, except instead of written specs, the spec was the actual interface.

So I had it build the architecture diagrams, the site map, and every flow — including auth and payments — straight from that context. It already knew how all the pieces fit together, so it could describe the system better than I could from memory.

Then I handed those documents to Claude Code: take these architecture diagrams and translate them into specs. Every route, every flow, specced out in one command. I told it explicitly to read the architecture diagram and write the target architecture into its CLAUDE.md. Now I had an architecture document with all the route flows living right next to the code. Heres what that looks like in reality:

Day two: building it

The next day, about eight hours, I built it. Page by page, the same way I'd designed it. Claude, initialize the project, pull this from the design.

Dashboard first, then the upload screen, then the next — screen by screen, flow by flow. I leaned on Clerk for auth and Stripe for billing.

One small story that captures how fast this space moves: I needed transactional email. I asked Claude whether Cloudflare had an email service. It said no and recommended Resend, so I wired up Resend. The next week I logged into Cloudflare and there was transactional email sitting right there in the dashboard. I ripped Resend out. You can build something one day and find a better primitive waiting for you the next.

I didn't implement everything Claude Design dreamed up. I had to wrestle it down a bit — great feature set, but for an MVP the job is to ship.

And this was the first app I've ever fully coded hands-off-keyboard, on purpose. I wrote zero lines. I didn't even open my editor. The entire product was written by Claude.

The part I didn't see coming

Then I started using it. And mostly it worked — it did what I needed. But there were rough edges everywhere: buttons that never got hooked up, flows that dead-ended. So I spent the next week, an hour here and there between meetings, getting feedback from friends, tweaking, removing.

By the end I'd spent about as much time refining the product as I'd spent building it.

That surprised me, and I think I understand why. When I build something by hand, it's basically done when it's done — the function works the way I want, because I was thinking through every flow as I wrote it, checking that the pieces lined up. When Claude builds, it's building. It reasons about the code, but it isn't manually walking every interaction the way a human does. The verification I normally do continuously, while building, became a separate phase afterward.

So where does this leave us

We can now go from a concept and a design to a working production prototype astonishingly fast. But that's the word: prototype. You're going to spend as much time tweaking as you spent building. That's roughly the inverse of how traditional development feels, and it's worth sitting with.

When you see people posting I built this whole thing this weekend, poke at it. You'll usually find the same pattern — a prototype with rough edges, buttons that look like they work and don't. That's not a dunk. It's just the honest state of the art, and naming it matters.

Figma isn't going anywhere. Traditional designers will keep reaching for it precisely because it gives them pixel-perfect control — they're pixel-perfect people, and that instinct is valuable. But for getting from idea to something real, the vehicle matters less every month.

Because when I tell you I went to Disney World, you're not going to ask how I got there. You're going to ask how the trip was.

While I have you here, check out the product it built: https://deky.app