How to start building a website

1. Decide what you are building

Before you open an editor, decide what kind of site this actually is. That single decision drives almost every tool choice that follows, and skipping it is the most common reason a first project stalls halfway through: people reach for a full framework and a database when a few HTML files would have shipped a week earlier.

• A brochure or portfolio (a handful of pages, rarely updated): the simplest path. Plain HTML and CSS, or a static-site generator, get you there with no database and no backend to secure or patch.
• A blog or content site (many pages, updated often, mostly text): a static generator that reads Markdown files, or a lightweight headless CMS if someone non-technical needs to publish without touching code.
• A web app (accounts, saved data, real interactivity): a full framework with a backend and a database. This is the only category that needs authentication, and the only one where the full pre-launch checklist matters before real users show up.

Most first-time builders default straight to the third option because it is the category they have heard the most about. Resist that. A brochure site with no backend has nothing to authenticate, nothing to back up, and nothing that can leak. Match the tool to what the project actually needs this month, not to the biggest tool you know the name of.

In practice a lot of real projects are a blend: a mostly-static marketing site with one blog section, or a small app with a handful of pages that never need a login. That is fine. Pick the category that describes most of the site, build it that way, and add the heavier piece later, in its own corner, once you actually need it. You are not locking yourself in. You are avoiding the cost of a backend and a database sitting unused while you write copy for a homepage.

2. Pick your tools

You need six things, and every one of them has a usable free tier. This is what people building real sites actually reach for, organized by what each one is for.

Notice the order: version control is the hinge the rest of the table turns on. Deploys, preview links, and rollbacks all depend on your code living in a Git repository before it lives anywhere else, so set that up first even if you are the only person who will ever push to it.

The free tiers are genuinely usable, not bait. GitHub gives unlimited public and private repositories at no cost. Vercel and Netlify both include enough bandwidth and build minutes to run a real personal or small-business site, and GitHub Pages is free indefinitely for a static site with no backend at all. The one place worth spending real money early is the domain itself, and even that is a yearly cost closer to a coffee subscription than a business expense.

Framework choice is the one people overthink. If you landed on brochure or portfolio in step 1, you likely do not need a framework at all: an index.html, one stylesheet, and a few linked pages will beat a full framework you do not yet need, both in how fast it loads and in how quickly you can change it. Reach for a static-site generator once repeating the same header and footer by hand across a dozen pages gets tedious. Reach for a full application framework only once you need actual application logic, meaning accounts, a database, or server-side code that has to run somewhere. Adding a framework before the project needs one is one of the most common ways a first site never ships. If you are pairing with an AI assistant to write any of this, the AI Foundations course covers how these tools actually work under the hood, which makes it much easier to tell a good suggestion from a confident-sounding bad one.

3. Set up a repo and run it locally

This part is mechanical. Do it once, correctly, and you will not think about it again for the life of the project.

• Create a new repository on GitHub and clone it to your machine.
• Add an index.html (or scaffold a framework project into the folder) and open it in your editor.
• Install anything the project needs, then run it locally and confirm it loads in your browser before you build anything further.

git clone https://github.com/your-username/your-site.git
cd your-site
npm create astro@latest .
npm install
npm run dev

Whatever the exact commands turn out to be for your stack, the loop underneath is always the same: change a file, save, check the browser, repeat. Get that loop working before you add a single real feature. A project you cannot yet see your own changes in locally is not ready for a domain or a deploy pipeline, no matter how far along the code looks.

4. Give it a design language

A small, consistent set of choices is what separates a site that looks intentional from one that looks assembled out of parts. Decide these once, write them down somewhere, and reuse them on every page instead of re-deciding each time you add one.

• Type: one or two typefaces and a small set of sizes, a heading size, a body size, maybe one more. Keep line length readable, roughly 50 to 75 characters per line.
• Color: one background, one text color, and a single accent. Check that your text-on-background pairing reaches WCAG AA: at least 4.5:1 contrast for normal text, and 3:1 for large-scale text.¹
• Spacing: a consistent scale, for example multiples of 4px or 8px, instead of gaps you eyeball fresh on every page.
• Components: reuse the same button, card, and heading styles across the site, and reach for the actual HTML element built for the job, a real <button>, not a styled <div>, rather than rebuilding behavior you would otherwise get for free. Semantic elements carry built-in keyboard navigation and screen-reader support that a generic element does not, at no extra development cost.²

Write these four choices down somewhere you will actually look, a short style note at the top of your stylesheet is enough, before you build a second page. It is much cheaper to define a color and a spacing scale once than to go back and reconcile ten pages that each drifted slightly from the last one.

5. Buy a domain and deploy over HTTPS

Once the site works locally, getting it onto a real domain is the fast part, if you picked a git-connected host back in step 2.

• Register a domain. Porkbun and Cloudflare Registrar both sell near wholesale cost, without the aggressive upsells older registrars are known for.
• Connect your GitHub repository to Vercel or Netlify. Every push to your main branch then deploys automatically, and most hosts also hand you a preview URL for every other branch or pull request.
• Point the domain at the host using the DNS records it gives you, then confirm the live site loads over HTTPS. Browsers now flag plain HTTP as not secure, and a growing set of web platform features simply refuse to run without it.³

That last step is not optional, and a git-connected host makes it close to automatic: most issue and renew the TLS certificate for you the moment the domain resolves, with no manual setup on your end.

Web, mobile, or desktop?

Everything above is the web path. The same underlying idea, decide the type of product, pick a small toolkit, ship behind version control, applies just as much to mobile and desktop. Only the specific tools change.

None of the three platforms are mutually exclusive, and you rarely need to choose once and never revisit it. A common, low-risk path is to ship the web version first, since it needs the least setup and reaches the most people for free, then wrap it for desktop with Tauri or Electron once real users ask for an installable app, and build a dedicated mobile app only once the web version has proven the idea is worth the extra platform.

Before you open it up

A site that loads on a real domain is not the same as a site that is ready for real users. Before you share the link outside of the handful of people testing it for you, walk through a short list of what actually breaks first.

• What does a visitor see if a form gets submitted with bad or missing data, instead of a blank page or a raw error?
• What happens on a page that genuinely does not exist or a request that fails, is there a real error page, or does the site just go silent?
• Would you actually know if the site went down overnight, or would the first person to tell you be a visitor?

None of that has to be solved on day one of the project. All of it has to be solved before day one of real traffic.