The dev foundations (plain-language)

You don't need to write any of this. You need to understand it well enough to make good calls and smell trouble. Every term here is in the glossary too.

2.1 Version control, and why "not pushed" means "does not exist yet"

Version control records the history of your code: who changed what, when, and lets you go back. Its online home is the reference copy, the backup, and the meeting point.

The words you'll actually use: a repository is the versioned project. A commit is a dated snapshot of a set of changes, with a message. A branch is a parallel line of work; the main line is usually called "main" and is your production. Push and pull send your local commits up and pull others' down. Merge folds one branch into another. A pull request is a request to merge, usually reviewed first.

The lesson paid in time: a commit that isn't pushed lives only on your machine. A re-clone or a local incident erases it. The rule: push after every unit of work. Local is fragile, the push is the backup. I've lost unpushed work twice. Recovered both times, but those are hours you don't get back.

For the CTO in you

when several accounts share one machine, a push can fail with "repository not found" simply because the wrong account is active. Switch accounts before you push.

2.2 Branches and review

The classic model: main is production, sacred, always deployable. You work on a branch, verify, then merge into main. Some teams keep a long "preprod" branch: push there, check the preview URL, then merge to main. Code review is the moment a peer re-reads before merge. With AI, review becomes two things at once: you re-read what the AI produced, and the AI does a review pass of its own. Two readers beat one.

2.3 Environments, config, and secrets

A product lives in several environments: local (your machine, to build), preprod or staging (an online copy to validate before prod), and production (what real users see). Environment variables configure the product per environment, like an API address or a public key. Two families matter. Non-sensitive config can live in the code. Secrets (API keys, powerful access keys, payment secrets) never go into version control. They're set by hand in your host's dashboard and persist across deploys.

The golden rule, worth tattooing: the powerful key, the one with full access to your database, is never in the frontend. Only server-side. The frontend gets a public, restricted key, fenced in by database rules. If a full-access key ever reaches the browser, assume the database is open to the world.

Keep an environment-variable matrix: a simple table of every variable, where it lives (in code, in a secret store, in the host dashboard, in your local file), and who sets it. Missing variables get discovered at deploy time, in the worst mood, over and over, unless you keep the map.

2.4 The backend building blocks

You won't build these from memory. You'll recognize them, and know which ones a feature touches, so you can ask the right questions.

An API is the interface the frontend, or a third party, uses to talk to the backend; a request lands on an endpoint, a URL plus a method. Auth is proving who you are, usually with a signed token sent on each call and checked by the server. A webhook is a call a third party makes to you when something happens, like a payment provider announcing "this invoice is paid." Rate limiting caps requests per period to stop abuse. Idempotence makes sure the same operation played twice doesn't double its effect, which is critical for payments and replayed webhooks. Encryption protects sensitive data at rest, like stored keys locked with a server-side secret.

2.5 Dependencies are power and risk

Every package you install is leverage you didn't have to build, and a door you now have to trust. Two habits keep it sane. Lock your versions: a lockfile pins the exact version of everything, so your build is identical today and in six months, on your machine and in production. And resist the blind auto-fix: a command that "fixes" every security warning by force-upgrading everything will happily break your app to silence a warning that never applied to you. Read what a fix changes before you run it. Fewer dependencies, chosen on purpose, beat a pile you can't account for.

2.6 Your product is a graph of services

A modern product is not one thing, it's a graph: a database, a payment provider, an email sender, an AI model, a chat integration, a host, a job runner. Each node is a point of value and a point of failure. Draw the map, even roughly, and for each node ask two questions: what happens to my users if this is down, and what does this one cost me. You don't have to make each one unbreakable. You have to know where the single points of failure are, so an outage is a known risk and not a surprise.