This is usually where people brace themselves. Installing things, terminal windows, cryptic errors before you've written a single line.
It's less bad than it used to be. And the thing that changed most isn't the tools, it's that you now have something that will explain any of it to you, patiently, as many times as you need to ask.
What you actually need
Not much. For most first apps, four things.
A code editor, which is where your files live and where you'll watch things being written. VS Code is free and what most people use.
Claude, either the normal chat or Claude Code, which runs in your terminal and can create and edit files directly. Chat is the gentler start. Claude Code is faster once you're comfortable.
A terminal, the black window where you type commands. It's already on your computer. You'll use about five commands ever, and you can ask what each one does before you run it.
And Node.js, but only if you're building something web-based, which you probably are. It's the thing that lets JavaScript run on your machine. One install, then you'll mostly forget it exists.
That's the whole list. You can ask Claude to walk you through any of it for your particular operating system.
The jargon, defused
You're about to meet a lot of words that sound like they mean something profound. Most of them mean something quite ordinary.
| Word | What it actually means |
|---|---|
| Repo | A folder with your project in it that remembers its own history |
| Commit | Saving a snapshot of your work, with a note about what changed |
| Deploy | Put your app on the internet so other people can use it |
| Frontend | The part people see and click |
| Backend | The part on a server that remembers things |
| API | A way for two pieces of software to talk to each other |
| Dependency | Someone else's code that your project uses |
| Bug | It's broken |
None of these are difficult ideas. They're words invented by people who already understood the thing, which is how most jargon happens in any field.
If you hit a word that isn't on that list, just ask. "Explain what a webhook is like I've never programmed" is a perfectly reasonable thing to type, and you'll get a better answer than most tutorials manage.
What a first session actually looks like
Less dramatic than you might be imagining. Roughly this.
You describe what you want to build in normal language, and mention that you're new. Claude suggests an approach and asks a few questions. You say which bits sound right. It writes some files. You run them. Something's broken. You paste the error back. It gets fixed. It works.
That loop, over and over, is most of building software now. The skill isn't memorising syntax any more. It's describing what you want clearly, and noticing when what comes back isn't quite right.
One thing worth doing early: say you're a beginner. Not out of modesty, but because it genuinely changes the answers you get. You'll receive explanations alongside the code rather than just code, and it'll stop skipping the steps that assume you already know the surrounding context.
Choosing what to build it with
You'll be offered a lot of choices, and people online hold strong opinions about all of them.
For a first app, the specific choice matters much less than picking something popular and sticking with it. Popular means more examples, more answers when you're stuck at midnight, and an AI that has seen the pattern thousands of times.
The thing worth optimising for isn't speed or elegance. It's how easily you can work out what went wrong, because you'll spend more time fixing than building. A boring tool you can debug beats an exciting one you can't.
A quick story. I learned to code in college the traditional way. Long hours, a lot of projects, plenty of grinding through problems alone because that was the only option on offer.
I'm glad I know what's underneath. But I want to be honest with you about something: you don't have to do it the way I did. Most of that effort went into memorising things and fighting syntax errors, and almost none of it went into the parts that actually decide whether an app works out.
If you find yourself spending your energy the way I did back then, in this era, something's off. The hard work has moved. It's in picking the right problem, judging whether what came back is any good, and actually shipping the thing. Those are the parts worth your late nights, and they're the parts nobody can do for you.
Getting unstuck, which will happen today
You'll hit something confusing quickly. Everybody does. A few things that help.
Paste the whole error, not "it doesn't work." The actual red text, all of it. The error usually says what's wrong, just in an unfriendly accent.
Say what you expected and what happened instead. "I expected the page to load and it's blank" gives far more to work with than "it's broken."
Start a fresh conversation when things get tangled. Long messy threads confuse things. A clean start with a clear description often fixes what twenty more messages couldn't.
And ask why, not just how. "Why did that fix it?" costs you ten seconds and it's how you gradually stop needing to ask.
What comes next
By this point you've got an idea worth pursuing, some sense of whether people want it, a first version small enough to actually finish, and the tools sitting on your machine.
Chapter 2 is the building itself. Screens, data, logins, and why some apps just look more real than others. It's the part that seems most intimidating from the outside and is, honestly, one of the more straightforward parts once you're in it.
If you want a hand with setup
That last instruction earns its place. Left alone, it'll skip the step it assumes everybody knows, and that's reliably the exact step you're missing.
That's Chapter 1. Chapter 2 is where you start building.
Next: How to talk to Claude about code →
Go deeper: Chapter 15, Choosing Your Tech Stack and Chapter 16, Project Architecture