Terminal, files and folders

The terminal is where you type commands instead of clicking. It's the single biggest psychological barrier for non-technical founders, and the gap between how scary it looks and how simple it is might be the largest in all of software.

One thing first, because it removes most of the intimidation: you don't need a separate black window. As the last page showed, it's a panel at the bottom of your editor — Ctrl+` — already pointed at your project. Open it there and read on.

You need about five commands. That's the whole syllabus.

What the terminal actually is

Everything you do in Finder or File Explorer — open a folder, make a folder, rename a file — you can do by typing instead. The terminal is just that, plus the ability to run programs that have no window.

The crucial idea: the terminal is always "standing" in one folder. Commands you type apply to wherever it's standing. Most beginner confusion — "it says the file doesn't exist but I can see it right there" — is just standing in the wrong place.

How a web project is laid out

Open any modern web project and you'll see roughly this. It looks like a lot; most of it you will never touch.

my-app/
├── node_modules/      ← thousands of downloaded libraries. NEVER touch, never commit.
├── public/            ← images, fonts, favicon — files served as-is
├── src/               ← YOUR CODE LIVES HERE. This is the folder that matters.
│   ├── app/           ← your pages (in Next.js, a folder per URL)
│   ├── components/    ← reusable pieces: buttons, cards, nav
│   └── lib/           ← shared logic: database access, helpers
├── .env.local         ← SECRETS. Passwords and API keys. Never commit this.
├── .gitignore         ← the list of things Git should ignore
├── package.json       ← your project's ID card: name, dependencies, commands
└── README.md          ← notes for humans

Four of those are worth genuinely understanding:

package.json

Your project's ID card. Two sections matter. dependencies lists every third-party library your app uses and which version. scripts lists shortcut commands — that's where npm run dev comes from. When someone says "what's your stack", the answer is largely in here.

node_modules

The actual code of all those dependencies, downloaded onto your machine. It's frequently hundreds of megabytes and tens of thousands of files. You never edit it, never open it, and never commit it — anyone can rebuild it from package.json by running npm install. If you ever see it in a Git commit, something is misconfigured.

.env.local

Where secrets live: database passwords, API keys, anything that would let a stranger act as you. Files starting with a dot are hidden by default, which is why people forget they exist. This file must never leave your machine except by being re-entered by hand into your hosting provider. See Security and spend — this is the mistake that bites hardest.

.gitignore

A plain list of things Git should pretend it can't see. node_modules and .env.local should both be in it, always, in every project.

The commands you'll actually run, every day

Reading the wall of text

When something fails, you get a large block of output and the instinct is to panic and scroll past it. Don't. It's structured, and you only need the top of it:

• The first error is the real one. Everything below is usually knock-on damage. Scroll up to the first red block, not down.
• Find the file path with a line number — something like src/app/page.tsx:42. That's where to look, and clicking it in Cursor takes you there.
• Yellow warnings are usually ignorable. Red errors are not. "Deprecated" means old, not broken.
• Anything mentioning node_modules in the path is a problem in someone else's code, triggered by yours. Usually a version mismatch.

And the actual technique, which is allowed and correct: copy the whole error and paste it to the AI. All of it, including the parts that look like noise. More detail in When it breaks.

I'm a non-technical founder on [macOS / Windows 11]. I have never used the terminal. Teach me in a hands-on way, not as a reference list.

Give me 10 short exercises in order, each building on the last, that take me from "afraid of the black window" to "comfortable navigating and creating projects". Cover: where I am, moving around, making and removing folders, creating and reading files, tab completion, command history, and what a file path actually is.

Rules:
- After each exercise, tell me exactly what output I should see, so I can confirm I got it right.
- Flag any command that could destroy something, and explain the safe version.
- Use the correct commands for MY operating system, and mention where Mac and Windows differ.
- No analogies. Just tell me what things are.

Look at the folder I'm currently in and give me a guided tour, written for a non-technical founder who understands HTML and CSS but nothing else.

For every top-level file and folder:
1. What it's for, in one sentence
2. Whether I will ever need to open it myself (yes / rarely / never)
3. What would break if it were deleted

Then answer these:
- Which single file should I read first to understand what this project does?
- Where does the page a visitor sees first actually live?
- Which files contain secrets, and are they correctly ignored by Git?
- If I wanted to change the site's colours, which file would I edit?

Finish with the three commands I'll type most often in this specific project and what each one does.

I'm a non-technical founder. I ran [command] and got this output:

[paste the ENTIRE output, including everything that looks like noise]

Please:
1. Tell me in one plain sentence what actually went wrong.
2. Point out exactly which line of that output is the real error, and which lines are just noise I can learn to ignore.
3. Explain why it happened, in terms of what my project was trying to do.
4. Give me the fix, and tell me what the fix does rather than just what to type.
5. Tell me how to avoid this class of problem in future.

Don't change any files yet — I want to understand it first.