The glossary

A machine that follows instructions, extremely fast. Everything else is just organised ways of giving it those instructions.

The instructions themselves, written in a language a computer eventually understands.

The base layer — Windows, macOS, or Linux — that manages hardware and how programs run.

Most AI coding tools are built on Mac/Linux. Windows works — often via one extra step (WSL).

A real Linux environment that runs inside Windows, alongside your normal desktop.

On Windows, run vibe-coding tools inside WSL so you match the Mac/Linux setup they were built for.

A document your browser can request and display. A single-page site is one link, and on disk, one file.

A desktop app (Chrome, Firefox, Edge) that requests and renders web pages by exchanging HTML with a server.

What the content is — headings, text, images, and structure.

The styling layer. Turns plain content into something that looks like your brand.

Makes the page interactive — clicks, popups, loaders — without a full reload. Runs in the visitor's browser, not your server; it can't remember anything between visitors on its own (see Layer 5).

A human-readable name — adensmowing.com — bought from a registrar.

Translates a domain name into the IP address of the computer that will answer.

The address of a specific computer on the internet.

A numbered lane on that computer for one kind of traffic, so everything doesn't collide.

HTTP 80, HTTPS 443, SSH 22 — these three cover almost everything early on.

Software listening on that port that returns the right file or response when your domain is requested.

Hosts like Vercel run this for you. Knowing the layer helps you name what broke.

Like a spreadsheet: rows and columns, each column typed (text, number, date…).

One entity per table — a tab in that spreadsheet. A mowing business might have businesses and locations.

A single typed value on a row — name, email, date.

One-to-many. A business has many locations; those locations belong to that one business.

The other direction — each location belongs to exactly one business.

The overall shape — every table, column, and relationship — sketched before application code.

Do this first or you get 80 accidental tables. Vibe code the schema, then build on it.

Fixed content that only changes when you edit it by hand. Fine for a brochure, not for a growing list of leads.

Runs in the visitor's browser. Great for UI; no lasting memory of its own, and can't touch your server's data alone.

Server-side logic that can save and query state — it talks to a database, not a static file.

Front end and back end wired together: visitors add data, you query it later — nothing frozen at deploy time.

A defined way for two systems to exchange data — request in, response out.

The data you send, and the shape it's in — JSON, form fields, or a file on a URL. The API decides which it wants.

Wiring one system's output into another's input — form → spreadsheet, webhook → queue, app → payments.

Most “impossible” bugs are really: this data isn't where the next step needs it yet.

Name it as get-data-from-A-to-B and it becomes a series of solvable steps.

A server can only process a file once that file exists somewhere it can reach.

Moves a file from the user's device onto your server (or a bucket) so the back end can use it.

A large share of real work is moving data between two things that don't natively understand each other.

A named, reusable block that does something — and often returns a result.

A branch: do this if true, otherwise do that.

Repeats an action — for a fixed count or list, or while a condition stays true.

Look at a feature and ask: function? if? loop? Naming the block tells you what to write.

Built for your own business. The data model is easy — it's just your customers, emails, and jobs.

Sold to other companies; each company's data stays separate inside the same product.

Scaling, security, and logistics get harder — spirits to an internal tool's beer.

Owner/operator of the whole product — sits above every tenant.

Admin of one business that signed up to use your product.

People using the product day to day inside a tenant — often several roles with different permissions.

Roles usually share one users table — that's what makes multi-tenant login tricky.

A change to database structure after real data is already in it — e.g. one-to-one → one-to-many.

Easy on an empty table, hard on a live one. Decide the shape before data piles up.

Picture the page you're building: what data is visible? Each distinct thing becomes a table.

Name and group tables by what the data is in the real world — not what's convenient to type today.

A listing is a property; rental history and sale history are separate tables because that's how the world is shaped.