Build a website of any complexity in one evening with Claude Code

Until recently, even a simple landing page meant coordinating several people. You briefed a designer, waited for a mock-up, collected revisions, passed everything to a developer, and explained half of it again. Two weeks was a good result. A month of messages and almost-final files was fairly normal.

Claude Code can compress that cycle into an evening. You describe the business, answer a structured set of questions, review the first version in a browser, and request changes in plain English. Claude creates and edits the files inside a folder on your computer. You do not have to write code or assemble the page block by block in a website builder.

If you are in the UK or another supported English-speaking market, install Claude and sign in normally. You do not need Telegram, a VPN, or a rented server to start. Hosting enters the picture much later, once the website has been approved and you are ready to put it online.

This guide covers the whole workflow: installing the Claude desktop app, opening Claude Code, preparing a useful brief, creating the first draft, giving revisions, testing on mobile, and finally connecting a domain and hosting.

Step 01What You Will Have by the End

Imagine you need a landing page for a consultancy, local service, course, workshop, or small product. Create an empty folder, open it in Claude Code, and write:

I want to build a one-page website for my consultancy. Before you create anything, interview me about the offer, audience, evidence, and visual direction. Turn my answers into a full brief, show it to me, and wait for approval.

Claude asks one question at a time. You can type short answers, paste notes, attach existing documents, or use your computer's built-in dictation. Once the interview is complete, Claude turns the material into a plan: promise, audience, problem, method, proof, offer, frequently asked questions, and next action.

After you approve the brief, Claude creates a real website inside the project folder. Open the preview and you will see headings, buttons, sections, images, testimonials, and a mobile layout. If the opening section feels weak, do not rebuild the page. Say: “The headline is too broad. Give me five more specific options for a consultant who relies on referrals. Do not edit the file yet.” Pick one, then ask Claude to apply it.

You can work through five, ten, or twenty rounds in the same way. The project stays on your computer until you decide to publish it.

Step 02How the Setup Works

There are four parts to the workflow.

1. The Claude desktop app runs on your computer.
2. Claude Code works inside a folder you have selected.
3. Your browser displays a private local preview.
4. Hosting is purchased or connected only when the finished version is ready for visitors.

You do not need a server while you are writing, designing, or testing. “Local” simply means the files live on your Mac or PC. You can open them, copy them, and continue working without owning a domain.

Keeping creation separate from publishing saves money and reduces risk. A broken experiment cannot affect customers because there is no public version yet. Build first, review carefully, and upload only the approved copy.

Step 03What You Need Before You Start

You need a macOS or Windows computer, an internet connection, a Claude account, and an empty project folder. Longer sessions use more of your plan allowance, so regular client work may justify a paid plan. Check the options currently shown in your account rather than relying on an old price from an article.

Collect whatever source material already exists: a description of the offer, prices, photographs, logo files, testimonials, common sales questions, and links to websites you like. Rough notes are fine. Claude can organise them, but it should never invent clients, claims, or results.

Do not buy a VPS yet. You do not need to understand DNS, SSH, Nginx, or deployment before building the first version. When the website is ready, Claude can prepare a provider-specific publishing checklist.

Step 04Install Claude and Open Claude Code

Go to claude.ai, download the official desktop app for your operating system, and sign in. In the UK and other supported markets, registration and billing work through the normal account flow.

Open the Code section in the desktop app. On Windows, the app may ask for Git. Install the suggested component and restart Claude. Git records changes and makes it possible to return to an earlier version, although you do not need to memorise commands to use it in this workflow.

Create a folder with a clear name, such as accountancy-site-leeds or consulting-landing-page. Avoid Downloads or a directory full of personal documents. Claude receives permission to work inside the folder you select, so each substantial project should have its own workspace.

Start a new Code session and choose that folder. Claude can now create HTML, stylesheets, scripts, image folders, and project notes. Read the permission prompts before approving an action. The application shows which files and operations are involved.

Step 05Begin with a Proper Brief

The most common mistake is writing “make me a modern website” and hoping the model understands the business. Claude does not know the customer, the proof behind the offer, or what “modern” means to you. Missing information produces tidy but interchangeable copy.

Start with this prompt:

I want to create a landing page that sells my service.

Before touching any files, interview me.
Ask one question at a time and wait for my answer.

You need to understand:
- what I sell and what is included;
- who the ideal customer is;
- what situation makes them look for help;
- what measurable or observable result they receive;
- what alternatives they have already tried;
- which objections delay the decision;
- how my approach is different;
- which case studies, testimonials, and numbers I can prove;
- the price and available options;
- any guarantees, conditions, and limits;
- the single action the visitor should take;
- the destination of every important button;
- websites I like and dislike;
- colours, imagery, and styles to avoid.

When the interview is complete, write a detailed brief.
Highlight missing information and ask final questions.
Do not build the website until I write: “Brief approved.”

Answer as you would speak to a capable colleague. If a question does not apply, say so. Attach proposals, brochures, call notes, or previous copy. Mark the difference between verified facts and ideas that still need checking.

This stage often reveals that design was not the main problem. The offer may address three audiences at once, the promised result may be vague, or the testimonials may lack context. Fixing those issues before layout begins is far easier than rebuilding a finished page.

Step 06Ask for the First Version

Once the brief reflects the business accurately, send a second instruction:

Brief approved. Build the first version in this folder.

Requirements:
1. Create a one-page website with HTML, CSS, and JavaScript.
2. Plan the structure and copy before styling it.
3. Make the layout responsive on desktop, tablet, and mobile.
4. Do not invent testimonials, prices, figures, or guarantees.
5. Leave a visible marker wherever source information is missing.
6. Give every button a real destination from the brief.
7. Use semantic HTML, readable contrast, and keyboard navigation.
8. Optimise images and avoid unnecessary dependencies.
9. Check that the page opens without errors.
10. Open a preview and report what you created, what works,
and what I must review personally.

Plain HTML, CSS, and JavaScript are enough for many marketing pages. A framework can help with a web application, but it adds moving parts to a page whose job is to explain an offer and collect an enquiry. Ask for the simplest approach that meets the requirements.

Claude may create one index.html file or separate the styles and scripts. You do not need to edit those files by hand. Ask for a short README that explains how to preview, publish, and update the project.

Step 07Review the Message Before the Design

Open the local address Claude provides. It may be a file or a URL beginning with localhost. Either way, it is visible only on your computer.

Give the page a five-second test. Can you tell what is being offered? Is the intended customer obvious? Is there a concrete outcome? Can you see the next step? If the answer is no, a polished card shadow will not rescue the page.

Now read it from top to bottom as a potential buyer. Highlight sentences that could appear on any competitor's website. Check whether the page answers the natural sequence of questions: what is this, is it relevant to me, why should I trust it, what is included, what does it cost, and what happens next?

Only then review type sizes, spacing, colour, hierarchy, photography, and visual consistency. An effective page does not need twenty animated effects. It needs to keep the visitor oriented.

Step 08Give Revisions Claude Can Execute

“Make it look more premium” forces Claude to guess. A useful revision identifies the location, problem, desired outcome, and boundaries.

In the hero section, the headline takes four lines and hides the promise. Reduce it to two lines, keep the point about generating enquiries without relying on referrals, and leave the rest of the page unchanged.

If you are still considering options, separate thinking from editing:

Suggest seven hero headlines. For each one, explain in a sentence which customer motivation it uses. Do not edit the website until I choose one.

Work section by section. Review the hero, problem, method, proof, offer, price, and FAQ in turn. After each major revision, scan the whole page again. A new section can work on its own while damaging the rhythm around it.

Ask Claude to create a commit or backup before a broad redesign. If the experiment fails, you can request the previous version instead of reconstructing it from memory.

Step 09Use References Without Copying

Collect three to five websites you genuinely like. Choose examples with a similar commercial job. A consultancy should usually study professional services rather than a fashion store. Send links or screenshots.

Analyse each reference separately:
- hero composition;
- typography and scale;
- colour palette and contrast;
- content width, margins, and spacing;
- buttons and cards;
- use of photography;
- rhythm between sections.

Create a compact visual system for my website.
Do not copy wording, branding, or complete compositions.
Extract principles that suit my offer.
Show me the system before editing any files.

A reference turns taste into observable decisions. “I like the narrow text column, large headings, and warm photography” is more useful than “make mine look like this”. It also helps Claude avoid borrowing distinctive elements too closely.

Step 10Add Real Images and Materials

Create an images folder and add the approved assets. Use names such as founder-portrait.webp, case-study-cafe.webp, and logo.svg. Clear names reduce mistakes during publishing.

Ask Claude to compress images without distortion, add helpful alternative text, and reserve the correct space to prevent layout jumps. For the hero image, specify which part of the photograph must remain visible on narrow screens.

Do not present an AI-generated face as a genuine customer. Do not fabricate reviews either. If social proof is still limited, replace the section with a clear process, verified experience, tangible deliverables, or a demonstration of the work.

Step 11Check Mobile Layout and Accessibility

Many visitors will open the link on a phone. Request an explicit audit:

Test the website at 390, 768, 1024, and 1440 pixels.
Look for clipped text, horizontal overflow, small tap targets,
broken menus, distorted images, and excessive empty space.
Check colour contrast, keyboard focus, form labels,
alternative text, and heading hierarchy.
Fix the issues and list every change.

Test it yourself as well. Open the navigation, buttons, form, links, accordions, and language switcher if there is one. Rotate a phone and increase the browser's text size. Automated checks catch patterns; a human test catches awkward real-world behaviour.

Step 12Stop the Model Inventing Information

Claude can write confidently when a fact never appeared in the brief. Set a permanent rule: every number, testimonial, partnership, deadline, and guarantee needs a source inside the project.

Ask for a claim register with three columns: statement, source, and status. Anything without a source should be removed, softened, or clearly marked for review. Apply the same check to prices, legal conditions, contact details, and links.

If the website covers health, law, investments, or another sensitive subject, arrange a review by a qualified professional. Claude can organise information and flag gaps, but the publisher remains responsible for the page.

Step 13Forms, Analytics, and Privacy

Most landing pages need an enquiry form or booking link. Decide where the lead should go before designing the button. It may open a calendar, email, WhatsApp, or a form connected to your existing system.

Avoid asking for unnecessary information. Name, contact method, and one qualifying question are often enough for an initial enquiry. Test the success message, validation, notification, and failure state with a real submission.

If you collect personal data or install analytics and marketing cookies, add the privacy information and consent mechanism appropriate to your business and audience. UK and EU requirements can differ, especially when you serve people in several countries. Do not copy another company's legal pages. Have them adapted and reviewed for your situation.

Step 14When to Buy Hosting

This is the right moment to arrange hosting: the local page is approved, the copy is final, images are compressed, and every button works. There is no reason to rent a server just to begin using Claude.

A static website can use managed hosting or a small VPS. Managed hosting is simpler. A VPS gives more control but makes you responsible for maintenance, backups, and security updates. Choose a data centre close to the main audience, such as the UK or Europe for a UK-focused business.

The publishing server does not provide access to Claude. Its only job is to store the final files and answer when somebody visits the domain. Claude builds on your computer; hosting serves the approved copy to the public.

Store the provider login, server address, and credentials in a password manager. Turn on backups and security updates. Never place passwords or private keys inside the public project folder.

Step 15Choose a Domain for the English Market

For a UK-focused business, .co.uk can signal a clear local presence. A .com works well for an international audience. The name should be easy to say, spell, and type after hearing it once. Avoid hyphens and unusual abbreviations unless they are part of an established brand.

Check the domain, business name, and social handles before building the logo around them. Also search for confusingly similar companies and relevant trade marks. Claude can help prepare a shortlist, but use an official registrar and appropriate professional checks before committing to a brand.

You can buy the domain separately from hosting. This often makes future moves easier because one provider does not control every part of the setup.

Step 16Publish the Website and Connect the Domain

Ask Claude for a plan tailored to the selected provider:

The website is approved and I want to publish it.
My hosting provider is [provider] and my domain is [domain].
Prepare a safe, reversible checklist.
Include a backup, file upload, web configuration, DNS,
HTTPS certificate, redirects, and final verification.
Do not delete or overwrite anything until you show me
the exact destination and explain the rollback.

With a VPS, the common process is to upload files to a web directory, configure the domain, and issue an HTTPS certificate. Managed hosting may accept a folder upload or connect to a repository. Follow the provider's current documentation and stop if an instruction might delete existing data.

After publishing, open the https:// address, test the versions with and without www, and confirm that only one canonical version remains. Send a real form submission. Share the link in a private message to check the title, description, and social image. Add a simple 404 page and verify that it returns the correct status.

Step 17Launch Checklist

• The opening section explains the offer, audience, and next action.
• No placeholders, sample copy, or empty links remain.
• Prices, claims, names, and testimonials have been verified.
• Every image has permission for use and a sensible file size.
• Navigation, buttons, forms, and error messages work.
• Keyboard use and colour contrast have been checked.
• Mobile, tablet, and desktop layouts have been reviewed.
• The domain loads through HTTPS and redirects consistently.
• A copy of the approved local version is stored safely.
• Privacy, cookies, business details, and contact information are reviewed.

Step 18A Practical One-Evening Schedule

The process works best when you do not design while still deciding what the offer is. Use the first forty minutes for information. Complete the interview, attach source material, and correct the brief. The result of this stage is a firm decision about the message.

Use the next block for structure and the first complete build. Avoid interrupting every minor operation. Wait until there is a page to review, open the preview, and collect notes outside the chat. Divide them into content errors, hierarchy problems, and visual preferences.

Spend the third block on the important revisions. Facts and clarity come first. Then fix the order of sections, headings, and calls to action. Finish with typography, spacing, colour, and imagery.

Use the final block for testing. Check phone and desktop widths, click everything, and read the page aloud. Do not publish simply because the evening is ending. A website ready for review is a useful outcome; missing legal copy or a broken form still needs attention.

If you stop before finishing, close the session with this request:

Summarise the current project in a file called PROJECT.md.
Include the objective, approved decisions, main files,
open questions, facts we must not invent, and the exact next step.
Do not change the design.

That document preserves context for the next session and helps another reviewer understand the project.

Step 19What to Do When Something Breaks

If the preview will not open, avoid a vague “it doesn't work”. Copy the full error or attach a screenshot. State what action produced it and what you expected to see. Claude can inspect routes, files, and processes more accurately with that context.

When an image disappears, check that it is inside the project and that the filename matches exactly. A path may work on a Mac and fail on a Linux server because Photo.webp and photo.webp are different names there.

If a revision removes a section, ask Claude to summarise the latest changes and compare them with the last good version. Do not authorise a full rebuild until you know what disappeared. Recovering one block is usually safer.

If the page becomes slow, request a performance audit before adding another tool. Large images, autoplay video, multiple font families, and libraries used for one small effect are common causes. Measure first, then simplify.

If a problem appears only on the live website, record the exact URL, device, browser, and approximate time. Inspect browser errors and server logs when available. Reproduce the fix locally and publish a small reviewed change. Do not experiment on the only live copy.

Step 20Keep the Project Understandable

Claude may write the code, but the folder should still make sense to a human. Request descriptive names, a small structure, and a README with preview and deployment instructions. It should explain where text lives, where images belong, and how the production version is made.

Store key content decisions in a separate note: voice, forbidden terms, correct brand spelling, primary audience, and intended call to action. This stops a future session from changing “book a consultation” to “buy now” without a business reason.

Avoid five folders called final, final-new, and final-really-final. Use Git or dated backups. Before each release, identify one exact version and note what it contains.

Keep private source material separate from public files. Contracts, customer lists, interview notes, API keys, and passwords should never be deployed. Give Claude only the necessary excerpt and ask it to confirm that private material has not been copied into the website.

Step 21Websites You Can Build This Way

The easiest first project has one job: present a service, collect consultancy enquiries, announce a workshop, or validate a new offer. A small scope leaves more time for the message and makes launch risks manageable.

The same workflow works for a portfolio, case-study library, local business page, event microsite, restaurant menu, or campaign page. Each project follows the same cycle: brief, local draft, revisions, testing, and publication.

A blog, members' area, marketplace, or online shop requires more decisions. You need a plan for content editing, customer data, accounts, payments, recovery, and ongoing maintenance. Claude can help build those systems, but they deserve a narrower specification and technical review.

Start with the smallest unit that creates value. If a page and an enquiry form can test demand, do not build a platform with user accounts yet. Expand once real usage shows what is needed.

Step 22What to Improve After Launch

A website starts collecting useful information once it is public. Record customer questions, see which calls to action receive clicks, and look for sections people misunderstand. Change one major variable at a time so you can connect the result to the edit.

Claude can add pages, translate the site, create case studies, or improve performance. Keep a backup of the live version before every release. Work locally, review the difference, and upload only approved files.

Do not turn the page into a permanent design experiment. If it already performs its job, focus on the offer, traffic, and customer conversations. Design supports the business; it is not the business itself.

Step 23Common Mistakes

Renting a Server Before You Have a Website

In the UK and supported English-speaking markets, you do not need a server to access Claude. Build locally and pay for hosting when there is an approved version to publish.

Starting with a One-Line Request

Without a brief, Claude fills gaps with generic copy. Spend time on the audience, offer, evidence, and desired action.

Redesigning Everything at Once

Large changes hide the cause of an improvement or problem. Work in sections and preserve versions.

Trusting One Screen Size

A polished desktop hero can fail on a phone. Test several widths and at least one physical device.

Publishing Invented Claims

Confident wording does not make an unsupported number true. Require sources and remove anything you cannot verify.

Deploying Credentials

Passwords, API keys, and private notes do not belong in public files. Use environment variables, provider secrets, and a password manager.

Step 25The Whole Process in One Minute

Install the Claude desktop app directly and open Claude Code. Create a dedicated folder and ask Claude to interview you before touching any files. Approve the brief, build a complete local version, and improve one section at a time with specific feedback.

Verify every claim. Test mobile layout, accessibility, buttons, forms, and privacy requirements. Keep a version history and a clear project note.

Only after approval should you choose hosting, connect the domain, enable HTTPS, and upload the final copy. The server publishes the website; it is not required for Claude access or day-to-day creation.

The real advantage is the shorter distance between an idea and something you can see, test, and improve. You keep the judgement. Claude handles much of the repetitive technical work.