In Class 24 you learned to name the workload: request-driven, scheduled, long-running, bursty, latency-sensitive, stateful, or compute-heavy. Naming the work came first on purpose. Now that you can say *what* needs to run, the next question is *where* it should run — and the honest starting place is the machine already in front of you.

What "local" actually means

Local work means code runs on your own computer. You edit files, start the app, open localhost:3000 in a browser, read the logs scrolling past in your terminal, change something, and reload. Everything is within arm's reach: the source files, the running process, the test database, the debugger.

That closeness is exactly why local is the best place to build. Debugging is fast because you can inspect anything. Experimenting is safe because nothing you break affects a real user. Trying a wild idea costs nothing — you throw away the branch and nobody ever knew.

A workshop is the right comparison. A woodworker's shop is where things get cut, fitted, sanded, and tested. It is not where customers buy furniture. Your laptop is the same: the place where the product gets built, debugged, and inspected — not the place where it lives for the public.

Where the workshop breaks down

Five limits make a laptop unsuitable as a production system. Learn them plainly so you stop fighting them:

1. Sleep. Close the lid, and your processes stop. A visitor arriving at 3 a.m. finds nothing awake to answer. 2. Changing network. Home and café networks change addresses, drop connections, and sit behind routers you do not control. There is no stable public address a domain can reliably point to. 3. Local-only secrets and data. Your .env file holds development keys and test rows. Those are not the production credentials or the real user data, and copying them outward by hand is how leaks happen. 4. One person's environment. Your laptop has your exact runtime versions, installed packages, and file paths. "It works on my machine" is a report about your machine, not a deployment plan — which is why Class 24 introduced containers. 5. No reliable public address. Even when the laptop is awake and online, the public internet has no dependable route to it. A product needs a stable front door; a laptop keeps moving the door.

None of these are flaws. They are the nature of a workshop. The mistake is asking the workshop to be the storefront.

The normal flow: local → preview → production

Professional teams move every change through three named places. Learn the word environment now, because the rest of the course uses it constantly: an environment is a named place where your project runs, each with different settings and data.

local (your laptop: build and debug)
  → preview (a hosted copy of one change, for review)
    → production (the public product real users touch)

Local is where you write and break things with test data. Preview is a hosted copy of a single branch or pull request — a shareable link where you or a reviewer clicks through the change with realistic-but-safe data before it goes public. Vercel's preview URLs are the classic example: every pull request gets its own live address. Production is the real thing: real domain, real database, real users, real consequences.

The same project travels through all three, but the settings and data change at each stage. Local uses development keys and throwaway rows. Preview uses staging keys and scrubbed or sample data. Production uses live keys and real user data. Secrets live in each environment's settings — never copied casually between them.

Work on localhost, but Git is the source of truth

Do your daily work on localhost — and treat GitHub or GitLab as the source of truth, never the laptop. The laptop can be lost, wiped, or drift out of sync. The repository is the version everyone and every deployment reads from. Production should deploy from Git (a merge to main triggers Vercel or your platform), never from a manual upload off one machine.

Make this the rhythm of every session, solo or with an AI agent:

start session → git pull (sync to truth)
  → branch per task → work on localhost → commit
    → git push (publish the truth, even WIP)
      → pull request → preview → merge → git pull again

1. Pull at the start. git status, then git pull (or fetch + rebase) before you touch anything. You are syncing to what the team — and the last agent session — already decided. 2. Branch per task. One change, one branch. "It works on my machine" becomes reviewable the moment the branch is pushed. 3. Push at the end of every session. Even work-in-progress goes up on its branch. A pushed branch survives a dead laptop and lets the next session, teammate, or agent continue from truth instead of reconstructing your local folder. 4. Merge through preview. Open a pull/merge request, let checks run, click the preview link, then merge to the branch that deploys production. Then git pull locally so the next session starts clean.

If an agent edits files for you, the same rule holds: no session ends with unpushed work sitting only on localhost. Push the branch, note the commit in your handoff, and the next session pulls first. Class 6 taught the commands; this is the habit that makes them protect you.

The important exception: a Mac mini that stays on

Here is the boundary Class 24 drew, restated so it sticks. Your everyday laptop is local development. But a Mac mini deliberately left on — continuous power, always-on internet, sleep disabled, a recovery plan after reboot — and assigned real jobs is no longer "a spare computer." It is a local server.

A local server can be a sensible first step. It keeps sensitive project files, development tools, and experimentation under your physical control. Local coding agents, scripts, an MCP server, or a home-lab service can all run there. But accept the operational role honestly: it needs the same care Class 24 described for a VPS — updates, access control, backups, logs, monitoring — plus responsibility for the physical location. A home internet outage takes it down. That tradeoff is worth it when local control matters most; it is not worth it as a way to dodge operations work.

A ByeBuy example across all three environments

Take the ByeBuy data-source card — the small component that shows where a product fact came from, with a source name, date, and link.

You build the card locally with test data: three hand-written source rows, no real credentials, fast iteration on layout and citation format. When it looks right, you open a pull request and a preview deployment renders the same card with staging data so a reviewer can check it. When the review passes, the change merges and the production site serves the card to real visitors from the real database.

The scheduled fetch behind the card — the job that checks sources for fresh data — runs remotely, on a managed platform or a VPS, because it must fire when your laptop is closed. The one exception: if keeping that fetch under your physical control outweighs reliability and networking tradeoffs, run it on a dedicated Mac mini as a local server. Either way, the decision is deliberate, and the laptop-as-workshop stays out of production.

Practical exercise: map your three environments

Open INFRASTRUCTURE-NOTES.md from Class 24 and add a three-row table:

| Environment | Who can access it | Which data is safe there | What a mistake could affect |

|---|---|---|---|

| Local | | | |

| Preview | | | |

| Production | | | |

Be specific. "Local: only me; throwaway test rows; a mistake wastes my afternoon." "Preview: me plus reviewers via link; scrubbed sample data, no real user records; a mistake confuses a reviewer." "Production: the public; real user data under real access rules; a mistake affects real users and real data."

Finish line: three filled rows in INFRASTRUCTURE-NOTES.md that separate who, what data, and what blast radius per environment.

Verify: cover the "mistake" column and ask a stranger to guess it from the "access" and "data" columns. If they cannot, the rows are still vague.

Common failure mode: putting real user data or production keys into local or preview "to make testing realistic." That converts a safe workshop into a breach waiting to happen. Use scrubbed samples instead.

Check your understanding

1. Name the five limits that disqualify a laptop as a production system. 2. What travels unchanged through local, preview, and production — and what changes at each stage? 3. Why is GitHub/GitLab the source of truth instead of your laptop, and what do you pull and push each session? 4. When does a Mac mini stop being "local development" and become a local server? 5. Why does preview use scrubbed or sample data instead of the production database?