AI & Automation

I Let Claude Build This Website. Here's Exactly How It Went

One evening, on a whim, I decided I needed a proper portfolio site. Not a template. A full-stack application, Next.js frontend, Express API, PostgreSQL, Redis, Nginx, Docker, TLS, the lot. Something I could point a CTO search committee at and say: this is how I think about technology.

The twist: I was going to write as little code as possible. Claude was going to do it.

By the next morning, I had a Technical Design Document, created by Claude. By the end of the same day, I had a working production deployment in the Cloud. This post is an honest account of how that actually went, what worked, what didn't, and what it means for anyone who still thinks AI-assisted development is just autocomplete on steroids.

The Starting Point: The TDD

The first decision, I wasn't going to write a line of code. It was going to be all prompt driven. This was hard, as someone who likes rolling my sleeves up and fixing issues, I had to stop myself. I asked Claude to produce a full Technical Design Document for the application, data models, API contract, authentication strategy, infrastructure topology, the works. I left it running, went to bed, and reviewed it the next day.

It was good. Not perfect. I made decisions along the way that diverged from it, but as a starting scaffold it set the direction cleanly and meant I never had a blank page problem. That alone is underrated. The biggest barrier to starting a project is usually starting.

The Build: Directing, Not Coding

My role throughout the build was director, not implementer. I described what I wanted in plain terms, reviewed the output, identified what was wrong, and refined the prompt. Repeat.

Claude handled:

  • The full Next.js frontend (App Router, Tailwind, Radix UI, Framer Motion)

  • The Express/TypeScript backend with Prisma ORM

  • JWT authentication with TOTP two-factor authentication

  • A complete admin CMS with a rich text blog

  • Rate limiting, helmet security headers, CORS configuration

  • Docker Compose production setup with Nginx

I directed. Claude built.

Where It Got Interesting: Errors and Prompt Iteration

I won't pretend it was frictionless, but I think Claude and I are still friends. There were errors. But here's the thing, understanding why something was broken changed how I prompted next time. When Claude produced something that didn't work, my job was to diagnose the gap between what I asked for and what was actually needed, then close that gap in the next prompt. That's a skill. It's not clicking a button and watching magic happen, it's applied technical judgment operating at a higher level of abstraction.

The engineers who will struggle with AI tooling are the ones who treat a wrong output as a failure. The ones who treat it as a signal, information about what the prompt was missing, will move very fast indeed.

The Standout: Terraform

If I had to pick one area where Claude demonstrably made something easy that would otherwise have been a significant time investment, it's Terraform.

I had a clear picture of what I wanted: a VPS, DNS records, a cloud-init script to bootstrap the deploy user and clone the repo, outputs for the IP address. I described it. Claude produced working Terraform that I reviewed, adjusted in one or two places, and ran. The infrastructure provisioned cleanly first time.

Terraform has a learning curve. The HCL syntax, the provider documentation, the state management model, for someone who doesn't live in it daily, it takes time to get right. Claude compressed that time to near zero. I kept full control and understanding of what was being provisioned, but I didn't have to type it from scratch.

What This Actually Means?

This project wasn't an experiment in laziness. It was a deliberate test of a thesis: that senior technical judgment, knowing what to build, why, and whether the output is correct, is more valuable than ever, and that AI tooling amplifies that judgment rather than replacing it.

I didn't need to remember the exact Prisma syntax for a many-to-one relation. Claude knows it. What I needed to know was that the data model was right, that the authentication flow was secure, that the infrastructure was production-grade and not held together with string. That knowledge is irreplaceable. The typing is not.

The tools I used throughout were Claude, Windsurf, now Devin, as an IDE (mostly to keep an eye on the files being generated), and WSL. Nothing exotic. The barrier to building production-quality software this way is lower than most people realise, and the ceiling is determined entirely by the technical depth the person directing it brings to the table..

That is, I'd argue, the point.

Share this post

Paul White

Senior Technology Executive · Cloud, DevOps, Security & AI specialist with 25+ years in enterprise technology leadership.