How to build a website using AI in less than a day

“Help me build a website” is an easy prompt to write. It is also a good way to get a page you spend the rest of the day fixing.

My blunt opinion: vague prompts often produce garbage. The copy could belong to anyone. The design changes from one section to the next. The feature your audience needs is missing.

Across the websites I have built, I keep coming back to the same questions: why am I building this, who is it for, and what should someone be able to do there?

With those answers and a small scope, a useful first version in less than a day is a reasonable goal. Think of a blog, a landing page or a simple business site. Accounts, private data and custom payment flows need more work. Have your copy and images ready, too; AI cannot fill missing business decisions reliably.

1. Get clarity before you ask AI to build

Write the answers in Notion, Excel or a plain text file. Keep them close while building.

Here is a hypothetical example: a website for a weekend pottery workshop. It has a clear audience and a specific action, so it is easier to decide what belongs in the first version. Replace these answers with your own.

Question	Workshop example
Why does the site exist?	Help people understand the workshop and book a place
Who is it for?	Beginners looking for a local weekend activity
What should a visitor do?	Choose a session and open its hosted booking page
What must be included?	Date, price, location, what is included, photos, FAQs and a booking link
What can wait?	Member accounts, a custom booking system and a large gallery
What content is needed?	Confirmed session details, original photos and booking terms
What should it feel like?	Warm and simple, with readable text and one clear primary action
What is the budget?	A fixed hosting/tool limit, plus domain and booking-service costs
What proves it works?	A visitor can find the details and reach the correct session’s booking page on a phone

If your answers are vague, ask AI to interview you:

I want to build [website]
for [audience].
Interview me before suggesting tools
or writing code. Ask one question at
a time about purpose, content,
features, design, budget and
who will maintain it.
Challenge vague answers. Finish with
a brief and a small MVP.
Flag unanswered questions instead of
inventing answers.

I also like asking AI to roast the plan: “Which features are unnecessary? What have I assumed about the audience? What would confuse a visitor?”

Use the criticism to improve the brief. Then show it to someone who fits the audience if you can. Their reaction is more useful than the agent agreeing with everything.

2. Decide the domain, hosting and type of website

A domain is the address. Hosting is where the site runs. DNS, the Domain Name System, connects the two. You can buy them from different providers.

Use the domain you already own, or start on your host’s temporary address. Choosing a name should not hold up the first version.

My preference is Cloudflare. One detail to check if you use its Registrar: the domain must use Cloudflare DNS, even if you host the website elsewhere.

The bigger decision is whether you need a backend.

A static site serves pages prepared ahead of time. It often suits a blog or an information site. You can still add menus and other browser interactions, or link to an external booking service. For the workshop example, I would start with a static information page and a hosted booking link. The booking service handles availability and payments; those tasks still need checking.

If visitors need accounts, private content or saved submissions, decide where that data lives and who can access it. That backend can be your own or a service you connect to.

For hosting, I would compare:

• Cloudflare for my preferred code-based setup. Workers can serve static assets alongside server logic.
• Vercel for a code-based site or app. Its Hobby plan is for personal, non-commercial use, so check the plan for a business site.
• Hostinger if a bundled builder and hosting setup suits you. Check renewal costs and export limits for the specific product you choose.

Count domain renewal, hosting, AI usage and any booking, database or email service in the budget. Keep private API keys out of browser code. If accounts are part of the scope, test that users can only access their own data. A generated login screen is not enough.

3. One website, one design language

Choose the colours and typography before asking for pages. Also define buttons, spacing and navigation. Otherwise, each prompt can produce another style.

A short guide is enough to start:

• Give colours roles: background, text, accent, border and error.
• Choose a readable font and consistent heading sizes.
• Reuse spacing, corner styles and shared components.
• Define button, link and keyboard focus states.
• Explain how the layout adapts to a phone.

Save it as docs/design-language.md. For example: every booking button uses the same colour and wording; workshop cards share one layout; secondary actions look less prominent.

Use reference websites to explain what you like about their type, spacing or navigation. Keep your own content and identity. “Make it modern” leaves too much for the agent to guess.

Check contrast, form labels and whether controls are easy to identify. The W3C accessibility checklist is useful when reviewing the result.

4. Why I use Astro for my personal blog

My personal blog is built with Astro. I like how it works, and it suits a website where reading is the main activity.

Astro generates static pages by default and also supports rendering selected routes on demand. I can start with a content site and add server features if I need them.

That is my choice for this blog. For your site, choose a framework or builder that fits the job and that you can keep working with. You do not need to evaluate every framework before making a simple page.

5. Think like a PM and define the MVP

The minimum viable product, or MVP, should complete the main visitor journey.

For the workshop site, that means understanding the session, finding its date and price, and reaching the correct booking page. A single page could do all of that. Member profiles and a custom booking system can wait.

Turn each requirement into a check. “A good booking experience” is vague. “The booking button opens the right session, and a full session is clearly marked” gives you something to test.

Keep a separate list for later ideas. When the agent suggests a feature, ask whether the visitor needs it to complete the main task. If it introduces accounts, new data or another integration, revisit the scope before adding it.

6. Pick the path that gives you the control you need

I used to start with tools like Lovable. I still think an AI builder is useful when you want the environment managed for you and prefer to work mainly through prompts. You will still need to check the copy, interactions and ongoing costs.

My preference for more control is a Git repository, local code in VS Code, and an agent such as OpenCode or Codex. I can inspect the files, review changes and keep improving the site. The tradeoff is setup and maintenance: installation problems or unfamiliar code can take time.

Code access varies between builders. Lovable supports two-way GitHub sync and working with the code outside the builder. Hostinger’s manual-mode WordPress export leaves out layout, styles and several features. These are different export workflows; check the exact product you intend to use.

Start with one working page

For either path, give the tool your brief, design rules and MVP. Build the main journey with real content, preview it, then request specific changes.

For the repository path:

1. Create the project and a Git repository. Git records versions; GitHub hosts a shared copy.
2. Follow the framework’s setup guide and run the starter locally. Astro’s guide lists the required Node.js version and setup steps in the sources below.
3. Open the folder in VS Code. Follow the linked setup guide for OpenCode or Codex and sign in as required.
4. Save the purpose and audience in docs/brief.md, the design rules in docs/design-language.md, and the must-have features and checks in docs/mvp.md.
5. Build one complete journey. Review the changed files and save a working version before the next change.

For the workshop example, my build request would be:

Read docs/brief.md,
docs/design-language.md
and docs/mvp.md.
Use the existing stack. Build the
workshop information page with the
supplied content and hosted
booking link.
Flag missing details. Reuse the design
rules and components. Make the journey
usable on a phone and with a keyboard.
Explain the plan before editing.
Afterward, report the checks you ran,
any failures and anything you could
not verify. Keep features from the
later list out of this change.

When the result is wrong, describe the observable problem: “The price is hard to find on a phone” is more useful than “Make it better.” If you cannot understand a change, ask the agent to explain it before accepting it.

7. Connect the pipeline when it helps

The loop I want is a small change, local preview, checks, a saved version and deployment.

With GitHub, a pull request lets me review a set of changes before merging them into the main branch. Cloudflare Workers Builds can connect to GitHub for automatic builds and deployment once configured.

For a static Astro site on Cloudflare, the deployment guide in the sources explains how to serve the generated files. Confirm your project’s build command, output folder and production branch. Check the temporary live address before connecting the domain.

MCP, or Model Context Protocol, is an optional connection that lets an agent use another service’s tools. One thing I like about Cloudflare is its MCP support. GitHub also has an official MCP server, including read-only options.

Connect the tools for the task, authenticate and check their permissions. A documentation connection answers questions; an account connection may be able to change resources. Ask the agent to explain what it will change before giving it write access.

You can launch through the hosting dashboard without MCP. Add integrations when they save repeated work.

8. Use agents for specific jobs

An idea worth trying is to split work between agents with clear responsibilities. The brutal tester and strict design-language guardian below are examples. You can add roles depending on what you need:

• A product-thinking agent to challenge the audience, main action and MVP.
• A building agent to implement one agreed feature at a time.
• A tester to find broken journeys and reproduce failures.
• A design guardian to check the result against the shared rules.

You can also use one agent in separate sessions for these jobs. More agents mean more coordination; choose roles because the work needs them.

Give each role the same brief and current version. Have reviewers report findings before making changes, then let the building agent fix the agreed issues. If agents work at the same time, keep their changes in separate branches and review them before merging.

For a product-thinking agent, I would start with: “Which audience assumption is weakest? What can we remove from the MVP? What observation would tell us the site is useful?”

Example: the brutal tester

Read docs/mvp.md. Test the main
journey in the browser. Check links,
phone layout, keyboard use and
failure states.
For booking or forms, verify the
destination and completion using a
test flow. Do not make real purchases
or submissions. Report the steps,
expected result, observed result and
severity. Include evidence. State what
you could not test. Report findings
first; do not edit the site.

Example: the design-language guardian

Review the rendered site against
docs/design-language.md. Check type,
colour roles, spacing, components and
focus states on phone and desktop
layouts, and supported themes.
Name each broken rule and the affected
page or component. Separate rule
violations from personal preferences.
State any inspection limits. Report
findings before editing.

A source-code review alone cannot prove that a page looks right or that a booking works. The agent needs the relevant browser and testing tools. I would also open the result on my own phone and ask someone to try the main task without instructions.

9. A simple sequence for the first version

Work through these stages at your own pace. Move on when the result works.

1. Define: write the brief and cut the scope. You should be able to describe the audience and main action in a sentence.
2. Prepare: choose the path, collect the content and write the design rules. Get a starter working.
3. Build: complete the main visitor journey. Add supporting pages only where needed.
4. Review: test the journey and design, fix blockers and repeat the affected checks.
5. Publish and verify: deploy, check the public address, then record what belongs in the next iteration.

Before sharing the link, check:

• The main action works on the live site, including any external booking or form flow.
• Phone layout, keyboard navigation, images and links work.
• Page title, description and social-sharing preview reflect the actual content.
• Placeholder copy and fake testimonials are gone.
• You have the source files and know how to update the content or restore a previous version.

Domain changes can take longer than the build. Use the temporary address while waiting. A new feature or setup problem is a reason to adjust the scope; keep the main journey complete.

10. Mistakes I would avoid

• Letting the agent guess the purpose or invent missing business details.
• Requesting redesigns without preserving the design rules.
• Adding a backend or several agents before the work needs them.
• Confusing a successful build with a working visitor journey.
• Choosing a platform without checking renewal costs and portability.
• Asking readers to use a feature the site does not have, such as comments.

AI tools are changing fast. Some of the tools and steps here may be outdated by the time you read this, or may not suit your setup. I would use this as a starting point and check the current guidance for the tools you choose.

The foundation stays the same: know why you are building, who the site is for and what they need to do. Start small, keep one design language and test the result. After each iteration, I come back to one question: can the person this site is for do what I intended?

Which tools do you use to build websites with AI, and what do you check before sharing them? If you found this through LinkedIn or Substack, reply there. Website readers can send me their approach.

Sources

Product details checked on 3 October 2026. Examples and workflow suggestions are mine. These links support the product claims and provide optional setup detail.

• Hosting and domains: Cloudflare DNS requirement, Workers static assets, Vercel Hobby terms.
• Builder portability: Lovable GitHub sync, Hostinger manual-mode export.
• Astro: rendering, installation, Cloudflare deployment.
• Coding agents: Codex in your IDE, OpenCode IDE integration.
• Pipeline: Cloudflare MCP, GitHub MCP, Workers Builds GitHub integration.
• Design review: W3C accessibility tips.