Claude Design to code is a shorter trip than any design handoff you have lived through, because the design already is code: a project of HTML pages, React components, and a stylesheet of design tokens. Getting from there to a live website on your own domain takes one of three routes. Static route: take the HTML, consolidate it into plain files, deploy free. WordPress route: translate the sections into your theme, which is what we did on our own homepage. Or the flat-fee route, where you hand us the design link and we ship it. This guide walks all three, with the gotchas we hit doing it for real.
Quick scene-setting for anyone who landed here first: Claude Design is Claude’s visual design workspace, and we covered the design half of the workflow, briefs, art direction, tokens, in how to design a website with Claude Design. This post starts where that one ends, with a finished design project and a business owner asking the only question that matters: how does this get on my domain, as of September 2026?
What is actually in a Claude Design project?
Open a project and you will find real files, and knowing what each one is turns the handoff from scary to mechanical. There is a tokens stylesheet, ours is a file called colors_and_type.css, holding every color, font, spacing step, and shadow as CSS variables. There are page files with the full markup of each screen. There are shared components, often as React JSX, plus the webfonts and any images you uploaded. The tokens file is the crown jewel: it is the design system as executable truth, and every route below starts by preserving it. Lose the tokens and you are eyeballing hex codes off screenshots like it is 2015.
Route one: the static site, code almost as-is
For a brochure site, landing page, or portfolio, the distance to production is short because the design output is already standards-based HTML and CSS. The work is consolidation, not translation. Merge the tokens stylesheet and the page styles, swap any React-rendered niceties for plain markup, wire the contact form to a form backend, and run the same pre-flight every well-built vibe coded site gets: read every line, test the form like a stranger, run Lighthouse, hunt invented details. Then deploy to a host whose free tier allows commercial use, Cloudflare Pages being our standing answer, and connect your ten-dollar domain.
The one real gotcha on this route is fonts. Design projects reference webfonts, and it is on you to load them properly in production: self-host the font files or use the Google Fonts link, but pick one, because a site that silently falls back to Times New Roman has lost most of what you designed. Second, smaller gotcha: image weight. Replace any working-file images with compressed versions before launch, or your beautiful design ships with a four-second load time.
Route two: WordPress, a translation rather than a port
This is the route we took on our own site, so the details are from the trenches. We designed a new homepage section in Claude Design, a full-width team photo banner with a stats strip, and moved it into our hand-built WordPress theme the same afternoon. The method that worked:
Map the tokens first. Our theme already used CSS variables, so step one was confirming the design’s token names and values matched the theme’s, colors, fonts, border widths, all of it. Ten minutes of comparison meant every later step was copy-adjust instead of rebuild. If your theme has no token layer, create one from the design’s stylesheet before touching any markup; it is an hour that repays itself the first time you restyle anything.
Translate structure, not syntax. The design section existed as a React component. We did not port React into WordPress. We read the component as a spec, its grid, its spacing, its responsive breakpoints, and wrote the same structure as PHP template markup with a scoped style block, the way the rest of the theme is built. The design tells you what; your theme’s conventions tell you how.
Move assets deliberately. The team photo came over into the theme’s assets folder with a descriptive filename, width and height attributes for layout stability, lazy loading, and proper alt text. Boring, and exactly the stuff that separates a shipped section from a screenshot of one.
Verify like it is someone else’s code. Fresh screenshots at desktop and phone widths, a diff against the design, schema and SEO checks, error log clean. Same discipline as any build. The section went from design link to live on the homepage in a few hours, which is the honest benchmark for one section done carefully by someone who knows their theme.
Route three: Claude Code does the translation
Here is the part that still feels slightly illegal: Claude can implement its own designs. Claude Code, the terminal-based coding agent, can connect to your Claude Design project, read every file in it, tokens, pages, components, and implement the design directly into your codebase while matching your existing conventions. That is not a hypothetical; it is literally how the homepage section described above got built: we pointed Claude Code at the design project, told it which section to bring over, and reviewed the result. The designer and the developer are the same model looking at the same files, so nothing gets lost in the handoff, because there is no handoff.
The catch is the same catch as all vibe coding: the review pass is still the job. Claude Code implementing a Claude Design does excellent first-draft work, and it still needs a human to check the seams, run the site, and read the diff before anything ships. Automation moved the work from typing to judging. It did not remove the work.
A real example, with the clock running
The homepage section mentioned above, from design link to live, as it actually went. Ten minutes connecting the design project and reading its files to find the section and its dependencies. Ten minutes comparing the design tokens against the theme’s stylesheet, which matched because both came from the same design system, your mileage here decides the whole afternoon. About forty-five minutes writing the section as a PHP template with a scoped style block, image moved into theme assets with proper alt text and dimensions. Thirty minutes of verification: fresh desktop and mobile screenshots compared against the design, a missed border removed after a second look, error log checked. Then the part nobody budgets for and everybody should: another half hour wiring the section’s image into the site’s structured data so search engines and AI crawlers see it too.
Call it two focused hours for one section, done by someone who knows the theme cold, with review included. Scale that honestly: a five-page site is days, not minutes, and the demo-in-minutes crowd is showing you step three of seven. The design half genuinely takes an hour now. The shipping half still rewards knowing what you are doing, which is either your afternoon or our line of work.
Which route should you take?
| Your situation | Route | Cash cost | Realistic time |
|---|---|---|---|
| Landing page or brochure site, comfortable with files | Static, DIY | ~$10/yr domain | An afternoon |
| Existing WordPress site, one new section or page | WordPress translation | $0 DIY, or $60/hr with us | Hours per section |
| Whole designed site, want it built right | We build it flat-fee | $2,800 static / $5,800 WordPress | 3 to 10 days |
| Developer on the team | Claude Code + review | Existing subscriptions | Fastest of all |
The pattern across all four rows: the design is no longer the expensive part, and neither is the typing. What you are paying for, in money or in your own hours, is the judgment layer, token mapping, review, testing, the unglamorous fifteen percent that decides whether the thing actually works. That has been the honest economics of vibe coding a website all along; Claude Design just extends it to the pixels.
Claude Design to code: quick answers
Can Claude Code read a Claude Design project directly?
Yes. Claude Code connects to the design project and reads its files, the token stylesheet, pages, and components, then implements them in your codebase following your existing conventions. We have run this exact flow on our production site. You still review the output like any code you did not type yourself.
Do I need to know React to use a Claude Design export?
No. The React components are best treated as a precise spec of structure and behavior, not as code you must run. Static sites use the HTML and CSS directly, and WordPress builds translate the structure into PHP templates. The only people who should ship the React itself are teams already running a React stack.
How long does Claude Design to WordPress actually take?
With a theme that uses CSS variables and a developer who knows it: a few hours per section, a few days for a full site, including the review and testing that make it production work rather than a demo. Without a token layer in the theme, add a setup hour to create one. Anyone quoting minutes is skipping the part where somebody checks it.
What if I designed the site but cannot build it?
That is the exact gap our flat fees exist for. Send the design link with your notes, and we turn it into a live site with the code handed over on GitHub: $2,800 static, $5,800 WordPress, posted publicly like every price we charge. Small jobs, like one designed section into an existing site, bill at $60 an hour in half-hour increments.