How Claude Code Speeds Up Website Builds: An Agency Workflow

Claude Code is an AI coding agent that runs in your terminal. It lets you handle design, code, testing and deployment of a website in a single session, which noticeably speeds up a small agency's workflow. At our studio the speed does not come from handing the job to the agent; it comes from writing the rules down and having a human check every step. Below is how Vinci Studio works with it, including the mistakes we made along the way.

What is Claude Code and what does it add for an agency?

Claude Code reads your project folder, edits files, runs commands and checks the result itself. Unlike a chat window, you do not copy and paste code; the agent works inside the project. For a small agency that means fewer handoffs between designer, developer and tester. For a two-person team, that is the real gain: waiting time shrinks.

Design, code, test and deploy in one session

In a traditional flow, design lives in one tool, code in another and testing is a separate stage. Most of our projects now run in one session:

• Design: Page structure and components are built directly in code, viewed in the browser and fixed in the same session.
• Code: Components, content structure and pages are written.
• Test: Type checks and lint run, then the pages are opened in a real browser. For us "the build passed" does not mean "done".
• Deploy: The change is pushed to the repository, deployment starts automatically, and the live page is checked separately.

With this flow we prepared a 22-page site preview for a production agency; it scored 95-96 on mobile PageSpeed. That is a single measurement, and since PageSpeed lab scores can swing between runs, read it as a data point, not a promise.

Working in parallel with agents

Claude Code can run helper agents (subagents) for specific jobs. We use them for independent work: one writes the content of a page while another builds components for a different page and a third audits existing pages. The main session holds the goal and the decisions; the helpers bring back results. The price of parallel work is coordination, which we illustrate with one of the mistakes below.

The rules file: CLAUDE.md

So the agent does not start from zero in every session, we keep a CLAUDE.md file in the project root. It holds the technologies we use, design rules, things not to do, and short notes on past mistakes. For example, a rule like "give no entrance animation to anything above the fold" is written there. The file works like a handover note for a new colleague; the agent and the human start with the same information. The only requirement is keeping it current, because outdated information is more dangerous than no information.

Where does human review come in?

• Decision points: Pricing, promises, client-facing copy and the decision to publish belong to a person.
• Visual checks: We do not say "done" without a screenshot and a look in a real browser.
• Content accuracy: Figures and regulatory claims are verified against sources before publishing.

The agent is fast, but it does not know what matters; we tell it.

Three mistakes we made

1. Above-the-fold animation hurt LCP. The homepage entrance animation was JavaScript-based; the server output shipped the element invisible (opacity 0), so the main content painted late. We moved the entrance animation to pure CSS and wrote the rule into CLAUDE.md.
2. Alpha support in a color token silently did not work. We tried to apply transparency through a color variable; the setup did not support it and, without any error, showed the plain color. The build passed, but the screen showed the wrong color. This is why we never skip the visual check.
3. Agents running builds at the same time caused a lock conflict. When two agents started a build in the same folder, the second failed because of the lock. The fix is simple: queue the builds and split parallel work across separate files.

The shared lesson: an agent can produce a bug silently, and a tool can swallow an error silently. After every mistake we first understand the cause, then add a rule or check that would catch it. The rules file slowly becomes an error archive and saves us time on every new project.

Where does the speed come from, and where not?

The time we save mostly comes from production: repeated components, similar page templates, type errors and small fixes are handled in minutes. Where we do not save time is thinking. What a page tells the client, which question it answers and which claim stays out are still human work and still take time. For small-business sites this balance works well, because the client is often the decision-maker, feedback comes fast, and we can show a second version the same day.

There is also an invisible gain: the agent does not get tired and does not skip boring checks. Heading structure, links, image sizes and meta information can be checked with the same care on every page. Because we write these checks into the rules file, the result does not depend on the time of day we worked.

What does this workflow mean for you?

Speed alone is not a value; a fast but unchecked site costs more than a slower, correct one. We use speed to run more rounds: test, measure, fix, measure again. If you want to talk about your site, see our web design service, and for search and AI-answer visibility after launch, our SEO·GEO·AEO service.