How I Build Websites for Free

Design: Magicpatterns or Lovable

This is the step I genuinely step back from, because you know your brand better than I do. You know your clients, your tone, what you want someone to feel when they land on the site. No developer can extract that from a written brief as accurately as you can extract it from seeing something on screen and reacting to it.

Magicpatterns and Lovable are AI-powered design tools. You type what you want, they generate a working UI. You look at it, adjust your description, generate again. It is iterative and surprisingly quick. You might go back and forth many times. That is the process. The goal is to arrive at something that genuinely feels like you, not something you settled for.

The important thing to understand about both tools: they are not just giving you a visual preview. They are giving you the actual code. When you are happy with the result, you export it. That code is exactly what gets deployed to the live site. Nothing is lost in translation between "it looks good in the tool" and "it looks good online" because what you see in the tool is already the real thing.

MagicPattern in action: the generated site preview on the left, the chat and structure panel on the right, and the Export menu open. "Download Code Zip" is the one you want. That zip is your codebase.

Version Control: GitHub

The code from step 1 needs a permanent home. That home is GitHub. Think of it as Google Drive specifically for code: every version of every file is saved, you can roll back to any previous state, and it connects to deployment tools automatically.

Creating a repository

Go to github.com and create a free account. Once logged in, look for the green "New" button next to "Top repositories" on the left sidebar, or click the "+" icon in the top navigation. Either gets you to the same place.

The green "New" button on the GitHub dashboard. Hard to miss once you know where to look.

Fill in a name, set it to Private, and turn on "Add README" so the repository is not completely empty. Click "Create repository" at the bottom when you are done.

Fill in a name for the repository (something like my-recruitment-site), choose whether it should be public or private, tick "Add a README file" so the repository is not completely empty, and click "Create repository."

Uploading the code

Once the repository is created, GitHub shows you the empty repository page. Click "Add file" then "Upload files." Drag and drop the entire exported project folder from step 1. Once uploaded, click "Commit changes." Your code is now in GitHub and every future change will be tracked here.

Click "Add file" then "Upload files." Drag your exported project folder in, scroll down, and click "Commit changes." That is your codebase in GitHub.

Forking: your ownership escape hatch

If someone else sets up the repository for you, it will initially live under their GitHub account. They will need to add you as a co-owner or contributor so you have access. But at any point, you can fork the repository. Forking creates an identical copy of everything under your own account, including the full commit history. No one can lock you out of it. No one can hold it over your head. The moment you fork it, it is entirely yours and the original owner becomes completely irrelevant to it.

Forking takes about thirty seconds: go to the repository page, click the "Fork" button in the top right, and choose your own account as the destination. You now have a full independent copy in your GitHub account. You can point Azure at your fork and the whole operation runs without you needing anyone else.

The Fork dropdown is in the top right of any repository page. Click it, choose "Create a new fork," and select your own account as the destination. Done in under a minute.

Hosting: Azure Static Web Apps (Free, Permanently)

Azure Static Web Apps is where the site goes live. The free tier is genuinely and permanently free for a static website: a business landing page, a portfolio, a recruitment site. Not a thirty-day trial. Not "free up to 1000 visitors." Just free.

I came to SWA as an application developer, not a website developer. What hooked me was not just the free hosting. It was two things in particular: the native GitHub CI/CD integration, and the built-in identity and authentication support.

The GitHub CI/CD means every time a change is pushed to your GitHub repository, Azure detects it, rebuilds the site, and deploys within a couple of minutes. No manual upload. No FTP. No "did I remember to publish?" anxiety. It just runs.

The identity support means you can gate access to parts of your site behind a login without building any authentication infrastructure yourself. Even on the free tier, you get support for public identity providers like Google, Facebook, and Microsoft accounts. On the Standard tier you can bring your own Microsoft tenant and restrict access to specific users by role. For the kinds of internal tools I originally built this for, that is genuinely powerful and I have written about it in my DuckDB static web app post. For a public website like Peter's recruitment site, we are using none of this: the whole thing is public with no login required.

Creating an Azure Static Web App and linking it to GitHub

The Basics tab. Subscription, resource group, a name for your app, Free plan, GitHub as the source, then select your repository and branch. That is all you need on this screen.

Deployment configuration. This is what gives Azure permission to watch your repository and deploy automatically on every push.

The Advanced tab. Set the region to wherever is closest to your users (East Asia works well for New Zealand). Leave Enterprise-grade edge unticked. Click through to Review + create.

As soon as this is done, you will notice a new folder in your repository called .github/workflows containing a YAML file. If you open that file, you will see a value called azure_static_web_apps_api_token. This is the secret handshake between Azure and GitHub. It is how they prove to each other that they are allowed to work together. Azure generated it, stored it as a secret in your GitHub repository, and the workflow file references it every time it deploys. You do not need to touch it. Just know it is there and what it does.

{
  "$schema": "https://aka.ms/azure/static-web-apps-cli/schema",
  "configurations": {
    "default": {
      "appLocation": ".",
      "apiLocation": "api",
      "outputLocation": "dist"
    }
  }
}

Domain and DNS: Cloudflare

A domain is the address people type to reach your site. Without one, you are sharing a URL like something-delightful-0678f2900.6.azurestaticapps.net. Which, as I noted above, is perfectly fine if budget is the priority and you have a good sense of humour about it. But if you want something that looks like a business, you need a proper domain.

My recommendation: buy your domain through Cloudflare Registrar and use Cloudflare for DNS. The reason is simple: everything in one place. You need Cloudflare for DNS anyway because of CNAME flattening (more on that below), so why buy the domain somewhere else and then point it at Cloudflare after? Fewer accounts, fewer logins, fewer things to go wrong. It just keeps it tidy.

The specific reason I am emphatic about Cloudflare comes down to CNAME flattening. Azure SWA gives you a hostname, not an IP address. Standard DNS does not allow you to point a root domain at a hostname. Cloudflare works around this automatically. Most other registrars do not.

If you are starting fresh: buy through Cloudflare

Go to cloudflare.com/products/registrar, search for your domain, and buy it there. Your DNS is already in Cloudflare from day one. Skip the next section and go straight to connecting the domain to Azure.

If your domain is already on GoDaddy: the nameserver switch

You do not need to transfer the domain away from GoDaddy. You just need to tell GoDaddy to use Cloudflare's DNS instead of its own. The domain stays registered with GoDaddy. Cloudflare just answers the DNS questions. This is exactly what I did for kepakisan.co.nz, and it is documented in full in my post on the DNS journey. The short version:

GoDaddy domain settings: DNS tab, then Nameservers sub-tab. Switch to custom nameservers and paste in the two Cloudflare addresses. That single change hands DNS control to Cloudflare.

Connecting your domain to Azure SWA

Cloudflare DNS panel with both CNAME records showing the grey cloud "DNS only" status. If you see an orange cloud on either of these, click Edit and turn the proxy off.

Ongoing Changes: Kiro

The site is live. The domain is connected. Every push to GitHub deploys automatically. Now: what happens when something needs to change?

This is where Kiro comes in. Kiro is an agentic AI development environment built by AWS. You open it, load your project, describe what you want changed, and Kiro makes the change in the code. You review it, push it to GitHub, and the live site updates within minutes. Cursor is a solid alternative if you prefer it.

Getting the code onto your local machine

Kiro works with files on your computer, not directly in GitHub. So before using Kiro for the first time, you need to pull the code from GitHub to your local machine. The easiest way to do this without touching a terminal is GitHub Desktop.

GitHub Desktop clone flow. Sign in, find your repository in the list, choose where on your computer to save it, and click Clone.

The local path field (highlighted) is where the code will live on your machine. You can choose any folder. Once you click Clone, all the files download there.

Making a change with Kiro

1.Download and install Kiro from kiro.dev. Open Kiro and open the folder where you cloned your site.

2.In the chat panel on the right, describe what you want changed. For example: "Add a new job listing for a Senior Accountant role in Auckland. Use the same format as the existing listings." Kiro reads the files, makes the change, and shows you exactly what it edited.

The Kiro chat panel. Type your request, Kiro reads the relevant files and makes the change. You can see exactly which files it touched and revert any edit if needed.

3.Before pushing the change live, preview it locally. Open a terminal in Kiro (Terminal menu at the top, then "New Terminal"), type npm run dev, and press Enter. Open localhost:5173 (or whatever port it tells you) in your browser. You will see your full site exactly as it will appear online, with your changes in place.

Opening the terminal in Kiro, running npm run dev, and previewing the site in the browser at localhost before pushing anything live.

4.Happy with how it looks? The changes are already saved. On Kiro you will see the changed files listed on the left. Write a short note about what changed (e.g. "Add senior accountant listing"), click "Commit," then "Sync Changes" Done. Your live site updates within a couple of minutes.

The diff view shows exactly what changed: removed lines in red, added lines in green. This is what Kiro edits before you commit. You can review every change before it goes anywhere near GitHub.

Where to store your content: two approaches

For a site where content changes regularly, like job listings on a recruitment site, you have two options. Both work. But they suit different situations.

🗂️

Option A: Content in the code. The text lives directly in the code files. When you need to add a new listing, you describe the change to Kiro, it edits the file, you preview it locally, and push. Technically this works. But it is not the best approach if your content changes frequently. Two reasons: first, the friction. Every content update goes through a full code-change-commit-deploy cycle when ideally you could just update a spreadsheet. Second, you cannot control what is cached in a client's browser. Even when a new version deploys, a user who visited the site before might still see an older cached version until their browser decides to fetch fresh content. You have no ability to force that refresh on their end. For occasional updates, Option A is fine. For something like a recruitment site where roles change constantly, it becomes a pain quickly.

📊

Option B: Google Sheets as a lightweight backend. The site reads its content from a Google Sheet that you control. Add a new role to the spreadsheet and the site reflects it without touching any code. This approach makes the most sense when your data is public-facing and non-sensitive anyway. Job listings on a recruitment site are a perfect example: you want the world to see them, there is nothing private about them, and a Google Sheet is free, easy to update, and easy to hand to anyone else. I am not recommending this as a general-purpose database solution. I am saying that for a list of public records that change frequently, a spreadsheet is the right level of tool for the job. No overengineering required.

For Peter: We talked through both. For a recruitment site where roles move constantly, Option B is the right call long-term. But let us get the design stable first and use Option A while we are still iterating. Once the site is locked in, I will show you how to wire up the Google Sheet. Either way, you will not be messaging me every time you pick up a new brief.

Everything Is Yours. That Is the Whole Point.

One thing that bothers me about how web development typically works for small businesses is the dependency it creates. Developer hosts on their account, registers the domain through their agency, and the client ends up in a situation where moving on means starting from scratch. That is a bad deal, and it is entirely avoidable.

This stack is built so that every asset belongs to the person who owns the website. And for a site like this, where there is no complex transactional database, no high availability requirement, no enterprise infrastructure to justify, this approach makes complete sense. Why spend thousands on a web agency when you can own the whole thing outright for a fraction of the cost?

If you decide tomorrow that you want someone else to maintain this, you just give them access to the GitHub repository. That is it. They make changes, commit to GitHub, and the CI/CD pipeline deploys automatically. The site keeps running. The domain keeps pointing where it should. No keys to hand over, no platforms to migrate, no awkward "can you transfer the hosting to me" conversations. That is how it should work.

The Developer Is No Longer on the Keyboard.

I want to end with something that looks like a provocation but is really just what I have been watching happen.

AI tools like Lovable and Kiro are compressing the time between "I want a website" and "I have one" in a way that would have seemed implausible a few years ago. A non-developer can produce a working, deployable UI in a few hours of prompting. The "build" part of the job, the part that used to justify the invoice, is becoming cheaper and faster at a pace that is not slowing down.

Which creates a real question: if the code is handled by AI, if the deployment is automated, if the design is driven by a prompt, what is the actual value a developer brings?

The developer role is reshaping. Less time on the keyboard, more time as the architect who understands the system before touching it. More time as the product owner who knows what not to build. More time as the account manager who can explain to a non-technical client exactly what they are getting and why they own every piece of it. More time as the consultant who translates between what someone needs and what the technology can deliver, efficiently and cost-effectively.

None of that knowledge is in a tutorial. Knowing to use Cloudflare instead of GoDaddy, knowing that a Google Sheet is the right backend for public-facing data when the alternative is weeks of unnecessary complexity, knowing how to structure ownership so the client is never dependent on you: you get this from building things, breaking them, and paying attention to why. That is what AI amplifies rather than replaces.

The most interesting people in any organisation right now are not the ones worried about AI. They are the ones who have figured out how to use it to close the gap between knowing what should be built and actually shipping it.

The threat is not the AI on its own. It is the person next to you who has already worked that out.