From zero to a live website

Never coded anything? No problem. With these prepared procedures, you will easily within an hour get from an empty computer to your own website on the internet that you can send to your friends. We will go step by step and for each one we will also explain why — so you understand it, not just click.

You might know ChatGPT, Gemini or similar chat tools — they work with varying success. Here we bet on Claude from Anthropic, which most corporate customers in the US deploy for real work. It works a bit differently: it doesn't just answer you in a window, but it touches files itself, runs commands and builds things for you.

And let's be clear right away: everything you use here is free. Even in the free version, you have the most powerful parts of the whole chain at full strength — the same ones used by top professionals; just in limited volume, not in limited functionality. For your first websites, it's more than enough. When your free credit runs out, you can pay extra — and you'll probably find it's one of the best investments you've ever made. But you don't need to spend a single crown to get started: a functional solution is here and completely free — available to students and those who don't believe it yet.

Type the name of the website we will make together in the box below:

The commands and prompts below will rewrite themselves accordingly. The folder will be www-hello-world, the page will have the heading "Hello World". Note: diacritics disappeared in the folder name and spaces changed to dashes — repository and file names in the computer world are written without accents (ASCII) and with dashes. The heading on the page can have diacritics.

Choose your own, less common name. The address www-hello-world.pages.dev is public — and if you keep the generic "hello-world", you'll land on an address that everyone from the course knows (and looks at). Instead of a quiet playground for you and a few friends where you can safely experiment and even mess things up, it suddenly becomes a showcase. Add something of your own (initials, number), like hello-world-kh-7 — so you have your own corner just for yourself. For real use, you'll get your own domain anyway (step 7).

View: Detailed = every step with an explanation why · Brief = just commands and steps (for those who already have a clue)

What you will have at the end 1 · Accounts 2 · Terminal + Homebrew 3 · First project 4 · Page (via agent) 5 · To GitHub 6 · To the internet 7 · Custom domain 8 · Launch set

What you will have at the end

A functional website at an address like www-hello-world.pages.dev (and later easily on your own domain), which anyone in the world can open in a browser. And most importantly, a process you can repeat for any other idea.

Heavy tools (build, libraries) run in the cloud and in the agent's sandbox — you install almost nothing on your computer. The computer is disposable, the truth is the cloud.

Plus — context: deploy runs from git (Cloudflare builds on every push), never manually from a laptop. Your computer only holds a working copy — the source of truth is git + cloud. That is the whole secret of a "disaster-proof" setup.

1 · Create three accounts (for free)

You will need three things. All of them have a free version that is more than enough for you to start:

Claude / Cowork — an AI assistant that will do the "computer" work for you. claude.com
GitHub — secure storage for your website (and the "source of truth"). github.com
Cloudflare — publishes your website on the internet. cloudflare.com

Register for all three, verify your email and you can move on. Save your passwords in a password manager (on Mac the app Passwords) — so you have them securely and don't have to remember them.

Password management and key backup have their own guide — we won't drag it in here now so it doesn't overwhelm you. You don't need it for your first website.

2 · Terminal and Homebrew

"Terminal" is a window where you type commands as text. It looks serious, but it's just a way to tell the computer exactly what to do. Open the app Terminal (via Spotlight: ⌘ Space → type Terminal).

Install Homebrew

Homebrew is a "store" for installing tools with a single command. Copy the following line, paste it into the Terminal and press Enter (it will ask for your computer password — that's fine):

Install a few tools

Now via Homebrew we will add git (versioning), gh (GitHub from the command line) and GitHub Desktop (clickable app for git):

Additionally: keep Brewfile in the repo (one line per tool) and on a new machine just brew bundle — the entire toolchain is reproducible from the manifest.

3 · Create your first project

You will have all your websites nicely together in the folder Projects right in your home folder (~ is an abbreviation for /Users/your-name). Create it and inside it a folder for this website:

Watch out for iCloud. Do not put projects in the folder Documents or on Desktop — iCloud syncs those to the cloud and fights with git (conflicts, disappearing files). The folder ~/Projects in the home folder does not sync to iCloud, so it is safe. The command above does it correctly.

The www- at the beginning is our convention for websites — in the Projects folder, your websites will line up nicely together (applications will get their own prefix). When you have more of them, you'll appreciate it.

Tip: drag the folder Projects to the left panel of Finder (into "Favorites") — you'll be going there really often, so have it one click away.

4 · The page will be written by an agent (you just say what)

Here comes the magic: you don't write code, you describe the result. In Cowork, open the folder ~/Projects/www-hello-world and write this prompt to the agent (copy it — it's already set to your name):

The agent will create the file. Open index.html with a double-click — you should see your page right in the browser (for now only on your computer). Does text/code open instead of the website? Don't panic — drag the file index.html onto the browser icon down in the Dock, or click on it with the right button → Open with → your browser.

Don't like it? Tell the agent what to change — "make the heading blue", "add the year at the bottom". Try, read the result, adjust. This is exactly how you work with an agent.

5 · Save the website to GitHub

We will now save the website to git — a secure repository from which it will also be published. How to do it? Choose your path:

You don't need to know a single command. Open in Cowork the folder ~/Projects/www-hello-world — and check that it's really the folder with your website (not Desktop, not Documents). This is where nine out of ten beginner snags hide. Then paste exactly this prompt to the agent (click in the box, ⌘ A, ⌘ C — it will copy the whole thing):

What will happen — and don't be alarmed. At one point, the agent will open a browser window where you will log in to GitHub yourself. This is correct and secure: neither the agent nor we see your password — you enter it directly to GitHub. Then you return to Cowork and type "done, continue".

Claude might "resist" you — and that's a good thing. For sensitive steps (login, passwords, paid confirmation) it will stop on purpose and leave them to you. It's not a mistake or that it "doesn't know how" — it's a safeguard so it doesn't do anything for you that you don't want. When it stops, do the step yourself and type "continue". (This beast commands respect, but it pulls for you — you just hold the reins.)

This is the key flow: you talk to Cowork and finished websites pop out on the other side. Most people don't need to know more.

Do you want to understand it and have insight into the repo? Great — here is what happens under the hood.

What is "commit" and "push" — in human terms. Files on the disk you pack into a package and thereby save their version — a timestamp you can return to at any time. You give the package a short name (commit message) and optionally a description (description). Packing = commit. When you send the package to the cloud to GitHub, it is a push. (Download back = pull.)

And branches: the live version of the website lives in the main branch main; you safely test a new thing on a separate branch and when finished you join it back with the command merge. Detailed in the manual Git & GitHub.

How an ordinary folder becomes a "repo" — with your own eyes. Open the project folder in Finder and press ⌘ ⇧ . (dot) — Finder will show hidden files. There are none there right now. Once you make it a git (commit / Publish in the next step), press ⌘ ⇧ . again — a hidden folder will appear .git. That is exactly what makes an ordinary folder a repository — it holds the entire version history inside. (You can hide the hidden files again with the same shortcut.)

How to do it manually — from the fastest:

Via the command line (one command):
Eventually via your own skill built on top of that command — you name it once and then just call it.
Clickable app GitHub Desktop (if you want a GUI): log in → File → Add Local Repository → select ~/Projects/www-hello-world → write the version name, Commit, then Publish repository (feel free to use Private).

6 · Release the website to the internet (Cloudflare)

Now we will expose the website to the internet via Cloudflare. How to do it? Choose your path:

Now we will expose the website to the internet. Paste this prompt to the agent — it is detailed on purpose, so it works the first time (click in the box, ⌘ A, ⌘ C):

Logging into Cloudflare will happen the same way as with GitHub — in a browser window and you enter the password, the agent won't touch it. Then you say "continue".

Here too, Claude might resist at login or confirmation — and that's correct. It will stop, you do the step and type "continue". If it struggles, feel free to give it a hint: "use the Cloudflare MCP connector" or "try it via wrangler".

This is the uncorking of the bottleneck: ideas → Claude → website out. Most people will choose this fully automatic process — and have peace of mind to create.

And what if a service doesn't have an API (just clicking)? Then comes into play the Chrome plugin: the agent will pre-click the steps directly in the browser for you and you just transfer the sensitive data (secret). For now in beta and slower than API/CLI/MCP, but powerful.

Stop for a moment — your website is out in the world.

A few dozen minutes ago you had an empty computer. Now you have a live website on the internet, at an address like www-hello-world.pages.dev. Open it — it works, it's public, anyone in the world can load it.

It's not your official domain yet (www.mujprojekt.com comes in step 7) — this one is "developmental". But it doesn't change anything: it's out there and you can touch it.

And this is exactly the moment you've been waiting for: send the link to your friends, ask them what they think — and feel free to redo and improve it several times afterwards. You can now change the website whenever you want (tell the agent, or manually commit → push), and in a moment the modification is out.

No rush to move on. Enjoy this — you yourself just got an idea from your head all the way to the internet.

Got a contact form on your page? Test it before you trust it. When you ask an agent for "a page with a contact form", it often scaffolds a form that looks completely real — fields, a Send button, even a "thanks!" message — but quietly doesn't send anywhere. It's a mock. So do this now: fill it in and submit it yourself. If no message lands in your inbox (or wherever you expected it), it's a mock and needs wiring to a real backend. We have a ready-made guide for exactly that: Ship a working form →

Now play — change the website and watch it publish itself

This is the whole magic: you say the idea in Cowork and the rest — saving the version (commit), sending (push) and building (build) — happens by itself. In a moment you see the change online, even on your mobile. You hold in your hand a tool to which you tell what kind of website you want, and it emerges under your hands.

Try it out — ask the agent for example for:

a different background color and font color;
in the footer the page version and build date — so you can see with your own eyes that the website really rebuilt;
some icons. We like Phosphor and Lucide — open them and choose, so you know what's in the repertoire.

Try these — low-stakes experiments, one sentence each

None of these can break anything — it's your private playground. Each one is a single sentence you say to the agent. Try one, watch it appear online, and you'll feel the tool become yours:

"Add a small clock showing the current time."
"Add a little icon next to the heading."
"Add a little sun drawn in the corner."
"Set this photo from my album as the background" (drag a photo into Cowork first).
"Lay the title over the photo so it stays readable."
"Add a light/dark toggle" — or a with-photo / without-photo switch.
"Change the font to something cleaner / more playful."
"Re-tune the whole colour palette — try luxury gold, or technical blue." One sentence, and the whole site changes mood.

Don't like the result? Just say so — "go back", "make it softer", "try another colour". Nothing here is permanent and nothing is at risk. This back-and-forth is the skill: ask, look, adjust.

After every change, either tell the agent "save and release it" (automatic), or manually Commit → Push — and Cloudflare will rebuild the website itself. In a moment you refresh the page and you have it. Idea → out. From now on you change the website whenever you want.

The right time for mobile. While you're playing, tell the agent "make the website look good on mobile too" — that's called responsive design (the website adapts to the screen size). Open the page on your phone and you'll see the difference. Now it makes sense because you can touch it right away. And it matters: the link you'll share gets opened on phones — so have the agent do a proper mobile version, not an afterthought (we'll double-check it in step 8).

Here ends the "toy". A finished Hello World is great for trying out — you usually don't put a test page on a live domain. Steps 7–8 below are for when you are building a real website.

website creation → publishing

7 · Custom domain for a real website

When you want a real address instead of .pages.dev — say mydomain.com — you connect it to your Cloudflare Pages project. There's one catch that trips up almost everyone, so let's get it right the first time.

Add BOTH addresses — the naked domain and the www one

In Cloudflare Pages open your project → Custom domains → Set up a domain and add two addresses, one after the other:

the naked domain — mydomain.com (this is called the apex);
and also www.mydomain.com.

For each one, Cloudflare creates the DNS record for you and issues the HTTPS certificate (the padlock). Takes a minute or two.

Why both? Because this is exactly where a real student got stuck. He set up mydomain.com, it worked — but www.mydomain.com showed an error. People type "www" out of habit, links from elsewhere use it, search engines remember it. If you only add the apex, every visitor who types www. hits a dead end. Add both and that whole class of "it doesn't work for my friend" disappears.

Pick one main address — and send the other one to it

Now both addresses work, but you don't want the same site living at two URLs (it's untidy and confuses search engines). So you pick one as the real one and redirect the other to it. We recommend the naked domain as the main one (shorter, cleaner). This is the step our student never did.

Add a small file called _redirects (no extension, just that name) to the root of your project — the same folder as index.html — with this single line:

In plain words: "anyone who comes to www., send them to the naked domain, and keep whatever page they wanted." Then tell the browser and search engines which one is the real one — the <link rel="canonical"> tag in your page <head> should point to the naked domain. (If you'd rather keep www. as your main address, do it the mirror way — just pick one and stay consistent.)

Don't worry about typing any of this by hand — the one prompt in step 8 sets up the redirect, the canonical tag and everything else in one go. Here you just need to understand why: two doors into the building, but everyone ends up in the same lobby.

Where to buy a domain: Cloudflare can register most domains directly at wholesale price — without markup (national ones like .cz/.eu for now via another registrar). With a larger portfolio, this makes significant savings: for example on a domain .group it's tens of thousands of CZK a year. And most importantly, you then have domain, hosting and website under one roof — all AI-agent-friendly, which is the credo of the whole Flowsmith.

Attention: domain setup also mixes emails and security (SPF/DKIM/DMARC). So you don't break your mail, we treat this as a separate guide — it doesn't belong in the first lesson.

8 · The launch set — the "grown-up website"

A bare page works, but a real website has a handful of small touches that make it look finished and behave properly everywhere. This is exactly the set we put on flowsmith itself. Here's what each piece is and why you want it:

The browser-tab text — the words you see in the little tab at the top of the browser (we call it the text "in the browser's ear"). It's the <title> tag. Empty or wrong, and your tab just says index.html — not great.
Favicons for every browser — the tiny icon next to that tab text, and the icon when someone saves your site to their phone's home screen. Done properly it's not one file but a small set: favicon.svg, favicon.ico (sizes="any"), apple-touch-icon.png at 180×180, a site.webmanifest (with 192 and 512 px icons) and a <meta name="theme-color">. Together these cover desktop tabs, Safari, and the mobile home screen.
Share preview — when you paste your link into a chat, message or social post, it should "unfurl" into a nice card with a title, a description and an image, instead of a naked URL. That's OpenGraph (og:title, og:description, og:type, og:url, og:image at 1200×630 px + og:image:alt) plus a Twitter card (twitter:card=summary_large_image with title, description and image).
Discoverability — so search engines and AI assistants understand your site: <link rel="canonical"> (the one main address from step 7), robots.txt, llms.txt (a plain-text summary so AI tools "get" your site too) and sitemap.xml (a map of your pages).

You don't do any of this by hand. Open your project in Cowork and paste this one prompt — it produces the whole launch set in a single go (it's already set to your name):

How to check it actually worked (do all five — it's quick):

type the naked domain in the browser — it loads;
type www. in front — it should bounce you to the naked one;
paste the link into a chat (message yourself) — a preview card with title, text and image should pop up;
look at the browser tab — your title and your little icon are there.
open it on your phone — the people you share with will mostly tap your link in a messenger or a text, so it opens on mobile.

Before you share it — check it on your phone. Friends usually get your link in Messenger or a text and open it on a phone. A site that looks great on your laptop but broken on mobile is an instant embarrassment. If you skipped the responsive tweak in step 6, tell the agent now: "make it look good on mobile too", then re-check on your phone.

(We have a prepared skill for this — a ready-made verified procedure that tells the agent exactly what and how. What a skill is and how to make your own is in the lesson What is a skill.)

What you just got your hands on: accounts → tools → project → website written by an agent → git → live website. You will repeat the same process for anything else — you only change the content.

Where to next

Manual: same procedure as a reference → Lesson: your first automation → I want Flowsmith to help me with this → Back to Academy →