How We Built Four Websites in Six Weeks Using Claude Chat, Code and Design

Introduction

This article shares how we built and shipped four websites in about six weeks using Claude.

Four sites in one group — a blog platform, a corporate site, a media site and a product site. Angular frontend, Azure Functions API, three different databases, CI/CD into Azure Static Web Apps, one shared design system, and a WordPress migration.

The git log shows 168 commits across four repositories between early August and mid-September 2026.

But "built with AI" tells you nothing. So let me share the part that is actually useful: we used three different Claude surfaces for three different jobs. That split is most of the reason it worked.

Three Modes, Three Jobs

Claude chat — for thinking before typing. Architecture questions, comparisons, the "should this be Cosmos DB or Firestore" discussion. It has no access to the repository, and that is the feature. You can propose three designs and throw away two at zero cost, because nothing is written yet.

Claude Code — for the implementation. This one runs in the terminal with the real repository. It reads the files, runs the build, starts the emulators, and greps for the existing pattern before adding a new one. Almost all the committed code came from here.

Claude artifacts and design — for the visual and document layer. Our design system started as one standalone HTML page showing every button, badge, input, card, alert and toast on a single screen. Our platform documentation is an artifact page mapping all four sites and their databases.

The mistake to avoid is using one surface for all three. If you ask a terminal agent an open architecture question, it starts editing files. If you ask a chat window to implement a change, you are copy-pasting into a codebase it cannot see.

Where the Design Page Helped Twice

The design system page is worth explaining, because it gave a benefit we did not plan.

First it was a specification. One HTML file, no build step, no framework. You open it in the browser and either it looks right or it does not. Changing it is fast because there is nothing to compile.

Then it became a source to copy from. Its patterns went into two places — plain CSS in styles.css reading from the --tk-* design tokens, and small Angular components for the pieces that need state, like toggle, checkbox, tabs and toast.

The second effect is the one that mattered. The tokens live in one CSS file, and tailwind.config.js points the Tailwind utilities at those variables. So changing one token changes the live app, without touching any component.

That is not an AI idea. It is normal design system practice. But having a rendered page to argue against made the right structure obvious early, at the time in a project when you are usually too busy shipping to build one.

The Same Pattern, Five Times

Look at the data clients across the platform.

// Cosmos
let _client: CosmosClient | null = null;
// Firestore
let _db: Firestore | null = null;
// Blob Storage
let _containerClient: ContainerClient | null = null;
// Postgres
let _pool: Pool | null = null;

Four SDKs, three clouds, one pattern. A single client created on first use and kept in module memory, because Azure Functions reuses the warm instance and rebuilding a connection pool every request is how you run out of ports.

Every one of them checks its settings at module level and throws the same shape of message.

Missing required environment variable: COSMOS_CONNECTION_STRING.
Set it in local.settings.json for local development,
or in Azure Static Web Apps Application Settings for production.

This consistency is the clearest thing you get from an agent that can read the repository. A person writing the fifth data client on a Friday evening writes it a little differently — a try/catch here, a different error text there. Six months later nobody knows which differences were on purpose.

It also makes the code easy to review. When every file has the same shape, anything strange is visible immediately.

What Still Needed a Person

I want to be honest about this part, because the articles that skip it are the ones nobody believes.

Business facts. Why Firestore for the contact form when we already run Cosmos DB? Because several sites in the group share one Firestore project and one contacts collection with a domain field, so the group inbox is one query. Nothing in the repository says that. Somebody had to supply it.

Decisions we reversed. One commit removed dark mode completely to show only the light brand. The next commit put it back. That is not a mistake to hide. That is what deciding looks like. Both directions were built correctly. Which one was right was never a technical question.

Security judgement. The captcha check fails closed — if Cloudflare is unreachable the request is rejected, not allowed. Draft posts return 404 to anonymous callers, not 403, so nobody can discover unpublished slugs. Both are one-line decisions, and the reason has to come from a person who thought about the attacker.

Knowing where to stop. Some endpoints read a whole container with no paging. That is a deliberate choice for admin-only pages with small data, and it is written down as a choice. Knowing which shortcut is safe is experience, and experience is the input here, not the output.

About the Speed

168 commits in six weeks with a small team is fast. But the speed is not the interesting part. You can produce commits quickly and still be drowning by month three.

What really changed is the cost of doing things properly.

A design system reference page. 16KB of architecture notes. A fifth data client that matches the other four exactly. These are the things we normally skip under deadline pressure, because they are expensive now and they pay later. When they became cheap, we did them. So the codebase at week six is one we can still work in at month six.

That is my honest claim. Not "AI built our platform" — a person made every decision in it. It is that the distance between the shortcut and the right way became small enough that we mostly took the right way.

Conclusion

If you try this, my suggestions are:

• Use the thinking surface for thinking and the coding surface for coding. Do not mix them.
• Build the visual reference page before the components, not after.
• Let the agent read the existing pattern before it writes the next one.
• Write down why, continuously. The reasoning is the part that cannot be regenerated.

That last point deserves its own article, and it has one.

Reference

• Claude Code
• Azure Static Web Apps