How We Build a Website With Claude, GitHub, and Netlify

The short version

• This is the real, actual workflow behind People in the Loop: Claude drafts and writes the change, GitHub stores and tracks it, Netlify turns it into something you can click through, and I review before anything goes live.
• Nothing reaches the live site without passing through a preview first.
• You do not need to run this exact setup to learn from it. The pattern (draft, preview, review, ship) applies anywhere you are building something that matters.
• This is the last post in a short series. The earlier posts cover what GitHub is, dev versus main branches, and environment variables in Netlify, worth reading first if any of those terms are new.

Why I am explaining this at all

People ask me constantly how I actually build this platform, especially once they hear I am not writing raw code myself. The honest answer is a real workflow, not a trick, made of a small number of tools, each one doing exactly the job it is good at.

That is worth writing down, both so members can understand what they are looking at when I talk about "pushing to dev," and so anyone building their own thing can borrow the shape of it.

The workflow, start to finish

Step one: the idea becomes a request. I tell Claude Code what I want changed, in plain language, the same way I would explain it to a person. No code, no syntax, just the actual thing I am trying to do.

Step two: Claude writes the change. Claude reads the existing code, makes the change, and explains what it did and why. This is where the actual "coding" happens, and it happens fast, because Claude is reading and writing code directly, not mocking something up first.

Step three: the change goes to GitHub. Every change gets saved as a commit, with a clear note about what changed. This is the history, the same one covered in the first post of this series. Nothing is lost, nothing is anonymous, everything is reversible.

Step four: it lands on dev, and Netlify builds a preview. Our dev branch has its own live, working preview site. I can click through the actual change, not just read about it, before anyone outside the team sees it. This is the test kitchen from the second post in this series, doing its job.

Step five: I review it. This is the step that never gets skipped. I look at the real preview, on my phone most of the time, and decide if it is actually ready.

Step six: it ships. Once I am satisfied, the change moves from dev to main, either automatically overnight once dev has been stable, or immediately when I say so. The moment it lands on main, it is live on peopleintheloop.app, using whichever environment variables are set for production (the third post in this series covers what those actually are).

Draft, preview, review, ship. Every step exists because skipping it once cost somebody something.

Why it is built this way

Every piece of this exists because of a real failure mode it prevents.

• Claude writing the code directly removes the translation step where I describe something and a person builds a different thing than I meant, because the same conversation that decided what to build is the one that built it.
• GitHub means nothing is ever silently lost or unexplained. Every change has a reason attached to it.
• The dev preview means I am reviewing a real, clickable version of the change, not a description of one.
• The review step, by a real person, every time means nothing reaches real members without someone accountable actually looking at it first.
• Environment variables mean the exact same code behaves correctly whether it is running on the dev preview or the real live site, with no manual swapping required.

What this means if you are not building a website

The specific tools matter less than the shape: separate deciding from building, always preview before you ship, and never let something reach the people who depend on you without a real review step. That pattern holds whether you are shipping code, sending an email to your whole list, or launching anything else that is hard to take back once it is out.

Key terms glossary

Claude Code: the tool that reads and writes real code directly, from plain-language instructions.

GitHub: where the code and its full history live (full explainer in post one of this series).

Dev branch / main branch: the working, tested version versus the live version (full explainer in post two).

Environment variables: the settings that let the same code behave correctly wherever it runs (full explainer in post three).

Deploy preview: a real, clickable version of a change, live before it is public.