Designing a Website With Claude Code: The Figma-Free Workflow

The conversation about building a website changed the moment design and code stopped being different people's jobs. For most of the history of the modern web, those two disciplines required two different people, two different tools, and a translation process between them that could consume weeks. That was the default cost of bringing a professional digital presence into existence, and most business owners either paid it or settled for templates that announced they were using a template.

Paper and Claude Code do not improve that process. They eliminate it. The person with the idea is now the person who sees the live site, and the gap between those two moments has compressed from weeks to hours. This is not primarily a story about efficiency, though the efficiency gain is real and large. It is a story about who gets to ship a professional web presence, and the answer has changed in a way that most people outside the technical community have not yet absorbed.

I am Madhuranjan Kumar. I have been watching this change happen in real time, and what follows is my attempt to explain what it actually means for the business owners and creators who have been priced out of serious web development for years.

For a decade, the handoff was the most expensive part

The design-to-development handoff has always been the friction point where money, time, and creative intentions went to slow down. A designer works in an environment built around visual thinking: they manipulate elements, adjust spacing, evaluate layouts through direct interaction with a canvas that responds to their eye and judgment. A developer works in an environment built around code: they write markup and logic, reason about behavior and state, build systems that produce visual outputs but do not start from them.

The translation between those two environments was never automatic, never free, and never fast. In the best cases, a designer and developer with a long working relationship could execute a handoff cleanly because they had developed a shared language over time. They knew each other's assumptions. The designer understood what was easy and expensive to implement. The developer could read the intent behind design choices that had not been precisely specified.

In the average case, which is the case for any business owner or creator engaging through the open market, the handoff involved misinterpretations, revision requests, scope debates, and timeline delays that the person who commissioned the work had no leverage to resolve because they did not understand the technical side of the translation well enough to adjudicate it.

The cost numbers are familiar to anyone who has tried to hire through the market recently. A professionally designed and developed website from a freelance team costs between $3,000 and $15,000 for a project of moderate scope, and the timeline for delivery runs between four and eight weeks in a standard engagement. Those numbers reflect labor, but they also reflect the translation overhead: the back-and-forth between what was intended and what was built, the revision cycles when the implementation did not match the design, the project management layer that neither side wanted to pay for but both sides needed to navigate the process.

The experience for the person who commissioned the work was one of sustained opacity. They wanted to see their idea become real. The process gave them a sequence of intermediary outputs: wireframes, mockups, staging links, iteration cycles. Each required them to evaluate the translation rather than the idea itself. Every time something was not right, the question was whether the problem was in the design, in the implementation, or in the communication between the two, and answering that question required skills the business owner rarely had and had not been hired to provide.

Paper removes the translation layer, not just the timeline

Paper is a design canvas built specifically to be operated by AI agents through an API rather than by a human hand through a visual interface. This is a foundational architectural difference from every design tool that preceded it.

When Claude Code connects to Paper through an MCP server, it can read the current state of a design board, place elements, adjust spacing, modify typography, iterate on layout, all through the same conversational interface that is also used to write application code. The design session and the development session can happen in sequence within the same conversation, driven by the same natural language input, producing outputs that are directly connected rather than being translated between each other.

The initial setup required one session reset after installing the MCP server. After that, the connection was stable. What the working session looks like is this: you describe what you want, Claude Code creates it in Paper, you respond to what you see, Claude Code revises. You can ask for three variations of the same concept and choose the one that matches what you had in mind. You can ask for a change across all boards in a single prompt, and the change propagates. You can describe a specific functional component in one sentence and watch it appear as a designed element.

When the design reaches the state you want, Claude Code reads the finished boards and writes the React application that implements them. The design is not a specification document that a developer must interpret. It is a direct input to the code. The intent flows through without the translation step.

The thing this removes is not primarily time, though hours replace weeks. What it removes is the dependency. The business owner or creator who has an idea for a website no longer needs to find a designer who can translate that idea into a visual artifact, then find a developer who can translate that artifact into a working application, then manage the relationship between those two people through a revision cycle that neither of them controls completely. That entire dependency structure is gone. The person with the idea is the only person in the process.

How a wedding photographer built her entire site in a single evening

The clearest illustration of what this means in concrete terms is a wedding photographer who had been working from a site she set up on a template platform eight years earlier. The site did the job technically. It showed her portfolio. It had a contact form. But it did not represent her current aesthetic or her current level of work, and she had been meaning to redesign it for two years without finding either the budget to hire a team or the time to learn a new technical platform well enough to do it herself.

She came into the session with two reference images. One was a layout she had found on another photographer's site that represented the structural approach she wanted: the ratio of image to text, the navigation style, the way the portfolio was organized. The other was a page from her own portfolio that contained the specific images and copy she wanted to use. Those two images were the entire brief.

She uploaded them and asked for three variations. The first round produced three distinct interpretations of the brief. She eliminated one immediately, asked for a specific adjustment to the whitespace treatment in another, and selected the third as the foundation for the remaining boards. Over the next hour she built out the remaining sections of the site through individual prompts that were closer to creative notes than technical specifications.

"Make this feel more editorial and less commercial." "The contact section should be warmer; it's too formal right now." "The about page should lead with the image rather than the text block; the image is what I want people to see first." Each prompt produced a revised board within seconds. The revision cycle that would have consumed multiple email exchanges and days of calendar time in a traditional engagement was running in real time.

When the design was complete across four boards, Claude Code read the boards and wrote the React application. She reviewed the output running on localhost, asked for two adjustments to how the mobile layout handled the portfolio grid, and pushed the site to a Vercel deployment through the CLI with her GitHub repository connected. The site was live on her custom domain by the end of the evening.

Two years of "meaning to update the site" compressed into a single session. The work itself was not trivial; the creative decisions required genuine thought and judgment. But the thing that had been making those decisions impossible to act on, the dependency on a team, the budget, the timeline, the translation overhead, was removed. The only thing standing between her intention and the live site was the quality of her creative clarity.

The comparison that matters is not speed. It is cost. A professional redesign through a freelance team would have cost somewhere between $3,000 and $8,000 for a photographer's portfolio site of that scope. It would have required weeks of calendar time and a revision cycle she had no guarantee of winning. The outcome she would have received, assuming a skilled team and a smooth process, would have been roughly equivalent to what she built in an evening.

Updates after the fact: one sentence to the same conversation. Add a new portfolio section: one sentence. Change the navigation structure: one prompt. Adjust the homepage copy after she decided it was too formal: one revision cycle measured in seconds rather than the invoice that would accompany the same request to a freelance developer.

The question is no longer who can afford to ship; it is who bothers to start

For years, the design-to-development handoff was a filter. It filtered for people with either the budget to hire a competent team, which means something in the range of $3,000 to $15,000 and the organizational capacity to manage the project, or the technical skills to function competently in both the design and development roles simultaneously, which describes a small and specific category of people.

Everyone who fell outside those two categories was left with template platforms. Template platforms have improved significantly over the years. They are faster, they have more design flexibility, they are cheaper to operate. But they communicate something that professional presentations should not communicate: that the site was built within constraints rather than to a vision. They have a ceiling on what they can express, and skilled observers can see that ceiling.

That filter is gone. The constraint that rationed access to professional web presence to people with specific technical skills or significant budgets has been removed by a workflow that did not exist two years ago.

What remains as the differentiator is creative clarity. Do you know what you want? Can you describe it in language specific enough to produce a useful result? Can you evaluate what you see and direct the iteration intelligently? These are creative skills, not technical ones. They are skills that business owners, photographers, consultants, coaches, and small shop operators have developed through years of producing work and presenting it to the world. They are the skills that the technical barrier had been preventing from expressing themselves in the quality of the thing the world saw when it looked at those businesses.

I have watched multiple non-technical people complete this workflow in recent months. All of them ended the session with a live site that accurately represented their work and their aesthetic. None of them had been able to afford the freelance engagement that would have been their alternative. All of them described the experience in similar terms: they described getting something they had been planning to get around to eventually, and now it was done.

There is a secondary effect that is easy to underestimate. When the cost of building a site is measured in an evening rather than in $8,000 and eight weeks, the relationship between the owner and the site changes. Changes that previously required an invoice, a scope discussion, a timeline negotiation, and a round of revisions now require a sentence. The site becomes something that evolves continuously rather than something that is built once and left alone because changing it costs too much.

For the photographer, this meant updating her portfolio section every few months rather than every few years. New work goes in, older work comes out. The homepage copy shifts to reflect how her approach has evolved. The about section changes when something significant happens that she wants her clients to know. The site stays current because the cost of keeping it current has dropped below the threshold at which she would decide not to bother.

This is not a minor quality-of-life improvement. A website that reflects the current state of your work and your positioning is a different sales asset than a website that reflects where you were two years ago and has silently drifted out of alignment with what you currently offer. The drift is invisible to the owner who built it once and stopped paying attention. It is not invisible to the prospective client who visits and finds that the service described does not quite match the conversation they just had.

The question of who can build a professional web presence has been answered. The question of who maintains one is answered by the same change. Both are now determined by the same factor: whether the person with the idea has enough creative clarity to direct the conversation. The technical barrier is gone. The budget barrier is gone. What remains is the intention to start, and that is a barrier that the tools cannot remove for you.

The conversation about who can build a professional web presence has changed. Most of the people who would benefit from that change have not heard about it yet. The capability is there, the workflow is available, and the majority of the people who would benefit from it are still operating on the assumption that the old constraints apply. They do not. The question is no longer who can afford to ship a professional site. It is who has enough creative clarity about what they want to actually start the conversation, and who has the discipline to keep it current once it is live.