Your First Project: Scaffolding, Dev Server, Git and GitHub

Summary

This is the lesson where the abstract becomes concrete. You scaffold a real project, run it in your browser, and put it under version control on a private GitHub repo. By the end you have a live local app and a safe, backed-up history of your work - the foundation every later project builds on.

What you will learn

You will scaffold a project with your agent, start a dev server and view it at localhost, understand what Git and commits actually do, and push your code to a private GitHub repository with secrets safely excluded. These are the everyday motions of building, so we make them muscle memory now.

Prerequisites

A working agent setup, Node.js, and a GitHub account (free). The Fundamentals pages on Git, GitHub, the terminal and what a dev server is will help if any term here is new - skim them, then come back. You will not need to memorise Git commands; the agent runs most of them, but you should understand what they do.

The problem

Beginners get stuck between "I have an idea" and "it is running on my screen". They are unsure how to start a project, scared of the terminal, and confused by Git. The result is a folder of files with no history and no backup, where one bad change loses hours of work. This lesson closes that gap properly.

Step by step: scaffold and run

Rather than memorise a framework, ask your agent to scaffold a modern starter and explain each step. A common, beginner-friendly choice is a Vite-based project, but the exact stack matters less than understanding the flow: create the project, install dependencies, start the dev server, open the browser.

# Scaffold a new Vite project (your agent can run this for you)
npm create vite@latest my-first-app

# Move in and install the dependencies it needs
cd my-first-app
npm install

# Start the local dev server
npm run dev

The dev server prints a local address, usually something like http://localhost:5173. Open it in your browser and you will see your app running on your own machine. "localhost" simply means "this computer" - nothing is on the public internet yet, which is exactly what you want while building. Edit a file, save, and the browser updates instantly. That live loop is what makes web building feel fast.

What Git actually does

Git is version control: it takes snapshots of your project called commits, so you can always go back. Think of it as an unlimited undo history with labels. Each commit records what changed and why, which means a bad edit is never a disaster - you just return to the last good commit. This single habit removes the fear that stops beginners from experimenting, because nothing you do is permanent until you decide it is.

# Start tracking this project with Git
git init

# Stage all current files for the first snapshot
git add .

# Save the snapshot with a message describing it
git commit -m "Initial project scaffold"

Keeping secrets out before you commit

Before you ever push to GitHub, make sure secrets cannot escape. A .gitignore file lists things Git should ignore. Your .env file - where API keys live - and the node_modules folder both belong there. Get this right once and you will never accidentally publish a key. Your agent can create this file, but you should be able to recognise a correct one.

# .gitignore - tells Git what to never track
node_modules
.env
.env.local
dist

The rule is absolute: secrets go in .env, .env goes in .gitignore, and the agent never writes a key into committed code. If you remember nothing else about security from this course, remember this.

Step by step: push to a private GitHub repo

GitHub stores your repository in the cloud: a backup, a history and, later, the thing your deployment connects to. Create the repository as private so your business code stays yours. The agent can do most of this, but here is what is happening under the hood.

# Create a PRIVATE repo and push, using the GitHub CLI
gh repo create my-first-app --private --source=. --push

# Or, if you created the repo on github.com first:
git remote add origin https://github.com/yourname/my-first-app.git
git push -u origin main

Private is the default you want for anything commercial. Public repos are great for open source, but your business IP should start private and only go public deliberately, after a security review - a topic Course 5 covers in depth.

Typical mistakes

The painful ones: committing a .env file with a live API key (now in your history forever, even if you delete it later); never running git commit, so there is no history to roll back to; creating a public repo for private business code; and panicking at the terminal instead of letting the agent run the commands while you read what they do. Slow down, read each command, and commit early and often.

Business ROI

Version control is cheap insurance with an enormous payoff. A single recoverable mistake - rolling back a broken change in seconds instead of rebuilding it for hours - pays for the habit many times over. A private repo protects the IP your business is built on. And a running local app means you can iterate fast, which is the whole point of building with agents in the first place.

Checklist

You are ready to ship once every one of these is true. Do not skip the secret-safety items - they matter more than they look.

• Your project runs locally and you can open it at localhost.
• The project is a Git repo with at least one commit.
• .env is in .gitignore and contains no secrets in any committed file.
• The code is pushed to a PRIVATE GitHub repository.

Resources

The Fundamentals pages on Git, GitHub and the dev server are your reference if a step felt shaky. The Claude Code Setup checklist in the resource library captures these guardrails as a reusable list. One step remains: getting this off your machine and onto the public internet.

Your task

Scaffold a small project, run it locally, make at least two commits as you change something, and push it to a private GitHub repo with a correct .gitignore. Confirm on github.com that your .env is nowhere to be found. You now have a real, version-controlled, backed-up project.

Next lesson

Your app runs on your machine. The final lesson of this course puts it on the public internet: deploying to Vercel, connecting a real domain, and handling DNS and Cloudflare so anyone in the world can visit your site.