From empty folder to deployed site with Claude Code

Short answer: start with a written brief, not a prompt. Put the goal, the stack, the non-negotiable rules and the build/test commands in a CLAUDE.md at the repository root. Scaffold the project with the official templates, then build in small, reviewed steps: ask for a plan, approve it, let Claude Code implement it and run the build and tests, read the diff, commit. Deploy something real in the first week. The AI types fast; your job is to keep every step small, tested and understood.

A real example: a small business site

A typical brief: a website for a local shop with a few public pages, a schedule visitors can browse, and a request form that notifies the owner. Bilingual, mobile-friendly, hosted on a cheap Windows plan. Nothing exotic, but enough moving parts (forms, an admin area, a database, deployment) to go wrong in the usual ways.

The workflow below is how to take that from an empty folder to a deployed site without losing control of the code.

Step 1: write the brief before any code

Create the folder and a CLAUDE.md. Keep it short, specific and about things that are easy to get wrong:

# Shop site: rules for Claude

## Goal
Public site for the shop (fa + en), a weekly schedule, a repair-request form that emails the owner.

## Stack (decided)
.NET 10, ASP.NET Core Razor Pages, EF Core + SQL Server, hosted on Windows/IIS (Plesk).

## Never
- No secrets in the repo: connection strings and passwords come from environment variables.
- No CDN links: self-host every CSS/JS/font file.
- No feature work without a test for its rules.

## Commands
dotnet build
dotnet test
dotnet run --project src/Shop.Web

The "Never" list does the most work. Every rule there is a mistake the agent would otherwise make sooner or later.

Step 2: scaffold with templates, not prompts

Let the official templates write the boilerplate; it's correct and costs nothing:

dotnet new sln -n Shop
dotnet new webapp -n Shop.Web -o src/Shop.Web
dotnet new xunit -n Shop.Tests -o tests/Shop.Tests
dotnet sln add src/Shop.Web tests/Shop.Tests
dotnet add tests/Shop.Tests reference src/Shop.Web
git init && git add -A && git commit -m "Scaffold solution"

Then start claude in the folder. It reads CLAUDE.md and the scaffold, and you're talking about your project from the first message.

Step 3: plan first, then implement

For anything bigger than a one-line fix, ask for a plan before code. Claude Code has a plan mode for this (Shift+Tab cycles modes): it explores and proposes without editing files. Review the plan the way you'd review a design doc. Is the data model right? Where do the rules live? What will be tested? Change it, then let it implement.

Good requests are narrow and checkable:

Add the repair-request form: name, phone, bike model, description (30–2000 chars). Save to the database, show a thank-you page, and add tests for the validation rules. Don't send email yet.

Step 4: let it run the loop, you read the diff

The agent's real advantage is the loop: write code, run dotnet build, read the error, fix, run dotnet test, repeat. Let it. When it says it's done:

1. Read the diff. All of it.
2. Run the app yourself and click through the change.
3. Commit with a message that says what changed and why.

If the diff touches files that have nothing to do with the request, reject it and ask again with a tighter scope.

Step 5: encode the rules as tests

Every rule that matters becomes a test the agent has to keep green: validation limits, "forms don't work without the antiforgery token", "admin pages require login", "prices are never floating-point". Tests are the only instructions that are checked on every change.

Step 6: deploy in week one

Publish and deploy the first working page, not the finished site. Shared hosting has its own surprises: the runtime version on the server, app-pool settings, file permissions, web.config. Finding them on day three is cheap; finding them on launch day isn't.

dotnet publish src/Shop.Web -c Release -o artifacts/publish

Keep deployment and production data behind your own hands. The agent can write the deploy script; you run it.

Pros and cons

Pros

• Days instead of weeks for the boilerplate-heavy parts.
• The build–test–fix loop runs without you, so your time goes to review and decisions.
• CLAUDE.md plus tests make the project's rules explicit, which helps any future developer, human or not.

Cons

• Review is the bottleneck, and the temptation to skim grows with every green build.
• The agent is confidently wrong sometimes; only tests and your reading catch it.
• Without a written brief, every session drifts a little further from what you meant.

The short version

Brief first. Templates for scaffolding. Plan, implement, read the diff, commit. Rules as tests. Deploy early. That's the difference between "AI wrote some code" and "I shipped a site with AI".

Want a site or MVP built this way, reviewed line by line by a senior engineer? See how I can help.