A Beginner's AI Launch Pad

·

You don't have to install anything to keep an AI-built project. This chapter covers the simplest possible option — saving a file and opening it — plus one lightweight step up if you ever want a backup.

This chapter is about skipping tools entirely, which only works for a web page project. Since a web app or multi-page site needs Node.js and npm to run at all, there's no fully tool-free version of this — but don't worry, it's still quick. Head to Get it running below to get it running.

If an AI tool gave you some code, the first step is just getting it saved as a real file on your computer.

Have VS Code? It's the easiest option: File → New Text File, paste your code in, then File → Save As, type index.html as the filename, and save it somewhere you'll remember — your Desktop is fine.

No VS Code yet? On Windows (Notepad): paste your code in, then File → Save As. In the "Save as type" dropdown, choose All Files — otherwise Notepad will quietly save it as index.html.txt, which won't work as a webpage. Type index.html as the filename and save.

No VS Code yet? On Mac (TextEdit): paste your code in, then go to Format → Make Plain Text first — this matters, since TextEdit saves rich text by default and that won't work as a webpage either. Then File → Save As, type index.html, and save.

If you got several files (not just one), the same idea applies — just save them all into the same folder together.

Find the file wherever you saved it, and double-click it — it should open directly in your browser.

If it doesn't open automatically: right-click the file → Open with → choose Chrome, Safari, Edge, or whichever browser you use. You can also just drag the file into an already-open browser window.

Nothing is "running" here — you're just viewing a file, the same way you'd open a photo or a Word document.

✅ This is a complete, valid way to keep an AI-built project. No account, no command line, nothing to install or maintain. What you have is a file you can open anytime, edit anytime (in VS Code, Notepad, or TextEdit), and share by literally sending someone the file.

What you don't have yet — and that's completely fine — is a backup if your computer breaks, or a link you could send someone to view it online without emailing them the file itself. If either of those ever matters to you, the next section below is a lightweight way to get both, with no command line required.

GitHub is a free place to store a copy of your files online — and you can do this entirely through your browser, no installation needed.

Create a free account at github.com if you don't have one already.
Click the + in the top-right corner → New repository. Give it a name, then click Create repository.
On the new repository's page, click Add file → Upload files — or just drag your file straight onto the page.
Drop your file in, add a short message describing what it is, and click Commit changes.

That's it — no Git installation, no terminal, nothing from the chapters below. Just your browser.

Want your page to be an actual live website with its own link? Or ready for proper version control as your project grows? Keep your work safe and Put it online below cover both, whenever you're ready — there's no rush.

·

Getting a project running locally — from installing prerequisites through to a production build. Never used a terminal before? The Run → buttons are safe to click — they simulate the output, nothing runs on your actual machine.

✅ Good news — as a web page project, there's nothing to install or build. Sections 2–4 below just confirm that — feel free to skip ahead.

Software	Purpose
Node.js (LTS)	JavaScript runtime
Git	Version control
Visual Studio Code	Development environment

Verify each is installed:

$node -v

$npm -v

$git --version

Web page

Node.js and npm aren't required — there's no package manager or build step involved. Git and VS Code cover everything.

Software	Purpose
Git	Version control
Visual Studio Code	Development environment (the Live Server extension is handy here)

$git --version

📁 Before installing anything: your terminal needs to be open inside your project folder — npm install only works if you're in the same folder as package.json.

Using VS Code? Open the folder you saved your files into (File → Open Folder), then open its built-in terminal (Terminal → New Terminal) — it starts inside that folder automatically. You're all set — skip to npm install below.

Using a plain terminal (Command Prompt, PowerShell, or Terminal.app)? Create your project folder and move into it — skip the first command if you already made the folder another way:

$mkdir project-name

$cd project-name

Replace project-name with whatever you actually named your folder — then save your package.json and the rest of your files into it before continuing.

$npm install

Installs every package listed in package.json.

If Vite's React plugin isn't already a dependency:

$npm install -D @vitejs/plugin-react

Always create a .gitignore before your first commit:

.gitignore

node_modules
dist
.env
.env.local
.vscode

$npm install

Installs every package listed in package.json. Next.js ships with its own bundler and dev server built in — no extra plugin needed.

Always create a .gitignore before your first commit:

.gitignore

node_modules
.next
.env
.env*.local
.vscode

Web page

Nothing to install — the project is just its files. Create the .gitignore below before your first commit, mainly to keep editor/OS clutter out of the repo:

.gitignore

.DS_Store
.vscode
Thumbs.db

Install packages:

$npm.cmd install

Start the development server:

$npm.cmd run dev

Install packages:

$npm.cmd install

Start the development server:

$npm.cmd run dev

Next's dev server defaults to port 3000, versus Vite's 5173 — otherwise the routine is identical.

Web page

There's no dev server to start — open index.html directly, or use VS Code's Live Server extension for auto-reload on save. If you'd like a quick local server from the terminal instead:

$npx serve .

Commands on this page auto-detect Windows vs. macOS/Linux/Git Bash from your browser and switch between npm.cmd and npm automatically.

Stop any running server:

CTRL

+

C

Press Y if prompted to confirm.

Always confirm the project builds successfully before committing.

$npm.cmd run build

Preview the production build — this surfaces issues that don't show up in dev mode:

$npx vite preview

Alternative, using serve:

alternative preview

npm.cmd install -g serve
serve -s dist

Always confirm the project builds successfully before committing.

$npm.cmd run build

Preview the production build locally:

$npm.cmd run start

If the project is configured for static export instead of a Node server, next export outputs plain HTML/CSS/JS — at that point it deploys the same way a web page project does.

Web page

There's no build step — the files in the project are exactly what gets deployed. Open index.html (or run the npx serve . command from the previous section) to give everything one last look before committing.

You can safely skip this until your project actually needs an API key or a secret — most simple projects don't need it right away.

Never commit real secrets. API keys, tokens, and passwords belong in a local env file that's already covered by the .gitignore from Section 2 — never directly in code.

Create a .env.local in the project root. Vite only exposes variables prefixed VITE_ to your frontend code — anything else stays server-side only (irrelevant for a pure static build, but relevant if you're running a small dev-only server alongside it).

.env.local

VITE_API_KEY=your-key-here

Create a .env.local in the project root. Next.js exposes variables prefixed NEXT_PUBLIC_ to the browser — anything without that prefix stays server-side only, which is where real secrets belong.

.env.local

NEXT_PUBLIC_SITE_NAME=my-site
API_SECRET=your-server-only-secret

Web page

A static site has no server — anything shipped to the browser is visible to anyone who views the page source, prefix or not. Don't put real secrets in a static project at all. Non-secret settings (a site name, a public analytics ID) can just live in a plain checked-in config.js instead of an env file.

Deploying to Vercel or Netlify? The same variable names need to be added again in the platform's dashboard — Project Settings → Environment Variables — since your local .env.local file is gitignored and never reaches the server.

·

The commit/push routine — for a brand-new repository and for one that already exists. New to terms like "commit" or "branch"? There's a plain-English Glossary in Look things up.

📁 Make sure your terminal is open inside your project folder before running the commands below.

Using VS Code? Its built-in terminal (Terminal → New Terminal) always opens inside whichever folder you have open — if that's your project, you're already set.

Using a plain terminal? Navigate there first (adjust the path to wherever you actually saved it):

$cd Desktop\project-name

$git init

$git add .

$git commit -m "Initial release"

$git branch -M main

$git remote add origin https://github.com/USERNAME/REPOSITORY.git

$git push -u origin main

Swap USERNAME/REPOSITORY for your actual GitHub path.

📁 Make sure your terminal is open inside your project folder before running the commands below.

Using VS Code? Its built-in terminal (Terminal → New Terminal) always opens inside whichever folder you have open — if that's your project, you're already set.

Using a plain terminal? Navigate there first (adjust the path to wherever you actually saved it):

$cd Desktop\project-name

Before pushing changes, a backup branch is a cheap safety net:

$git branch backup-before-push

$git add .

$git commit -m "Describe changes"

$git push origin main

See Undoing a bad deploy (in Put it online) for what the backup branch is for.

Use clear, descriptive messages.

Good

Initial release
Added dashboard filters
Fixed login bug
Improved mobile layout
Refactored API service

Avoid

Update
Stuff
Changes
Test
Fix

Recommended: Semantic Versioning — Major.Minor.Patch, e.g. 1.0.0, 1.1.0, 1.1.1, 2.0.0.

Change	Example
Patch	Bug fixes
Minor	New features
Major	Breaking changes

·

Getting commits live, on Vercel, Netlify, or GitHub Pages — and rolling back cleanly if something goes wrong. Unfamiliar terms are explained in the Glossary in Look things up.

📁 Make sure your terminal is open inside your project folder before running the commands below.

Using VS Code? Its built-in terminal (Terminal → New Terminal) always opens inside whichever folder you have open — if that's your project, you're already set.

Using a plain terminal? Navigate there first (adjust the path to wherever you actually saved it):

$cd Desktop\project-name

First time pushing this project? Run all of these, in order:

$git init

$git add .

$git commit -m "Initial release"

$git branch -M main

$git remote add origin https://github.com/USERNAME/REPOSITORY.git

$git push -u origin main

Swap USERNAME/REPOSITORY for your actual GitHub path. More detail on each of these steps is in Keep your work safe → Your very first time.

Already pushed this project before? Just stage, commit, and push your latest changes:

$git add .

$git commit -m "Describe changes"

$git push origin main

Recommended deployment method. Every push to main automatically creates a new deployment.

Commit │ ▼ Push │ ▼ GitHub │ ▼ Vercel │ ▼ Live Website

Connect the repository once — automatic deployments happen after each push, same as Vercel.

Suitable for static websites that don't need a build server.

Restore from the backup branch created earlier:

$git reset --hard backup-before-push

Force GitHub to match your local state:

$git push origin main --force

Warning: a force push overwrites the remote history. Use only when you fully understand the consequences.

Once the deployment is verified, remove the backup branch:

$git branch -d backup-before-push

·

House rules for structure and naming, common failure points, and a one-page cheat sheet.

Folder structure:

folder structure

project-name/
  src/
  public/
  assets/
  components/
  pages/
  styles/
  package.json
  README.md
  .gitignore
  vite.config.js

Branch naming:

main

develop

feature/...

bugfix/...

hotfix/...

Every repository should include:

README.md

.gitignore

package.json

LICENSE (optional)

CHANGELOG.md (recommended)

📁 Make sure your terminal is open inside your project folder before running any of the commands below.

Using VS Code? Its built-in terminal (Terminal → New Terminal) always opens inside whichever folder you have open — if that's your project, you're already set.

Using a plain terminal? Navigate there first (adjust the path to wherever you actually saved it):

$cd Desktop\project-name

Missing packages — delete node_modules and package-lock.json, then reinstall:

$rm -rf node_modules package-lock.json

$npm install

Dev server won't start — check:

Node version

Package installation

Terminal errors

Missing dependencies

Build fails — run the build and read the first error carefully:

$npm.cmd run build

Most build failures come from: missing imports, syntax errors, TypeScript errors, or missing packages.

Git push rejected — pull, resolve conflicts, then push again:

$git pull

Plain-English meanings for terms used throughout this guide.

Repository (repo)

Your project folder, as tracked by Git — its full history lives here.

Commit

A saved snapshot of your changes, with a message describing what changed.

Branch

A separate line of work that doesn't affect the main version until merged in.

Push / Pull

Push sends your commits up to GitHub. Pull brings changes down from GitHub to your machine.

Deploy / Deployment

Making your project live on the internet, so anyone with the link can see it.

Build

Converting your project's source code into the optimized files a browser actually loads.

Dev server

A temporary local address (like localhost:3000) where you preview your project while working on it.

Environment variable

A setting or secret (like an API key) kept outside your code, so it isn't shared publicly.

Backup branch

A safety copy of your work made before a risky change, so you can restore it if something breaks.

Semantic versioning

A number like 1.2.3 that signals what kind of change was made — bug fix, new feature, or breaking change.

Rollback

Undoing a deployment or change to return to a previous, working version.

Package manager (npm)

The tool that installs and manages the external code your project depends on.

Development

npm installinstall dependencies

npm run devstart dev server

npm run buildproduction build

npx vite previewpreview the build

Git

git add .stage everything

git commit -m "…"save a snapshot

git push origin mainsend to GitHub

Recovery

git reset --hard backup-before-pushrestore backup

git push origin main --forceoverwrite remote

Deployment checklist — before every deployment:

Project compiles successfully

Production build completes

Production preview tested

Commit message is descriptive

Backup branch created

Changes pushed to GitHub

Live deployment verified

Backup branch removed after verification