PART 2: USE CASES

Chapter 5: Front-End Design and Web Development#

What It Is#

Claude Code, equipped with the frontend-design plugin, can build complete, production-quality websites from a text brief. Not wireframes. Not mockups. Actual functioning websites with responsive design, animations, interactive elements, and professional visual quality — deployed to the internet on free hosting.

This is the capability that surprises people most. You describe a website in plain English — the sections you want, the content to include, the aesthetic you are going for — and Claude produces a fully designed, multi-page web experience. You then iterate through conversation: “make the hero bigger,” “change the color scheme to dark mode,” “add a newsletter signup form.” Each round of feedback produces an updated, working website.

For non-technical professionals, this is the closest thing to a superpower. You can prototype ideas, build landing pages, create portfolio sites, design event pages, and produce content showcases — all without a designer or developer.

Why It Matters for Non-Technical Professionals#

Every professional project eventually needs a web presence. A new initiative needs a landing page. An event needs a registration site. A research report needs an interactive showcase. A personal brand needs a portfolio. A content series needs a home.

Traditionally, these web projects require coordination between three roles: a designer (to create the visual design), a developer (to build it), and the project owner (to provide content and direction). This triangle creates delays, dependencies, and communication overhead.

With Claude Code, you are all three. You provide the direction and content, and Claude handles the design and development simultaneously. The iteration loop that normally takes days (brief designer, wait for mockup, give feedback, wait for revision, hand to developer, wait for build, give feedback again) compresses into minutes.

I have built over a dozen websites using Claude Code. Multi-section editorial content hubs, IPO commemoration showcases, sector thesis infographic sites, year-end newsletter microsites, and my own personal homepage with a content management system. Every one of them was designed and deployed through conversation alone.

What You Need#

Essential: - frontend-design plugin — This is non-negotiable. It dramatically elevates the design quality.

frontend-design is my default and where every build should start. Two newer skills are worth knowing once you outgrow the default: a “taste” skill (design-taste-frontend) that pushes designs away from the templated, AI-generated look toward something that reads as deliberately art-directed, and impeccable, which audits and polishes an interface you have already built — tightening hierarchy, spacing, and motion rather than starting from scratch. Reach for the taste skill when a frontend-design result feels generic, and for impeccable when you want to level up an existing page instead of rebuilding it.

• playwright plugin/MCP — For visual verification (Claude takes screenshots of what it builds)
• commit-commands plugin — For pushing to GitHub

For component-based development: - shadcn MCP — Connects Claude Code to the live shadcn/ui component registry, giving it access to hundreds of beautifully designed, open-source UI components. Instead of Claude generating components from its training data (which can be outdated), the MCP pulls current component APIs, props, and usage patterns directly from the registry. Install with: claude mcp add --transport http shadcn https://www.shadcn.io/api/mcp. This is optional but highly recommended if you are building anything with React or Next.js — it turns “add a data table with sorting and filtering” from a vague request into a precise component installation.

For deployment: - A GitHub account (free) - A Vercel account (free tier is sufficient) - GitHub CLI (gh) — Claude installs this for you

Pre-approved permissions: - Bash(git init:*), Bash(git add:*), Bash(git commit:*), Bash(git push:*) - Bash(gh repo create:*), Bash(gh auth:*) - Bash(npm install:*) - Playwright browser actions (navigate, screenshot, etc.)

The Workflows#

Workflow 1: Building a Multi-Page Website from a Brief#

As a Claude prompt:

I want to build a comprehensive multi-page website for a content
property. Here are the details:

Purpose: A digital publication for a consumer brand with six
content pillars.

Pages needed:
1. Homepage — hero section, featured content cards, navigation to
   all pillars
2. Pillar pages (6 total):
   - "Farm to Table" — stories about sourcing and sustainability
   - "Kitchen Secrets" — recipes and cooking tips
   - "Curator's Guide" — product recommendations with editorial voice
   - "Behind the Scenes" — brand story and team profiles
   - "Know Your Ingredients" — educational content about what goes
     into products
   - "Community Stories" — customer stories and testimonials
3. Events page — upcoming and past events with registration links
4. Newsletter signup — email capture with a compelling value proposition

Design direction:
- Modern, editorial feel — like a digital magazine
- Warm color palette (earth tones, cream backgrounds)
- Excellent typography with clear hierarchy
- Mobile-responsive
- Smooth scroll transitions between sections

Please use the frontend-design skill.

What Claude does: 1. The frontend-design skill activates, providing Claude with detailed design principles 2. Claude creates the full file structure (HTML, CSS, JavaScript) 3. Builds each page with responsive layouts, consistent navigation, and the specified design direction 4. Sets up a local development server so you can preview the site 5. Takes screenshots using Playwright to show you the result

The iteration loop:

After the initial build, you iterate.

As a Claude prompt (iteration follow-up examples):

> The hero section is too short. Make it full-screen height.
> Change the "Farm to Table" pillar card to use a green accent instead of brown.
> The navigation links are too small on mobile. Increase the tap target size.
> Add a YouTube video embed in the "Behind the Scenes" section.
> The newsletter signup needs a more compelling headline. Try something about "joining a community."

Each instruction produces an updated version. Claude edits the files, refreshes the preview, and takes a new screenshot. The cycle from feedback to updated preview is typically under a minute.

Real example: I built a complete multi-section editorial website for a consumer brand’s content property. It had seven content pillars, a homepage with featured content cards, YouTube embeds, a newsletter signup, and consistent navigation across all pages. The initial build took about twenty minutes. Over three more sessions (about two hours total), I refined the design, added content, and deployed it to the internet. A project that would traditionally take two to three weeks was done in an afternoon.

Workflow 2: The Iterative Design Process#

The most important skill in working with Claude Code for web design is knowing how to give visual feedback in text. Here is the framework I use:

Be specific about position: “Move the logo to the top-left” is better than “fix the logo placement.”

Reference existing design patterns: “Make the card layout look like Pinterest — a masonry grid with varying heights” is better than “make the cards more interesting.”

Use comparison: “I preferred Version 2’s color scheme but Version 3’s layout. Combine them.”

Describe the feeling: “This feels too corporate. Make it warmer and more inviting — think indie bookshop, not consulting firm.”

Point to specific elements: “The third section (the one with the team photos) needs more padding above and below.”

Request multiple options: “Show me two different hero designs — one with a full-bleed image background, one with a split layout (text left, image right).”

Real example: For an IPO commemoration website, I asked Claude to create four different homepage concepts. One used a carousel hero, another a unified mosaic, a third a horizontal scroll, and a fourth combined the best elements. I reviewed all four (Claude took screenshots of each), picked my favorite elements, and asked Claude to merge them into a final version. This “diverge then converge” approach consistently produces better designs than trying to get it right in one shot.

Workflow 2B: The Screenshot Verification Loop#

One of the most powerful design techniques in Claude Code is the self-correcting screenshot loop. Here is how it works:

1. Claude builds the website or updates a section
2. Claude uses Playwright to take a screenshot of the result
3. Claude examines the screenshot itself and identifies visual issues — misaligned elements, text overflow, broken responsiveness, inconsistent spacing
4. Claude fixes those issues without you having to point them out
5. Claude takes another screenshot to verify the fix

This loop can run automatically. When you include Playwright in your setup and tell Claude to “verify the design visually after every change,” it builds a self-correcting feedback mechanism. Claude catches problems that would be invisible in the code but obvious in a screenshot — overlapping text, images that did not load, buttons too close together, sections that look different than intended.

As a Claude prompt:

After every design change, take a Playwright screenshot at both
desktop (1440px) and mobile (375px) widths. Review the screenshots
yourself. If you see any visual issues — alignment problems,
overflow, spacing inconsistencies, broken layouts — fix them
before showing me the result.

This single instruction transforms Claude from a code generator into a visual designer that checks its own work.

The Design Tournament: Systematic Creative Exploration#

For important design projects, combine the screenshot loop with a tournament structure:

Round 1 — Diverge: Ask Claude to generate three fundamentally different design directions for the same brief. Not variations on a theme — genuinely different aesthetics, layouts, and approaches. Claude builds all three and takes screenshots of each.

Round 2 — Select: Review the screenshots. Pick the direction you like best — or cherry-pick elements from multiple directions (“I like Option A’s color scheme with Option C’s layout”).

Round 3 — Iterate: Ask Claude to generate three more variations based on your selected direction, each pushing the design in a slightly different way. Review again.

Round 4 — Refine: Take the winning variation and iterate on the details — spacing, typography, content, interactions.

This tournament approach systematically explores the creative space rather than settling for the first thing Claude produces. Each round narrows the design toward something you genuinely love, and the screenshot loop ensures every version is visually verified before you see it.

As a Claude prompt (design tournament template):

I want to explore three fundamentally different design directions
for this homepage. Each should have a distinct aesthetic:
1. A minimalist, clean direction with lots of whitespace
2. A bold, dark direction with strong typography
3. A warm, editorial direction with rich imagery

Build all three as separate HTML files. Take screenshots of each
at 1440px width. Do not settle for similar approaches — I want
genuinely different creative directions to choose from.

The Effects Lab: Audition Changes on a Throwaway Page#

Here is a habit that removes the fear of breaking a live site: never audition a new effect on the real files. Before I change anything visual on my homepage — a hover treatment, a hero animation — I ask for a throwaway lab page first.

Say to Claude:

Show me three options for this effect side by side on a separate
local page. Do not commit any changes.

Claude builds one disposable page with all the candidates running next to each other. I kill the weak directions fast — “option two is still bad, go with one” — and only the winner gets implemented on the actual site. Then the experiment file gets deleted.

I do this for every hero-image and animation change on my site. Exploration is free when it happens on a page nobody will ever see.

Workflow 3: GitHub Setup for Non-Technical Users#

Once your website is built, you need to get it on the internet. GitHub is where the code lives, and Vercel is where it gets hosted. Claude handles both.

As a Claude prompt:

Set up a GitHub repository for this website:
- Repository name: my-content-site
- Initialize with a README
- Push all the current files
- Make it a public repository

What Claude does: 1. Initializes a git repository in your project folder 2. Creates a new repository on GitHub (using the gh CLI) 3. Adds all files, creates an initial commit 4. Pushes everything to GitHub

If this is your first time using GitHub through Claude, it may need to authenticate. Claude will walk you through the gh auth login process, which involves opening a browser window and authorizing access.

Workflow 4: Deploying to Vercel#

As a Claude prompt:

Deploy this website to Vercel. Use the free tier.
Also add Vercel Analytics so I can track visitors.

What Claude does: 1. Connects your GitHub repository to Vercel (if not already set up) 2. Triggers a deployment 3. Adds the Vercel Analytics script to your HTML 4. Provides you with the live URL

After the initial deployment, every subsequent push to GitHub automatically triggers a new deployment. Your workflow becomes:

1. Make changes through Claude Code
2. /commit-commands:commit (using the commit-commands plugin)
3. Push to GitHub
4. Vercel automatically deploys the updated version

Real example: My personal homepage is deployed this way. I have pushed dozens of updates over multiple months — new blog posts, design tweaks, new sections. Every update follows the same simple cycle: edit through Claude, commit, push, live in sixty seconds.

Artifacts: A Live Page Without the Deploy#

Sometimes you do not need a website — you need a page. A dashboard from the data Claude just analyzed, three design options laid out side by side, a checklist that fills in while a long task runs. For those, Claude Code can publish an artifact: a live web page hosted at a private URL on claude.ai, straight from your session. No GitHub, no Vercel.

As a Claude prompt:

Turn this analysis into a dashboard artifact — key numbers at the
top, the trend chart below. Keep it updated as you work through
the remaining files.

Claude writes the page, asks your permission to publish it, and prints a link that opens in your browser. When it revises the page later, the same URL updates in place. Everything you have published lives in a gallery at claude.ai/code/artifacts, and Ctrl+] reopens the most recent one from the terminal.

The fine print matters here. Artifacts are available on individual plans — Pro and Max. A new page starts out private to you, and on individual plans sharing means exactly one thing: a public link that anyone on the internet can open. (Team and Enterprise plans add organization-only sharing in between.) Each artifact is one self-contained page: no forms that save data, no multi-page sites, no custom domain. So the division of labor is clean — an artifact is a live view of your work that you can hand someone as a link; the Vercel workflow above is for anything meant to be a real site.

One requirement: you must be signed in with your Claude subscription (/login), because artifacts do not work on API-key sessions. If Claude says it cannot publish and writes a local HTML file instead, that is usually why.

The newest upgrade: live data. Since July 2026 (Claude Code v2.1.209 or later), an artifact can pull fresh data through your claude.ai connectors every time the page is opened — so a dashboard shows this morning’s numbers, not a snapshot from the session that built it. The page fetches on load and can refresh on an interval or with a refresh button.

As a Claude prompt:

Build a dashboard artifact of my open GitHub pull requests that
pulls the live list through my GitHub connector when the page loads.

Two boundaries to know. Only connectors attached to your Claude account at claude.ai can feed the page while you view it — the MCPs you set up inside Claude Code (Appendix B) can supply data while Claude builds the page, but the published page cannot call them. And a live-data page cannot be shared with a public link on any plan. On Pro and Max, where the public link is the only way to share, that means a connector-backed artifact stays private to you: a personal live dashboard, not a client deliverable.

Getting Your Site Found: SEO and AI Answer Engines#

Deploying a site and getting it discovered are two different projects. In May 2026 I finally tackled the second one for whyvanamali.com, and the entire brief was one plain-English ask.

Say to Claude:

I want to make the website SEO friendly and friendly for AI
crawlers. How do I explicitly invite them?

Claude audited the site file by file and came back with a gap list I could actually understand: no llms.txt, no structured data (JSON-LD), no canonical URLs, no per-page metadata. Then it asked me a handful of shaping decisions and implemented everything.

If llms.txt is new to you: it is a plain-text index that tells AI assistants what is on your site — the robots.txt of the AI era. Search engines read your sitemap; AI answer engines read this.

The other half of discoverability is knowing whether Google has actually indexed you. I wired Google Search Console into Claude Code through an MCP, so indexing checks and sitemap submissions happen from the terminal instead of a dashboard.

In your terminal:

claude mcp add gsc -- uvx mcp-search-console

It needs Google credentials the first time you use it — Claude walks you through the setup. The full entry is in Appendix B.

The lesson: discoverability sounds like a specialist’s job, but it is a one-session project once you can say the plain-English version of what you want. You do not need to know what JSON-LD is. You just need to know you want to be found.

Workflow 5: Building a Personal Homepage#

This deserves its own section because it is one of the most valuable things a non-technical professional can build.

As a Claude prompt:

I want to create a personal website with these characteristics:

Design aesthetic: Hand-drawn, sketch-like feel (inspired by
Excalidraw). Handwriting fonts, paper texture backgrounds,
subtle borders that look hand-drawn.

Pages:
1. About — my career summary, current role, what I'm interested in
2. Writing — a repository of my LinkedIn posts and blog entries,
   filterable by category tags
3. Work — my professional history and key projects
4. Wall of Love — testimonials and kind words, displayed as
   scattered sticky notes

Content source: I'll provide a CSV of my LinkedIn posts and my
resume as a PDF.

Technical requirements:
- Static site (no server needed)
- Can be deployed to Vercel for free
- Each post should be its own page with a unique URL
- Tags for filtering: Startups, AI, Marketing, Fintech,
  Consumer, Personal

What Claude does: 1. Designs the full website with the specified aesthetic 2. Sets up a static site framework (like Astro or plain HTML) 3. Reads your CSV to extract all LinkedIn posts 4. Creates individual pages for each post with metadata and tags 5. Builds the tag-based filtering system 6. Reads your resume PDF to populate the Work section 7. Creates the sticky-note layout for the Wall of Love 8. Sets up for Vercel deployment

Real example: My personal homepage is the most extensive project I have built with Claude Code. It features a hand-drawn Excalidraw-inspired aesthetic, eighty-plus LinkedIn posts populated from a CSV export, a tag-based filtering system with six content categories, a Wall of Love with sticky-note design, and a work history section populated from my resume PDF. Over six months of iteration, I have refined the design, added content management system integration, and pushed dozens of updates. The site runs on Vercel with analytics tracking.

Workflow 6: Document to Deployed Microsite#

Sometimes you already have the content — a report, a playbook, a guide — and you simply want it live on the internet as a clean, shareable web page. This workflow turns any written document into a deployed microsite with analytics and lead capture.

As a Claude prompt:

Turn this markdown file into a simple HTML website:
/Users/krishna/Desktop/Content/writing-playbook.md

Rules:
- Do not change a single word in the copy
- The design should be clean and readable, optimized for long-form
  content
- Use the frontend-design skill for visual quality
- Add a table of contents with anchor links
- Add Vercel analytics (inject method for static HTML)
- Make it fully responsive

Save to /Users/krishna/Desktop/Content/writing-playbook-site/

What Claude does: 1. Reads the markdown file 2. Converts to semantic HTML while preserving every word 3. Applies a polished design (typography, spacing, color) 4. Creates a table of contents from the heading structure 5. Adds analytics integration 6. Produces a deploy-ready static site

As a Claude prompt (iteration follow-up examples):

The 2x2 matrix in the content is showing as a code block.
Convert it into a responsive HTML table, or replace it with
this image: /Users/krishna/Desktop/Content/matrix-image.png

Add a Tally form popup between sections 1 and 2 for email
capture. Here is the embed code: [paste Tally snippet]

The table of contents has 7 items. Balance it — put 4 on the
left column and 3 on the right for the desktop view.

Real example: I had a LinkedIn writing playbook — a detailed analysis document with frameworks, matrices, and seventy-plus references to specific posts. Claude converted it into a designed website, replaced code-block matrices with actual images, added Vercel analytics, embedded a Tally form for email capture, and hyperlinked all seventy-plus post references to their original URLs. The site went from markdown file to live URL in under thirty minutes. This is a repeatable pattern for any written document you want to make publicly accessible.

Why this is different from Workflow 1 (building from a brief): When you build from a brief, you are designing a website. When you convert a document, you are preserving content while adding presentation. The key constraint — “do not change a single word” — makes Claude focus purely on design and functionality rather than content creation.

Slide Decks That Do Not Look Like PowerPoint#

The same skill-powered approach that builds websites also builds presentations. The frontend-slides skill, built by Zara Zhang, produces single-file HTML slide decks — full-screen, animated, and nothing like a default template.

The flow is the selling point. The skill asks a few questions about the vibe you want, then generates three single-slide previews in genuinely different aesthetics. You pick by looking at rendered slides, not by describing an aesthetic in words — the same principle as the design tournament earlier in this chapter.

Once you pick, it builds the whole deck in that style. Every slide inherits the direction you chose, so the finished deck feels designed rather than assembled.

Inside Claude Code:

/plugin marketplace add zarazhangrui/frontend-slides
/plugin install frontend-slides@frontend-slides

I have it installed and I use it. The output is one HTML file — open it in a browser, present full-screen, or send it as a link. Nobody will ask which template you used.

Case Study: Arcade Mode — From Thought Experiment to Shipped Feature#

In June 2026, my personal site got an opt-in “Arcade Mode” — a full 8-bit retro reskin with a toggle, CRT power-on transitions, and a Konami-code easter egg. It went from idea to public launch on LinkedIn in about four days. How it was built matters more than what was built.

It started as a message that literally opened with “Ok just a thought experiment…” I was not committing to a project; I was wondering out loud what a retro version of whyvanamali.com might look like. Thought experiments used to cost a designer’s week — now they cost one sentence.

The exploration had one rule that changed everything. I told Claude: “whenever you are posing questions, mock it up and then ask.” Every design question after that arrived as rendered mockups instead of text descriptions, and I picked looks by looking.

Once the direction settled, Claude wrote a design spec and an implementation plan, and I approved both. Then the build itself was one command: /goal — the run-until-done feature Chapter 15 covers in detail — which executed the full plan autonomously, phase by phase.

Here is what made a big autonomous build feel safe. The entire thing happened in an isolated copy of the site — a git “worktree” — behind a flag, so nothing could touch the live site until I merged. Claude could rewrite whatever it wanted in there, and my real homepage never flinched.

Then came QA: screenshot-driven review rounds on desktop and mobile, the same loop from Workflow 2B. When the design held up on both, I merged and deployed.

One detail worth flagging: the 8-bit avatar did not come from Claude drawing pixels. Claude wrote a detailed prompt for an image model, and the image model produced the sprite. That move — when Claude cannot make the asset, have it write the prompt — gets its own section in Chapter 13.

Three lessons from four days: thought experiments are cheap now, mockup-based questions beat text-based ones whenever a decision is visual, and big builds are safe when they happen in an isolated copy of your site.

Build to Learn: The Fastest Way to Understand Anything#

Everything in this chapter so far assumes you are building for an audience. But the reframe that changed how I use these skills is this: the fastest way to understand a confusing topic is to have Claude build YOU an interactive explainer.

In July 2026, I wanted to understand India’s capital account versus current account — a topic most finance explainers manage to make impenetrable. So I asked Claude for an interactive HTML explainer: “explain it like I’m somebody who does not understand finance, remove the jargon.” Claude grounded the facts with a web search first, then built the page.

What I got was my own personal textbook. One page, zero dependencies, written for exactly my level of ignorance.

Here is the pattern:

Say to Claude:

Make me an interactive one-page HTML explainer of [topic].
I'm a complete beginner — remove all jargon. My learning goals:
[2–3 questions you want answered]. Ground every fact with a
web search first.

Nobody else ever needs to see these pages. That is the point — they are built for an audience of one, and they can be as simple or as playful as you need them to be.

Pro Tips#

Tip 1: Always use the frontend-design plugin. The difference in design quality between building with and without this plugin is stark. Without it, Claude produces functional but generic websites. With it, Claude creates visually distinctive, production-quality interfaces.

Tip 2: Use Playwright screenshots as your review tool. Instead of switching to a browser to check Claude’s work, let it take screenshots using Playwright. You see the result right in the terminal. This keeps the feedback loop tight.

Tip 3: Save your work frequently with git. Use the /commit-commands:commit command after every significant design change. This creates a history you can roll back to if an iteration goes wrong. I once asked Claude to make a change that broke the layout — because I had committed before the change, I could easily revert.

Tip 4: Explore multiple design directions before committing. For important projects, ask Claude to create two or three different design options first. Review all of them, pick the strongest elements, and ask Claude to combine them. “Show me this in a dark theme and a light theme” or “Give me a minimalist version and a bold, editorial version.”

Tip 5: For design feedback, reference real sites. “Make the card layout similar to how Notion displays their template gallery” or “I want the hero section to feel like Apple’s product pages — clean, lots of whitespace, one hero image.” Claude understands these references and can adapt them to your project.

Tip 6: Mobile-first review. After any major design change, ask: “Take a screenshot at 375px width (iPhone size).” Mobile responsiveness issues are easy to miss on desktop screenshots.

Tip 7: Use the shadcn MCP for component-driven development. If you are building with React or Next.js, the shadcn MCP gives Claude Code a live connection to hundreds of professionally designed UI components — buttons, dialogs, data tables, forms, dashboards, and more. Instead of describing what you want from scratch, you can say “Build a settings page using shadcn components” and Claude will query the registry, install the right components, and wire them up with current, accurate APIs. The MCP also supports namespaced registries, so teams with their own component libraries can expose them to Claude alongside the public shadcn catalog. Combined with the Figma MCP, this creates a design-to-code pipeline where Figma provides the visual intent and shadcn provides the implementation building blocks.

What Others Are Doing with Web Building#

Website building has become one of the most visible non-developer use cases for Claude Code, and the community has developed several notable patterns:

Template replication from screenshots. Instead of describing a design from scratch, give Claude a screenshot or URL of a website you like and say “Build something that follows this layout and aesthetic for [my purpose].” Claude can replicate visual patterns while adapting the content to your needs. This is especially useful for landing pages where you want a proven layout pattern.

The honest contrarian view. For simple landing pages and content sites, Claude Code is excellent, but for complex, interactive applications with intricate UI requirements, human designers still produce superior results. I agree with this nuance: Claude Code excels at “make something great” and is less suited for “match this exact Figma specification pixel-for-pixel.” Know the boundary.