>_ Lab Experiment — LIVE
BUILDING DIY BODY LAB WITH AI
The Full Workflow — Step by Step
This is exactly how this website was built — from zero to live — using Claude, Claude Code, Next.js, and Vercel. No prior coding experience. No web agency. No monthly platform fee.
Each step below shows what actually happens at that stage — including the back-and-forth, the mistakes, what breaks, and what you end up with. The guide at the bottom turns all of this into something you can actually reference later.
12
Steps in the workflow
6
Core tools
~$25–40
Est. monthly cost
~1 day
First deployment
Before you start reading —
This page shows you the technical complexity of what went into building this site. But the real lesson is not in the steps. The real lesson is concept — how to think alongside AI, how to direct it, how to work with it as a partner rather than a search engine. That shift in how you approach it changes everything. The guide at the bottom covers both: the steps themselves, and the framework for the thinking behind them.
Understand What Claude Actually Is
Before you touch any tools, you need to understand what you are working with. Claude is not a search engine. It does not look things up. It reasons. There is a difference between asking Claude a question in a browser tab and using Claude Code in your terminal — and most people start confused about this.
Claude in the browser (claude.ai) is your thinking partner — planning, copy, decisions, strategy. Claude Code in the terminal is the builder that touches your actual files. You will use both, constantly, but for different things. Getting this distinction wrong wastes a lot of time early on.
>_ What this actually looks like
Browser conversation (planning):
"I want to build a website about body health and movement. What sections should the homepage have? Give me a list and explain why each one matters."
Claude responds with a full breakdown.
You go back and forth five or six times adjusting the structure. This is normal. You are not wasting time. You are building the blueprint before you pour concrete.
Later, in Claude Code (building):
"Build a homepage hero section with a background video, a headline that says 'What moves you,' and two CTA buttons — one linking to /assessment and one scrolling to #learn."
>_ Common mistakes at this step
- ✕Treating Claude like Google — it does not search the internet by default.
- ✕Expecting one prompt to produce a finished product — it takes iterations.
- ✕Using Claude Code for planning conversations instead of building conversations.
What you have at the end of this step
You understand the two modes of working with Claude and when to use each one.
Install Claude Code
Claude Code is a command-line interface — a tool you run in your terminal. It connects Claude directly to your project files. It reads them, writes to them, creates new ones, runs commands, and shows you what it is doing in real time.
The install itself is straightforward, but your environment matters. You need Node.js installed first. You need a terminal you are comfortable opening. You need an Anthropic API key, which is different from your claude.ai login. The API key is what lets Claude Code make calls on your behalf — and it costs money per use, though the amounts are small if you are not being reckless.
>_ What this actually looks like
What the install looks like:
npm install -g @anthropic-ai/claude-code
What you type to start a session:
claude
First real conversation in Claude Code:
"What files are in this directory and what does this project currently do?" — Claude Code reads everything and tells you. This is the moment it clicks.
>_ Common mistakes at this step
- ✕Forgetting that Claude Code uses your API key, not your claude.ai subscription — these are billed separately.
- ✕Not setting your API key as an environment variable — it will not work without it.
- ✕Opening Claude Code in the wrong folder — it builds in whatever directory you are in.
- ✕Panicking when it runs commands — it is supposed to do that. That is the point.
What you have at the end of this step
Claude Code opens in your terminal, reads your directory, and responds to instructions.
Scaffold the Project
You do not write the project structure. Claude Code does. You describe what kind of site you want to build, and it creates the folder structure, configuration files, and starting codebase. This takes about two minutes and saves days of setup if you had to do it manually.
Next.js is the framework we used. It handles routing, page rendering, image optimization, and API routes out of the box. Claude Code knows how to scaffold it. The result is a project that works locally the moment it is created — you can open it in a browser on your own machine before you have written a single line of actual content.
>_ What this actually looks like
Prompt to Claude Code:
"Create a new Next.js project called diybodylab-web with TypeScript, Tailwind CSS, and the App Router. Set up the basic folder structure for a site with a homepage, a library section, and an API folder."
Claude Code runs:
npx create-next-app@latest, installs dependencies, creates folder structure, and confirms it is done. Total time: under 2 minutes.
Then:
"Run the dev server so I can see what we have." It runs npm run dev. You open localhost:3000. It works.
>_ Common mistakes at this step
- ✕Not specifying TypeScript or Tailwind upfront — you can add them later but it creates extra work.
- ✕Skipping the App Router vs Pages Router decision — Claude Code needs to know which one to use from the start.
- ✕Not confirming the project runs locally before moving on — if it breaks here, fix it now.
What you have at the end of this step
A running Next.js project on your local machine with the folder structure in place.
Register Your Domain
Your domain is yours. Not tied to a website builder. Not rented from a platform. When you register a domain through a registrar, you own the right to use that name and point it wherever you want.
Choosing a name takes longer than registering one. Once you have the name, registration takes five minutes. The domain itself costs around $10–15 per year depending on the extension. You will also set up nameservers later — these tell the internet where your site lives. For now, just register the name and keep the login somewhere safe.
>_ What this actually looks like
The research process:
"I want a domain for a site about DIY health and body optimization. Give me 10 name options that are short, memorable, and likely to be available." — This conversation with Claude went about four rounds before I landed on DIYBodyLab.com.
The registration:
Go to Namecheap (or similar), search the name, add to cart, check out. Done.
The mistake most people make:
Spending $40 on a .com when a perfectly good domain is available for $10. Or buying five domains they will never use.
>_ Common mistakes at this step
- ✕Buying a domain with hyphens — harder to say, harder to remember, looks less professional.
- ✕Skipping domain privacy protection — your personal information gets published in public records without it.
- ✕Registering through a website builder platform — you lose portability.
- ✕Not writing down the registrar login — you will need it again.
What you have at the end of this step
A registered domain you own, pointed at nothing yet.
Set Up GitHub
GitHub stores your code online. Every change you make gets pushed to GitHub. This gives you version history, backup, and the connection Vercel needs to automatically deploy your site whenever you push an update.
Git is the underlying system — GitHub is just where the code lives online. Claude Code handles most git operations when you ask it to. You need a GitHub account, a repository for your project, and a basic understanding of push and pull. The workflow is: make changes locally, Claude Code commits them, you push to GitHub, Vercel picks it up and deploys. This loop is the backbone of the entire build process.
>_ What this actually looks like
Setting up the connection:
"Initialize a git repository in this project, create a .gitignore for a Next.js project, and make the first commit." — Claude Code does all of this.
Daily push workflow:
"Commit these changes with the message 'Add hero section and newsletter signup'" → Claude Code stages and commits. Then you run: git push.
What version history actually saves you:
Three weeks in, you break something that was working. You look at the git history, find the last commit where it worked, and either revert or compare. This happened multiple times during the DIY Body Lab build.
>_ Common mistakes at this step
- ✕Pushing sensitive files like API keys — Claude Code should create a .gitignore but always double-check before the first push.
- ✕Not pushing regularly — the longer you wait, the harder it is to trace what broke.
- ✕Committing everything in one giant push — smaller, frequent commits are easier to manage.
What you have at the end of this step
Your code is backed up online and ready to connect to Vercel for automatic deployment.
Deploy to Vercel
Vercel takes your GitHub repo and turns it into a live website. Every time you push an update to GitHub, Vercel automatically rebuilds and redeploys the site. No manual uploads. No FTP. No server configuration. It just works.
Vercel's free tier covers everything you need to start. You connect your GitHub account, select your repository, and Vercel handles the rest — it detects that you are using Next.js and knows exactly how to build it. First deployment takes about three minutes. After that, updates go live in under sixty seconds. You also get a preview URL for every commit, so you can see changes before they go to the live domain.
>_ What this actually looks like
The setup conversation:
"I just connected my GitHub repo to Vercel and the first deployment failed. Here is the error message. What is wrong and how do I fix it?" — I had this conversation four or five times during the initial setup. Claude Code diagnosed and fixed each one.
What a typical error looks like:
A missing environment variable. A font not loading. A module that works locally but fails in production. Each one has a specific fix.
What it looks like when it works:
You push to GitHub. Sixty seconds later, the live site is updated. You refresh the browser. The change is there. That moment never gets old.
>_ Common mistakes at this step
- ✕Forgetting to add environment variables in Vercel's dashboard — API keys that exist locally do not automatically go to production.
- ✕Using npm run build locally to catch errors before deploying — skipping this step means Vercel finds the errors instead of you.
- ✕Not setting up a custom domain right away — the Vercel default URL works but your real domain should be live from the start.
What you have at the end of this step
Your site is live on the internet. Updates deploy automatically when you push to GitHub.
Set Up Professional Email and Transactional Email
Two things: a professional email address at your domain (not Gmail), and a system that handles emails your site sends automatically — newsletter signups, form submissions, contact forms.
Your domain email (like shane@diybodylab.com) is handled by Google Workspace or a similar service. It looks professional, stays separate from personal email, and routes through your domain. Resend handles the other side — when someone submits a form on your site, Resend is what actually sends the confirmation or stores the email address. Connecting these to your Next.js site requires API keys, environment variables, and a few lines of code that Claude Code writes for you.
>_ What this actually looks like
The API route conversation:
"Build a newsletter signup API route in Next.js that accepts an email address, validates it, and sends it to Resend for storage. Handle success and error states." — Claude Code writes the full route, the validation, the error handling, and the response format.
What this actually creates:
A file at /src/app/api/subscribe/route.ts that handles everything. You never touch it manually — Claude Code maintains it when something needs to change.
Testing it:
"The signup form is returning a 500 error when I submit. Here is the error from the console. What is wrong?" — Usually a missing environment variable or a Resend API key that was not added to Vercel.
>_ Common mistakes at this step
- ✕Forgetting that Resend API keys are different in development and production.
- ✕Not verifying your domain in Resend before trying to send emails — they will be rejected.
- ✕Using a free Gmail address for your business email — kills credibility immediately.
- ✕Not testing the signup flow end-to-end before the site goes live.
What you have at the end of this step
Professional email at your domain. Forms on your site actually send and store data.
Build the Pages — The Main Work
This is where most of the time goes. You work with Claude Code in a continuous back-and-forth: describe a section, review what it builds, redirect or refine, repeat. You are the architect. Claude Code is the builder. You do not need to understand every line of code it writes. You need to know what you want and be able to describe it clearly.
A single homepage section might go through 20 or 30 exchanges before it looks right. The heading is too small. The colors are off. The spacing feels wrong. The button needs a hover state. The mobile layout breaks. Each of these is a new prompt. Claude Code reads the current state of the file, understands what you want changed, and makes only that change. It is not starting over every time — it is iterating on a real codebase.
>_ What this actually looks like
Round 1:
"Build a hero section with a full-width background video, a headline overlay that says 'What moves you,' and two CTA buttons."
Round 2:
"The headline is centered but I want it left-aligned. The first button background should be #C9A177 and the text should be black."
Round 3:
"On mobile the two buttons are stacking in a way that looks bad. Make them wrap into a flex row with a gap between them."
Round 4:
"The video is not loading on Vercel even though it works locally. What is the correct way to reference a video file in the public folder in Next.js?"
Round 8:
"Add a gradient overlay on the video — dark on the left side, transparent on the right — so the text is readable without covering the full image."
This continues.
This is one section. The homepage has twelve. Each one goes through this process.
>_ Common mistakes at this step
- ✕Vague prompts produce vague results — 'make it look better' does not work. 'Increase the heading font size to 5xl and add 24px of top padding' works.
- ✕Not reading what Claude Code builds — if you do not review the code, you do not catch the mistakes.
- ✕Trying to build everything in one session — the build is a long project, not a sprint.
- ✕Letting Claude Code make too many changes at once — smaller, specific changes are easier to verify and easier to undo.
What you have at the end of this step
Real, working pages with structure, layout, and components that hold up on all screen sizes.
Add Features — Chatbot, Forms, Video, APIs
Once the pages exist, you start adding what makes the site functional. Newsletter signup. A chatbot. Background videos. An assessment tool. API routes. Each feature is a separate project inside the larger project — and each one follows the same build loop.
The chatbot (MOBI) alone was a multi-day build. It required a streaming API route connected to Claude, a client-side UI that showed responses in real time, a system prompt that told Claude how to behave, guardrails to stop it from making things up, and a cost model that kept the API usage manageable. Claude Code built all of it. The system prompt that makes MOBI useful took longer to write than the code did.
>_ What this actually looks like
Chatbot setup prompt:
"Build a streaming chat interface in Next.js that connects to the Claude API. The user types a question, hits send, and the response streams in token by token. Use the claude-sonnet model. Handle loading states and errors."
Three iterations later:
"The streaming works but the response cuts off after about 200 words. Why is this happening and how do I fix it?"
System prompt work (in Claude, not Claude Code):
"I am building a health and movement chatbot for a website called DIY Body Lab. It should only answer questions about body health, movement, recovery, and related topics. Here is what I want it to refuse to answer... Here is the tone I want it to use..." — This conversation went 15 rounds before the behavior was right.
The cost question:
"How do I add a rate limiter to the chatbot API route so that one user cannot make hundreds of requests in a day?"
>_ Common mistakes at this step
- ✕Underestimating how long features take — a chatbot that looks simple from the outside is not simple to build well.
- ✕Not setting API rate limits — without them, one busy day can generate a large bill.
- ✕Building a chatbot without a clear system prompt — it will give generic, unhelpful answers.
- ✕Not testing edge cases — what happens if the user submits an empty input? A 10,000-word wall of text?
What you have at the end of this step
Working features that function correctly in production, not just on localhost.
Write the Real Copy
The structure is built. Now you fill it with real words. AI can help with drafts, structure, and editing — but the voice, the stories, the specific knowledge, and the decisions about what to say all come from you. This part cannot be outsourced entirely.
For DIY Body Lab, the content work was separate from the build work — but they happened in parallel. While one page was being coded, the copy for the next one was being written. Claude helped with rough drafts that I then rewrote in my own voice. It helped cut long passages that were saying the same thing twice. It flagged sentences that were too vague. The final copy on every page is mine — but it went through Claude as an editor probably three times.
>_ What this actually looks like
Starting a draft:
"I want to write the origin story for DIY Body Lab. Here are the key points I want to cover: [list]. Write a first draft in a conversational, first-person voice. Avoid corporate language and do not make it sound like a sales page."
Editing a draft:
"This paragraph is too long and repeats itself. Cut it to four sentences without losing the main point."
Checking voice:
"Does this sound like someone talking to a person or like a marketing brochure? What would you change?"
What Claude cannot do:
Write the specific stories. Know what actually happened. Sound like you.
>_ Common mistakes at this step
- ✕Publishing first drafts without editing — Claude's first draft is a starting point, not a finished product.
- ✕Letting the copy sound like AI — read it out loud. If you would not say it that way, rewrite it.
- ✕Not matching the copy to the design — long paragraphs look different in a narrow column than they do in a text editor.
What you have at the end of this step
Real copy on every page that sounds like a person, not a tool.
Debug, Fix, Push, Repeat
Things break. Production behaves differently from localhost. A font does not load. A video does not play on mobile. An API returns a 500 error. A layout breaks on a specific screen size. This is not failure — this is the workflow.
Most bugs on this site were caught by looking at the live site after a push and noticing something wrong. The fix loop is: observe the problem, describe it to Claude Code with as much detail as possible, review the fix, test it, push again. Some bugs took five minutes to fix. One took three days. The ones that take longest are usually environment issues — something that works in development but breaks in production because of a missing variable, a different file path, or a caching issue.
>_ What this actually looks like
A typical bug report to Claude Code:
"The hero video plays on desktop but on mobile Safari it shows a black screen. The video is in the public/videos folder and is being referenced as a Next.js video element with autoPlay, muted, loop, and playsInline. Here is the current code. What is wrong?"
The answer (this actually happened):
"Add the playsInline attribute explicitly in addition to the JSX boolean — some versions of Safari require the lowercase HTML attribute, not the React camelCase version."
A longer debugging session:
"Fonts are loading locally but not on Vercel. I am using next/font/google. Here is the error from the Vercel build log." — This took two hours and three failed deployments to resolve.
>_ Common mistakes at this step
- ✕Giving Claude Code vague bug reports — 'it is broken' tells it nothing. 'It returns a 404 on this specific URL in production but not locally' tells it everything it needs.
- ✕Not checking the Vercel build logs when a deployment fails — the error is always in there.
- ✕Fixing multiple things at once when debugging — change one thing, test, then change the next.
- ✕Giving up on a bug that Claude Code says it fixed without actually testing the fix.
What you have at the end of this step
A stable site that works correctly across devices and browsers.
Keep Building — The Site Is Never Finished
DIY Body Lab launched with a homepage, a few library articles, and a basic assessment. It has grown significantly since then. New pages, new features, new content — all added using the same workflow. The tools are the same. The loop is the same. You just get faster.
Eighteen months ago, building a single page took me a full day and multiple failed attempts. Now a new page takes a few hours. Not because the tools changed — because I understand how to use them. The prompts get more specific. The iterations get shorter. The mistakes get caught faster. The mental model you build over time is worth more than any single feature on the site.
>_ What this actually looks like
What a build session looked like early on:
"Make the button bigger." → Wrong result. "I mean the CTA button in the hero." → Still wrong. "The one that says Take the Assessment." → Finally right. Three exchanges for one change.
What a build session looks like now:
"In src/app/page.tsx, find the Take the Assessment button in the hero section and increase the font size from text-lg to text-xl and the padding from px-8 py-3 to px-10 py-4." → Done in one exchange.
What that gap represents:
Learning to speak Claude Code's language. Understanding file structure. Knowing where things live. That is what the guide below helps you build faster.
>_ Common mistakes at this step
- ✕Thinking the launch is the finish line — it is the starting line.
- ✕Not documenting what you built — six months later you will forget why you made certain decisions.
- ✕Trying to build everything before launching — launch with less, then add more.
- ✕Stopping because something feels too technical — if you can describe what you want, Claude Code can usually build it.
What you have at the end of this step
A site that grows with you over time, built by the same workflow you already know.
>_ The real lesson
It Is Not Prompts. It Is Communication.
I have been teaching this the same way since my first course on it eighteen months ago. The concept has not changed. What I teach is not prompt engineering. It is not a system of techniques you memorize. It is communication — the same skill you already use with other people, applied to AI.
Think about what it took to build this site. I did not know how to code it. What I knew how to do was say what I wanted, explain why, and keep going back and forth until the output matched the idea. That is the skill. Everything else — the tools, the steps, the technical setup — follows from that.
And just like DIY Body Lab is not about isolated exercises or symptoms — it is about understanding the whole body as one system — this is not about isolated prompts or tools. It is about learning to work with AI the way you work with a capable teammate.
>_ The actual workflow — how this site gets built
ChatGPT / Claude
[Thinking partner]
Start here. Describe what you are thinking about building, what you want it to do, what kind of person it is for. Ask questions. Let it push back. This is where the idea gets shaped.
Claude (browser)
[Prompt architect]
Once you know what you want to build, ask Claude to write the prompt that will tell Claude Code how to build it. You are using AI to communicate with AI — and it works better than writing the prompt yourself.
Claude Code
[Builder]
Give Claude Code the prompt. It reads your project files, writes the code, runs the commands, and tells you what it did. You review. You redirect. You go back and forth. That is the build.
The loop
[Working as a team]
This is not a one-shot process. You adjust, it adjusts. You catch something that is off, you describe it, it fixes it. The output keeps getting closer to the idea. That is what working as a team with AI actually feels like.
The part nobody talks about
AI will mislead you sometimes. It will tell you something that sounds right but is not quite right. So do humans. Once you understand how AI actually works — what its limits are, where it tends to drift, how to steer it back — you do not need someone to teach you every technique. You can figure it out yourself. Because you know how to ask the right questions.
That is what I mean when I say it is communication. Learn that, and you can build anything. You do not need to know how to code. You do not need to know which tools are trending this week. You need to know how to talk to something and get what you actually want out of it.
>_ Free Download
Get the Almost-Free Website Guide
The same guide from the downloads section — the full technical setup, every tool, every step, the real monthly cost, plus the recipe-vs-cook framework for working with AI as a team, not a search engine. Everything you just read, condensed into something you can actually reference in the moment.
Sign up and it downloads immediately.
Free. No pitch. Unsubscribe any time.