Ten Boxes Deck
MakerSquare

The Ten
Boxes

How software actually gets built — for people who don't write code.

Pre-work · before we start

Do this before day 1

Every hour of setup done at home is an hour of building in the room. None of it is hard. All of it is slow if forty people do it at once.

Four things to install
Six accounts to create
Four more for day 3
Budget about 40 minutes
Pre-work · 1 of 3

Install these, in this order

  1. Warpwarp.dev. Your terminal. Free.
  2. Node.jsnodejs.org. Take the version it recommends. Claude Code needs it.
  3. Open Warp and type npm install -g @anthropic-ai/claude-code — one line, once, forever.
  4. Type claude and press enter. Sign in when it asks.
You're ready when you can open Warp, type claude, ask it "what can you do?" and get an answer back. If you get there, the hard part is behind you.
Pre-work · 2 of 3

Create these six accounts

AnthropicWith billing added. This is the one that blocks everything else — do it first, not last.
GitHubFree. Pick a username you're happy to be seen with.
VercelFree. Sign up with GitHub — it saves a step later.
SupabaseFree. Sign up with GitHub too.
ClerkFree.
StripeTest mode is fine. Business details can wait.
Pre-work · 3 of 3

Four more, for day 3

All free tiers, about two minutes each. Do them now so day 3 is building rather than signing up.

ExaSearch built for AI. Your agent's eyes on the live web.
ComposioReady-made connections to Gmail, Slack and a few hundred other apps.
SentryTells you when something breaks for a real customer.
ResendSends the email your app produces. Have a domain handy if you own one.
Save every key somewhere you can find it. A notes file is fine for now — we'll show you where they actually belong on day 1. Don't paste them into a group chat.

Every software product fills the same ten boxes.

A booking site. A client portal. An internal tool. Different names in each box — same ten boxes.

The map

Ten boxes, roughly in build order

01Where you build itClaude Code
02Where code livesGitHub
03Where it runsVercel · Render
04Where data livesSupabase
05Who's logged inClerk
06How you get paidStripe
07The modelsClaude
08Hands and eyesMCP · Exa · Apollo
09How your app talksResend · Twilio
10Knowing it worksSentry · PostHog

Learn the boxes and you can read any company's stack in five minutes — including one you've never seen.

The short answer

You need six of them

Claude Codebuild it GitHubstore it Vercelhost it Supabasedata Clerklogins Stripeget paid

A real web app with accounts, a database and payments — not a brochure site. Costs close to nothing until you have customers. Render joins later, the first time something needs to run on a schedule.

Day 1 of 3 · 9:00–4:00

From nothing to live

By 4pm you have a working URL on the internet that you built — and you've watched an agent fix its own mistake.

The ten boxes
Lab 1 · get the tools working
What a harness is
Lock-in, and what actually protects you
The agent loop and how to ask
Reviewing work you can't read
Lab 2 · build something and ship it
Branches and preview URLs
The idea everything hangs off

A model can only do one thing: take text in, put text out.

It can't open a file, visit a website or send an email. Left alone it's a very well-read person locked in a room with no phone.

So what makes it useful?

The model is the engine.
The harness is the car.

An engine on a workshop floor is impressive and useless. The car is the steering, the pedals, the brakes — the parts that turn combustion into going somewhere.

The harness

What a harness actually does

Decides what the model sees. Your project has 4,000 files. It can't hold all of them.
Hands it tools and runs them. The model says "read this file." The harness actually reads it.
Loops. Run, read the error, try again. The model doesn't loop on its own.
Asks your permission before deleting a file or pushing to production.
Remembers your rules — your CLAUDE.md, your skills — every session.

Claude Code is a harness. Cursor is a harness. So is the Claude app on your phone.

Claude Code and the Claude app are the same model.

Everything that makes one more capable than the other is harness. Most of the gap between a demo and something that actually works is harness, not model — and it's the part you control.

Choosing one

Harnesses come in three kinds

The difference is where it lives — which decides how much it's allowed to touch.

In a browser

Lovable, Bolt, Replit. Describe an app in a chat box. Nothing installed. Fastest to a demo — stuck inside their sandbox.

In an editor

Cursor, Windsurf. Sits inside a code editor, helping with the file on screen. Built for people who read code all day — not our route.

On your machine

Claude Code, Codex. Reads the whole project, changes many files, runs it, reads the errors, fixes them. Comes as a terminal tool or a desktop app — same agent either way.

Why we pick the third kind

Only a full agent can run your code, see what broke, and fix it — in a loop, without you clicking anything.

It works the way a contractor does. You describe the outcome; it comes back when the tests pass.

A real fork in the road

Terminal or desktop app?

Same agent, same tools, same loop, same CLAUDE.md. The difference isn't capability — it's how many doors stay open.

Desktop app

Easier, friendlier, faster to start. Visual diffs, side-by-side panes, no black window. It is also a room with one door. Everything you learn is how Anthropic's app works.

Terminal · what we teach

Neutral ground. Every coding agent lives here — Claude Code, Codex, Gemini. Swapping is typing a different word in the same window.

Be precise about this: Claude Code runs Claude either way — the CLI isn't more model-neutral than the app. What differs is the surface. The terminal is a place every vendor ships into. The app is one vendor's product.
The honest trade

Easier today, or optionality later.

The app gets a nervous beginner building an hour sooner. The terminal is the skill that still works when the best tool changes hands — and in this field it will, more than once.

Where this goes

The arc we'd steer you through

Week oneIf the terminal is what stops you, start in the app. Shipping something beats being purist about the window you shipped it from.
Soon afterMove to the terminal. It's one uncomfortable afternoon, and it's where the next three things you'll want already live.
LaterParallel agents, worktrees, scripting, scheduled jobs, running on a server. All terminal-only. The ceiling you'd eventually hit is here, not in the app.

We teach the terminal because it's where you end up anyway.

The loop

What that actually looks like

You describe it Agent decides what to do Changes files many at once Runs it app + tests Done tests pass something broke — read the error, try again This loop is the whole difference. Nothing here needs you between the steps.
Two words, then we move on

Two words. This is all they mean.

TerminalA window that runs text-only programs. Warp is one. You open it before you can start Claude Code — that's the only reason it matters to you.
CLIA program you start by typing its name instead of clicking an icon. claude is one. That's the whole definition.

Open Warp. Type claude. That's the entire ritual.

Box 01 · Where you build it
What we teach

Claude Code

Reads your entire project, edits many files at once, runs commands and tests, and keeps going until it works.

Honest about why — we teach it because it's what we use every day, not because the alternatives are bad. Codex is a genuine peer and does the same job well. Pick one and get fluent; switching around costs more than the difference between them.
The question everyone asks

"Doesn't that lock me in?"

Yes — at the shallowest layer in the whole stack.

LockedThe tool itself. Moving to another coding agent means relearning a tool and losing some of its extras.
Not lockedAll your code. Plain files in git. A different agent reads the same repo tomorrow morning.

You're renting the typist, not the typing.

What survives a switch

Almost everything

Stays yours

Your code and its history. Your database, hosting, logins, payments — every other box is untouched by which agent typed it. Your MCP servers, because MCP is an open protocol other agents speak. Most of your written instructions, because they're markdown.

You'd lose

Muscle memory. Tool-specific extras like skills and hooks. Some prompt tuning. Days of adjustment, not months of migration.

And you can just run two. Two agents on the same repo, same afternoon — they both read files. Comparing them on one task is a real technique, not a compromise.
The reframe

Rank your stack by how hard it is to leave

HardestBrowser builders. Your app lives in their sandbox. This is the real lock-in — and the reason we don't start there.
HardYour CRM. Years of relationships and process inside it.
MediumA proprietary database. Supabase is Postgres, so it's portable. Not everything is.
EasiestThe coding agent. The cheapest decision in the stack to reverse.
What actually protects you

Portability isn't a tool you pick. It's a shape your work is in.

Choosing a weaker, model-neutral tool to stay free costs you capability today against a future where the leader changes every few months anyway. Keeping your work as plain files in git does the job for nothing — and you already do it.

Box 01 · Setup

Getting started

  1. Install Warp from warp.dev. This is your terminal.
  2. Install Node.js from nodejs.org. Take the recommended version.
  3. Run npm install -g @anthropic-ai/claude-code — one line, once, forever.
  4. Move into your project with cd my-project.
  5. Type claude and sign in.
  6. Describe what you want in plain English. No special syntax.
End every session with "commit and push this." It does not do this automatically. That one sentence is the entire discipline.
The highest-leverage thing you can do

Put a CLAUDE.md at the top of your project.

Anything in it is read at the start of every session — your conventions, what not to touch, how you like things done. Write it once. Stop repeating yourself forever.

Box 01 · Memory files

Three layers, one question: who should see this?

ProjectCLAUDE.md in the repo. Committed — every teammate's agent reads it. How this project works: run the tests this way, this deploys there, never touch that.
Personal~/.claude/CLAUDE.md on your machine. Every project you open, nobody else sees it. How you work.
IdentitySOUL.md, pulled in with one line: @SOUL.md. Who you are — voice, values, judgement. Not process.

Project = facts about the code. Personal = preferences about you. Soul = who you are.

Box 01 · Memory files

Which file does this go in?

Project

"Run tests with bin/dev test." Test: would a new teammate need this on day one?

Personal

"Numbered steps, one action each." Test: is this true of you on every project?

Soul

"Tell me bluntly, don't soften it." Test: would it still be true if you changed jobs?

The project file is committed forever. No keys, no passwords, no opinions about colleagues. And it loads every session — keep it to what's genuinely load-bearing.
Example · the project file

CLAUDE.md — in the repo, everyone sees it

riverside-rv-park / CLAUDE.md # Riverside RV Park — booking site ## How to run it · npm run dev starts it locally on port 3000
· npm test before every push. If it fails, fix it — don't skip it. ## Where things are · Pages live in src/app
· Database is Supabase. Migrations in supabase/migrations. ## Rules · Never push straight to main. Branch, preview, then merge.
· Prices are in cents, not dollars. This has bitten us twice.
· Don't touch legacy-rates.ts — it's being replaced.

Facts a new teammate would need on day one. Nothing about you.

Example · your personal file

~/.claude/CLAUDE.md — every project, only you

~ / .claude / CLAUDE.md ## How to talk to me · Numbered steps, one action per step.
· Show me the command — don't describe it.
· Lead with the answer. Reasoning after, only if I need it. ## How to work with me · Ask before anything destructive.
· Commit and push at the end of every session.
· If you're not sure, say so. Don't guess confidently.

Preferences that follow you between projects. Write it once on day 1 and every session after gets better.

Example · who you are

SOUL.md — pulled in with one line

~ / .claude / SOUL.md  ·  referenced from CLAUDE.md as @SOUL.md # Who I am I run a 60-site RV park in Texas with my wife. Twelve years.
Not technical. I learn by doing, not by reading docs. ## What I care about Guests who come back. Not being on the phone at 10pm.
Cash that's predictable across the season. ## How I sound Plain and short. Never say "customers" — they're guests.
No corporate voice. Mine would laugh at it. ## What I'd rather you did Tell me when something's a bad idea. I'd rather hear it now.
Why the third file exists

The first two change how it works. The third changes how it sounds.

Without it you get competent writing that isn't yours — and you'll rewrite every email it drafts. One line, @SOUL.md, pulls the whole file in — which also keeps anything personal out of a repo your team can read.

Box 01 · Reviewing the work

"But I can't read code"

You don't review it by reading it. You review it by seeing what changed and whether it still works.

Ask it to explain itself. "What did you change, and why?" If the answer doesn't match what you asked for, that's your signal.
Look at the diff. Orca shows which files changed and by how much. Thirty files touched for a copy tweak is a red flag even if the contents mean nothing to you.
Make it prove it. "Run the tests." "Open the app and show me it working." That's the only review that counts.
Box 02 · Where the code lives

GitHub

If your laptop died tonight, is the work gone? This box is every file, and every version of every file, kept somewhere that isn't your machine.

CommitSave a snapshot of your changes with a note about what you did.
PushSend those snapshots to GitHub. Until you push, it's only on your laptop.
BranchA parallel copy where you try something risky without touching the working version.
Never commit a password, key or token. Once it's in the history it's effectively permanent.
Box 02 · Branches

Your safety net

There's one branch called main and it is the version that's live. Everything else is a branch off it — a named copy where you can change anything without affecting what customers see.

main untouched this whole time — customers see none of it merge = live your branch commits its own preview URL — the real thing, running
Never work directly on main. On a branch, the worst case is you delete it and nothing happened. On main, the worst case is your customers find out.
Box 02 · Branch vs worktree

Not the same thing

A branch is a version of the history — a label, not a folder. A worktree is the folder of real files you can open. Switching branches doesn't make a folder; it rewrites the one you have.

Normally — one folder, branches take turns your project folder showing: main switch the same folder showing: your-branch the files just changed underneath you With a second worktree — two folders, both open folder one main · agent A working folder two your-branch · agent B working neither one moves the other's files

A branch is which version. A worktree is where it's laid out.

Box 03 · Where it runs
For websites and apps

Vercel

Connect GitHub once. Every push is live about thirty seconds later.

Push to main → the live site updates automatically.
Push to any other branch → a preview URL you can send a client before it replaces the old one.
Secrets go in Settings → Environment Variables. Never in the code.
Not "just static sites." Vercel runs your backend too — logins, database queries, payment handling. A Vercel app with accounts and a database is the most common way authenticated web apps get built today.
Box 03 · Where it runs
For things that keep running

Render

The line isn't frontend versus backend. It's this: Vercel runs your code when someone visits. Render runs your code when nobody is visiting.

Web Service

An always-on backend that answers requests.

Cron Job

Runs on a schedule, then stops.

Worker

Runs constantly, chewing through a queue.

Free services fall asleep. The next visitor waits 30+ seconds for it to wake. Fine for testing, unacceptable for customers.
Day 2 of 3 · 9:00–4:00

Make it a real product

By 4pm your app remembers things, knows who's logged in, and has taken a test payment.

Recap · context windows and compacting
Where the data lives
Lab 3 · add a database
Who's logged in
Lab 4 · add logins
How you get paid
Lab 5 · take a payment
Messages your app sends
Box 01 · Why it goes vague

The context window

The agent holds only so much at once. Your CLAUDE.md, every file it reads, every command it runs, and the whole conversation so far all compete for that space.

Window full CLAUDE.md files it read the whole conversation compact Room again a summary empty What you lost the exact error text the file contents what you said 40 messages ago unless it made the summary
It isn't getting worse. It's working from notes instead of the recording. That's why long sessions drift.
The fix

A conversation is expensive memory.
A file is cheap memory.

Every message re-sends the whole context — so a bloated conversation is vaguer and costs more on every turn. Anything you'll need again belongs in a file the agent can re-read, not in a chat you're nursing along.

Box 01 · Keeping the window clear

Three habits

  1. Start a fresh session for a new task. Cheapest fix by a mile.
  2. Write decisions down as you go. "Add what we just decided to CLAUDE.md" — one line, survives every compact.
  3. Dump session notes into a vault. An Obsidian folder is the usual choice. Next session the agent reads the note instead of you re-explaining.
Why Obsidian — it's plain markdown files on disk. No database, no export, no API. Your agent reads and writes them directly, and the whole vault goes in git so knowledge is versioned like code.
Box 04 · Where the data lives
What we teach

Supabase

A Postgres database plus file storage and an automatic API, with a dashboard where you can see your data like a spreadsheet.

Row Level Security is the one that bites people. With it off, anyone who finds your key — and it's in your website's code, so they can — reads your entire table. Turn it on from the first table, not the fiftieth.
The real fork in the road isn't between database products. It's whether humans need to edit the data directly. If they do, Airtable is a real answer, not a lesser one.
Box 05 · Who's logged in
What we teach

Clerk

Drop-in sign-up and login screens that already look good, plus profiles, social logins and teams.

  1. Create an app at clerk.com and pick your sign-in methods.
  2. Copy both keys into your environment variables.
  3. Tell Claude Code "add Clerk authentication to this app."
  4. Sign up as a fake customer and check it works before anyone else sees it.
Box 05 · The distinction that matters

Clerk answers "who is this?"
Your database answers "what are they allowed to see?"

Two different jobs. Clerk logging someone in does not stop them reading another customer's data. You still have to write that rule.

Box 06 · How you get paid

Stripe

It scales from a payment link you make in a dashboard in ten minutes — no code, no developer — all the way to subscriptions and in-person card readers.

  1. Create an account. Leave it in Test mode.
  2. Add your product and set the price.
  3. Click Create payment link.
  4. Paste it behind a button. You can now take money.
  5. Test with card 4242 4242 4242 4242.
Test and live are separate worlds with separate keys. A test key in production means nobody can pay you.
Box 09 · How your app talks to people

Messages your software sends

Someone signs up. Someone resets a password. A booking is confirmed. Your app has to send that — and it has to land in the inbox, not in spam.

ResendEmail your app produces — receipts, password resets, notifications. One message to one person because they did something.
TwilioPhone numbers and SMS. Booking reminders, two-factor codes, and the line an AI receptionist answers on.
Skip the DNS records and your email goes to spam. They prove to Gmail you're allowed to send as your own domain. Non-negotiable.
A distinction worth holding

Software you build is not the same as software you run.

Your CRM, your forms, your scheduling link, your chat widget — HubSpot, Tally, Cal.com, Intercom — are bought, logged into and configured. They matter enormously and none of them are in these ten boxes. Every box here is a component you wire into your product.

Day 3 of 3 · 9:00–4:00

Make it run without you

By 4pm you have an automation doing a real job unattended, tests guarding it, and two minutes on stage.

The models
Giving AI hands and eyes
Lab 6 · build one real automation
Context, compacting and hiring
Keys, secrets and security
Knowing it works
Lab 7 · tests, Sentry and polish
Open source, and keeping up
Demos
Box 07 · The models

Models split by job, not by brand

ClaudeThinking and writing. Long documents, code, following instructions without drifting. GPT and Gemini are fine alternatives — not worth agonising over.
WhisperSpeech to text. Turns a recording or a call into a transcript.
ElevenLabsText to speech. A voice that doesn't sound like a robot.
This box changes fastest. Vendors get replaced every few months. Build so swapping one out is small, and don't fall in love.
Boxes 07 + 09 · Worked example

How an AI phone agent is actually assembled

A customer rings a normal phone number and talks to an agent. Here's every piece behind that.

  1. Twilio owns the phone number and answers the call, then streams the live audio onward.
  2. Whisper or Deepgram turns what the caller said into text, as they're saying it.
  3. Claude decides what to say back — and what to look up first.
  4. Tools check real availability, make the booking, take the payment — the plumbing for that is box 08, next.
  5. ElevenLabs turns the reply back into a voice, fast enough that it doesn't feel like a wait.
Newer models collapse the middle. A realtime voice model hears and speaks directly, replacing steps 2 and 5 — which is how RoverPass's own front desk agent works. You still need Twilio either way: somebody has to own the phone line.
Why that example matters

Nothing in that list is exotic. It's five boxes, wired together.

A phone line, a transcriber, a model, some tools, a voice. Once you can name the pieces, "we built an AI receptionist" stops sounding like magic and starts sounding like an afternoon.

Back to the harness

Three parts, and you've now seen two

This is what people mean by "an AI agent" — not one product, three things arranged together.

The model

The thinking. Box 07. Swappable.

The harness

The loop, the permissions, the memory. Claude Code.

The tools

The reach. Box 08 — this one.

When someone says they built an agent, these are the three things to ask about.

Box 08 · Hands

How does the AI actually send the email?

Instead of writing you one to copy and paste. It needs hands — and there are two kinds.

Rules — you decide

"When a form is submitted, add a row and send a Slack message." Same way every time. Zapier.

Agents — it decides

You describe an outcome. It works out which tools to use. MCP, Composio.

Which one

Rules for anything that must happen identically. Agents when the work needs judgement.

Box 08 · The distinction people get wrong

API vs MCP

APIHow two pieces of software talk. Decades old. A fixed menu of operations — and a human writes code for each one.
MCPHow an AI talks to that same software. Wraps the API in a description the model can read, so the model picks the right operation itself.

An API is a door. MCP is a door with a sign on it the AI can read.

MCP doesn't replace APIs — it sits on top of them. What's new isn't the access. It's that nobody hand-writes the glue any more.

Box 08 · Where Composio fits

They're layers, not competitors

These three names sound like rival products. Each one sits on top of the one above it.

APIThe connection itself. Stripe, Gmail and your CRM all have one. It exists whether or not any AI is involved.
MCP serverA wrapper around an API, describing it in terms a model can read. Somebody has to write it — often the company whose API it is.
ComposioHundreds of those wrappers already written — plus the part nobody wants to build: logging your accounts in and keeping them connected.

No AI in the loop? Just use the API. Agent deciding? MCP. Don't want to write it? Composio.

Box 08 · Eyes

Where the agent gets facts

A model knows what it was trained on. It doesn't know what happened this week, or anything specific about the company you just named. This is why agents make things up.

Exa"What's out there about this?" Search built for AI — returns page contents, not just links.
Apollo"Who works there and what's their email?" Companies and the people inside them.
DataForSEO"Where does this rank?" Live search results and map-pack positions, as data.

The model supplies judgement. These supply facts.

Box 08 · Eyes

There are hundreds. They cluster into eight.

Your agent MCP · Composio one way in, whatever sits on the other side The live web Exa · Firecrawl · Perplexity People & companies Apollo · Clay · Hunter Your CRM HubSpot · Attio · Zoho · Salesforce Search & rankings DataForSEO · Search Console Money & books Stripe · QuickBooks · Xero Inbox & calendar Gmail · Outlook · Slack Files & docs Drive · Notion · Dropbox Your own database Supabase · Postgres · Airtable …and whatever your industry has: booking channels, MLS, POS, dispatch, lab systems

The categories are stable. The vendors churn.

Box 08 · The fallback

When there's no API at all

An old supplier portal. A competitor's site. A government database with a search form. The fallback is blunt and it works: let the agent use the website the way a person would.

Playwright

The robot that clicks through a site. You'll meet it again in box 10, testing your own.

Browserbase

Runs that browser in the cloud, steered in plain English. Handles staying logged in and looking like a real visitor.

Last resort, not first. Slow, costs more, and breaks whenever the site changes layout. If an API or MCP server exists, use that.
All of it, assembled

One instruction, five tools

"Find fifteen RV parks in Texas without online booking, and draft an intro email to each owner."

Eyes — Exa searches the live web and reads each site to check for a booking widget.
Eyes — Apollo turns each park into a named owner with a real email address.
Judgement — the model writes fifteen different openers, each referencing what it actually saw.
Hands — Composio drops all fifteen into Gmail as drafts.
You — read them and hit send.

That's the whole job. It's one instruction.

Scaling up · one rung up

When one agent isn't enough

A terminal runs one agent at a time. Soon the bottleneck is you, waiting for it. Run several at once and they overwrite each other — unless each gets its own copy.

Worktree — a second complete copy of your project on disk, on its own branch, sharing the same history. Two agents, two folders, no collisions.

Warp

A terminal. One agent at a time, in a window you can click and scroll like a normal app. Where you start.

Orca

Also a terminal — built to run several agents at once, each in its own worktree. Adds a diff view, GitHub and Linear, and a phone app.

Same kind of tool, different amount of it. Get fluent with one agent before reaching for many.

Throwing compute at a problem

An agent can hire.

Instead of doing a big job itself, it breaks the job up, runs helpers in parallel, and collects what they found. One instruction becomes twenty agents working at once.

Orchestrators and subagents

One instruction, four context windows

You one instruction Coordinator splits the job up worker · own context reads, reports back worker · own context reads, reports back worker · own context reads, reports back worker · own context reads, reports back One answer summaries only

Four agents can read four hundred files between them and your window only receives four paragraphs. The context problem, solved by delegation instead of discipline.

Orchestrators and subagents

Two shapes

SubagentsHelpers inside one session. Each gets its own fresh context, does one job, reports back a summary. For reading — research, search, review.
OrchestratorA coordinator splits the job into tasks and launches a worker for each, each in its own worktree. Heavier, and the right shape when workers are writing code.

Reading fans out cheaply. Writing needs isolation.

Orchestrators and subagents

How to break a job up

  1. Split into pieces that don't touch each other. Two tasks editing the same file aren't independent — sequence them.
  2. Give each piece a clear "done." "Find every place we mention the old pricing" beats "look at the pricing stuff."
  3. Fan out anything you'd otherwise repeat. The same question across twelve accounts is twelve workers.
  4. Verify separately from building. A fresh agent checking the work catches what the author can't see.
Ten agents costs roughly ten times one agent. You're buying wall-clock time and coverage, not a discount. And if step two needs step one's answer, running them at once just gives you two confident agents and one wrong result.
Box 10 · Knowing it works

Three different questions

SentryIs it broken right now for a real person? Messages you the moment it breaks, with the exact line. Install before launch.
PlaywrightDid I just break something? Drives a real browser through your site like a customer.
EvalsTesting for AI. You can't unit-test a sentence, so you grade output against examples.
PostHogIs anyone using this? What people click, where they give up, replays of real sessions.

When AI writes the code, this box matters more, not less. You didn't write it — you can't eyeball it.

Cuts across all ten

Keys and secrets

Your app needs secrets. They can't live in the code, because the code goes to GitHub — and GitHub repos have a way of becoming public.

.env on your laptop, gitignored never committed retyped Vercel Settings → Environment Variables Render same names, same values GitHub never, not once
Security

Two kinds of key

PublishableSafe in the browser. Anyone can read it and that's fine. Clerk publishable, Supabase anon, Stripe publishable.
SecretServer only. Never in front-end code, never committed, never pasted in a chat. It can do anything your account can.
The prefix is a decision, not a label. Anything named NEXT_PUBLIC_… or VITE_… is compiled into the page and shipped to every visitor. Put a secret behind that prefix and you've published it.
Security

The test that actually finds bugs

  1. Make two accounts in your own app.
  2. Log in as the first and create something.
  3. Log in as the second and deliberately try to reach the first one's data.
  4. If you can see it, you have a bug — and you found it instead of a customer.

Reading a policy tells you what it was meant to do. Trying to break it tells you what it does.

Security · the honest limit

"Check this for security problems"

A genuinely good habit that will find real things. It is not a security review.

It does catch

Keys in code, missing RLS, a secret behind a public prefix, known-vulnerable dependencies.

It can't know your rules

It has no idea one park owner shouldn't see another's bookings. Most real breaches are business logic, not code bugs.

It can't un-leak

A key committed three weeks ago is already out. Scrapers watch public repos. Only rotating it helps.

Security

An agent can check your work. It can't be the reason you're safe.

Rent the hard parts — logins from Clerk, payments from Stripe; their security team is bigger than your whole company. And when it's money, health data, or anything you'd have to write an apology email about, that's a paid review, not a prompt.

The layer nobody sells you

Half of what we taught you was built by strangers and given away.

Anthropic makes Claude Code. It didn't make most of what gets plugged into it. MCP servers, skills, agent setups, the templates you'll start from — written by people you'll never meet, published free, improved by whoever turns up.

Open source · where it lives

Two places, doing two different jobs

GitHubThe code itself. The README is the manual. Lists like awesome-mcp-servers are how you find one for a tool you already use.
XWhere you find out it exists. Still Twitter to most people. No press release, no docs update — somebody posts a thread on a Tuesday night and by Thursday it's in everyone's setup.
DiscordWhere you go when it breaks at 11pm. Most projects have one and the link is in the README.
Reddit · HNSlower, more sceptical, and better at telling you something is overhyped.

GitHub is where it is. X is where you hear about it.

Open source · keeping up

Twenty minutes, twice a week

The feed is built to eat your whole day. Treat it like a trade paper, not a group chat.

  1. Make one X list. The accounts for tools you actually use, plus whoever wrote the repos you've installed. Fifteen accounts, not five hundred.
  2. Read the list, never the timeline. The timeline shows you what's loud. The list shows you what you picked.
  3. Ask one question: does this fill a box I already have, or is it a box I don't have? Everything else is entertainment.
  4. Don't install it the day you see it. Give it two weeks of other people finding the bugs.
Every demo video is the one take that worked. Forty seconds of magic, and no footage of the ninety minutes before it.
Open source · the part to be careful about

You're running a stranger's code with your keys

Installing an MCP server hands somebody else's program your Gmail, your database, your Stripe account. Most authors are honest. That isn't the same as safe.

Check it's alive

Commits this month. More than one contributor. Issues that get answered. 8,000 stars and nothing since March is a museum.

Prefer the official one

If Stripe publishes a Stripe MCP server, use that — not the fan version with the nicer name and the bigger promises.

Start in test mode

Point anything new at test keys or a throwaway account for a week. Then decide whether it gets the real ones.

Rules of thumb

The nine that matter

Nothing is real until it's pushed.
Never build your own login.
Start with a Stripe payment link. Move up when something forces you to.
If your data is leads and customers, your CRM is your database.
Cheap model for bulk sorting. Best model for anything a customer reads.
The model supplies judgement. Tools supply facts.
Rules for what must happen identically. Agents when it needs judgement.
A test nobody runs is a comment.
If you can't name the problem it solves for you today, you don't need it today.
One thing to remember

Tool names
will change.
The boxes won't.

Learn the ten boxes, and every new tool is just a name you can place.

← → to move · F for fullscreen