Building a website with Claude over a weekend

February 15, 2026·4 min read

Claude Code Astro 5 Tailwind CSS v4 TypeScript @fontsource
Claude sessions: 12
Wall clock: 2 days
Human involvement: ~3 hours
Tokens used: ~2.4M
API cost: ~$32

API cost is the equivalent if billed per token. Actual cost is a flat subscription.

apptory.eu

This website went from npm create astro to deployed over a weekend. Dark theme, content collections, 4 app detail pages, responsive layout, a design I don’t hate. I’m a backend developer — frontend is not my day job. About 3 hours of actual involvement — I never touched the code. All of it came from telling Claude what I wanted and testing the results. The workflow: describe, test, point out what’s wrong, repeat. It’s 5-10x faster for straightforward stuff, but Claude gets confidently wrong on anything new — Tailwind v4, Astro 5 API changes. This was my first time building an entire website with AI, and while it shipped, the process is far from perfect.

Lessons learned:

  • Use --dangerously-skip-permissions. The flow dies without it.
  • Be specific in prompts. “Make it look better” wastes time. Pixel values and color names get results.
  • Invest in context early. Writing guides, test suites, and design constraints pay off across sessions.
  • Test in the browser, not in the terminal. The code compiling doesn’t mean it looks right.
  • You don’t need to write code. Describing and testing is enough if the tool can execute autonomously.

The workflow

The loop: I describe what I want, Claude generates it, I check the browser, I point out what’s wrong, Claude fixes it. For anything involving framework quirks or recent API changes, Claude was confidently wrong and I had to debug.

Run Claude Code with --dangerously-skip-permissions. Without it, every file write, every shell command, every dev server restart needs manual approval. You’re clicking “allow” instead of checking the browser. With permissions skipped, I tested the output, described what was wrong, and gave instructions on what to improve. That’s the entire workflow — and it only works when the tool can operate without constant hand-holding.

My time broke down roughly like this:

  • 50% writing descriptions of what I wanted
  • 25% reviewing output in the browser
  • 20% pointing out bugs and asking for fixes
  • 5% configuring skills and tools for better results

That last 5% mattered a lot. Adding a writing voice guide, setting up test suites, defining design constraints — front-loaded work that made later sessions faster because Claude had better context.

Where it broke

Every bug had the same shape: Claude didn’t know about it and confidently suggested fixes that didn’t work.

The worst one: Tailwind v4 ships as a Vite plugin that scans source files for class names. Except it doesn’t scan Astro’s dynamic route files like [...slug].astro. My detail pages rendered with zero styling. No error, no warning — the page just looked like raw HTML from 1997.

I asked Claude what was wrong. It suggested checking my Tailwind config, my PostCSS setup, my import paths. All wrong — there’s no config file in Tailwind v4, and PostCSS isn’t involved. Claude knows Tailwind 3, not Tailwind v4. Wrong mental model, confident wrong answers. Finding the fix myself took longer than building the initial site.

What changed

After a few hours of this, I noticed I was thinking differently. Not “how do I implement this” but “how do I describe this clearly enough.” The skill shifted from writing code to writing English.

Early prompts were vague (“make the homepage look better”) and needed lots of corrections. By the end I was writing things like “add a featured app section, larger card with gradient border glow on hover, icon on the left 96px, name plus tagline plus description on the right, cyan accent for the Learn more link.” That produced results I could ship almost directly.

What’s next

The workflow was manual — check the browser, describe what’s wrong, wait for the fix. It worked, but I can already see where it breaks down at scale.

The obvious next step is closing the loop. Claude can run a test suite, analyze the results, fix what failed, and run the tests again — no human in the middle. Add visual regression tests and you catch layout issues automatically. Add accessibility checks and performance audits and you catch things I didn’t even look for. The human role shrinks from “check every page” to “review the test report and decide what ships.”

I didn’t build that loop for this project. Next one, I will.

Back to all blurps