From Zero to
a Working App
Stock alerts for a real business — a tile retailer with a Friday Excel habit and a stock problem.
Session 0 — Think Like a Builder. 1.5–2 hours. No laptop needed.
→ next · N speaker notes · O slide list · F full screen
You will not become a programmer.
You will become something arguably more useful: a person who can direct software into existence.
A real app a real business can use
Weekly stock summary, low-stock alerts, dead-stock alerts. Running by itself every Friday.
The skill is not writing code
The skill is thinking clearly about the problem, and directing Claude well.
Project: Stock Update & Alerts
- Weekly stock movement — which SKU came in / went out and how much, each week. (Currently someone updates an Excel file manually every Friday.)
- Low-stock alert — for best-selling SKUs, if remaining stock drops below 200 sq.m., alert so we can reorder.
- Dead-stock alert — any color/SKU with no movement for more than 4 months, alert.
SKU = "stock keeping unit" — the code for one specific product. For this client, one tile design in one colour and one size.
Why this case is perfect for teaching
Small enough to finish
Three rules. Two tables. One weekly job. You can hold the whole thing in your head — and finish it in two days.
Real enough to matter
Someone is doing this by hand right now, and money is quietly rotting on a shelf as dead stock.
Contains every classic decision
Where does data live? What runs the logic? How does a human find out? What makes it run without us?
Don't jump to solutions.
Every time you feel the urge to say "we should use X", force yourself to ask two questions first:
What problem does X actually solve?
Name the problem in a sentence with no technology words in it.
What else solves that same problem?
List at least two alternatives. If you can't, you don't understand the problem yet.
This is why every decision in this deck arrives as a table of options — and why the Against column of the option we chose is always real.
How to Think About Any App
The most important chapter of the entire course. Everything after this is detail.
Every app is four questions
Where does the data live?
Storage. The place facts are written down and can be found again tomorrow.
What turns data into answers?
Logic. The rules that convert raw facts into something worth knowing.
How do answers reach a human?
Interface or notification. An answer nobody sees is not an answer.
What makes it run without a human?
Automation. The trigger that fires whether or not anyone remembered.
Photograph this slide. We will come back to it four more times.
Our case, in four answers
Stock movement records
Currently: a Friday Excel file, updated by hand.
Three rules
One per client bullet point.
Someone must SEE it
Who? And where do they already look every day?
Every Friday
After the file is updated.
Requirements are always incomplete
Three bullet points from the client contain at least four hidden questions.
A good builder finds them before writing code — not because ambiguity is unprofessional, but because the client genuinely doesn't know yet either. You are not extracting an answer they're hiding. You are helping them decide.
"Best-selling SKU" — defined by whom?
Top 20% by volume
Objective. Needs a time window ("in the last 90 days"?) and re-computation. More code, more decisions.
A manual list the owner keeps
Subjective — but the owner already has this list in his head. Zero code. Wrong on the edges, right where it matters.
All SKUs, no distinction
Simplest of all — and produces alert spam for 300 slow-moving colours. Rejected.
is_bestseller, that a human ticks.
The simplest thing that could possibly work. Upgrade to computed (A) later if it hurts —
and the upgrade is a one-line change to how that column gets filled, not a rewrite.
"No movement for 4 months" — which movement?
No inbound AND no outbound
Literal reading of the word "movement". But a tile we restocked in March and never sold since would look healthy — the restock counts as movement.
That is exactly backwards. Buying more of something nobody wants is the worst case, not the safe one.
No outbound movement
Dead stock means it doesn't sell. Inbound is irrelevant — it's the money going in, not coming back.
Chosen. "Dead" = no type = out row for > 4 months.
The threshold, and the word "alert"
200 sqm — for every SKU?
Probably not forever. A fast-moving 60×60 grey burns through 200 sqm in three weeks. A specialty black slate might take a year.
What does "alert" mean?
Email? A LINE message? A red row in the sheet? A dashboard?
Ambiguity is normal. You resolve it with cheap reversible defaults, not by stalling.
A cheap reversible default is…
- quick to implement (a column, a constant)
- obviously wrong in a way you can see
- cheap to change when reality argues back
- never load-bearing for anything downstream
The failure mode it replaces
Four weeks of meetings to define "best-selling" precisely, while the owner still doesn't know which tiles are quietly dying on the shelf.
Stalling feels responsible. It isn't. A wrong default that ships teaches you the right one in a week.
The "walking skeleton" principle
Build the thinnest possible end-to-end version first — data in, logic, one alert out. Then thicken it.
A skeleton that walks is worth more than a perfect femur. It proves the pieces connect, which is the part that always surprises you.
Three weeks perfecting the data model
Beautiful schema. Supplier tables. Multi-warehouse support. Unit conversion. Nothing running. Nobody has seen a single alert.
Day one: an ugly thing that works
Then you thicken the bones that actually bear weight — and you know which ones those are, because you watched it walk.
What Claude Code changes — and what it doesn't
- Write the code
- Read the error message
- Fix the code
- Run it again
- Look things up it doesn't know
- Explain any line back to you in plain English
- Know your business rules
- Know your data's quirks (the negative stock row is coming)
- Know what "done" means
- Know that dead stock means outbound movement
- Notice when it is confidently wrong
Drafting a Simple Architecture
Four questions. Four decisions. Four options tables. One napkin.
What "architecture" means at our scale
It is not
A 40-page document. A diagram with sixty boxes. Kubernetes. A meeting with an Enterprise Architect who has never met your client.
It is
The four questions, answered with named components, drawn as boxes and arrows. It fits on a napkin. If it doesn't fit on a napkin, you don't understand it yet.
Architecture is just deciding which boxes exist and which arrows connect them — before anyone types anything.
The value isn't the drawing. It's that you can't draw a box you can't name, and you can't name a box until you know what it's for.
The whole app, before any technology
Four boxes. Four questions. Zero product names. Keep this picture — it barely changes for the rest of the course.
Storage
| Option | For | Against | Verdict for THIS case |
|---|---|---|---|
| Keep Excel files | Zero change for staff. It already works, today, for a human. | Files get emailed around, versions diverge, "final_v3_REAL.xlsx". Hard for code to reach reliably. | REJECTED…as the system of record. But it stays as the input format we must accept from staff. |
| Google Sheets | Free. Staff already understand it. Has an API. Shareable. One source of truth, in the cloud, always the latest version. | Not a real database. Slow at scale. Weak data integrity — nothing stops someone typing "abc" into a quantity cell. | ✅ CHOSENAt hundreds of SKUs and weekly updates, scale is a non-issue. The weak integrity is real — we handle it in code. |
| Real database Postgres / SQLite |
Correct. Fast. Professional. Actual constraints — a quantity column that refuses "abc". | Staff can't open it. Someone must build admin screens. Hosting, backups, credentials. Overkill for 30 rows a week. | REJECTED, FOR NOWRevisit when SKUs × years of history gets big, or when data integrity starts costing real money. |
API a door on a service that a program can knock on — with a code — instead of a human clicking buttons
"Best technology" is meaningless.
"Best for this team, this scale, this budget"
is the question.
A retail staff who live in spreadsheets. A database would be technically superior and practically abandoned by week two.
Hundreds of SKUs. Thirty movement rows a week. Every argument against Sheets is an argument about a scale we don't have.
$0/month, and the client's tolerance for maintenance is roughly zero hours per year.
Compute
| Option | For | Against | Verdict |
|---|---|---|---|
| Formulas inside Google Sheets | No code at all. The business could do it themselves. Genuinely fine for rule #2 alone. | The 4-month dead-stock rule across a movement log becomes an
unreadable nest of QUERY and ARRAYFORMULA. No alerts
without add-ons. One deleted cell breaks it silently. |
REJECTEDBut acknowledge: this is how the business would have solved it, and for rule #2 alone that's a legitimate answer. |
| Python script | Beginner-friendliest language. Best data libraries (pandas). Claude Code is excellent at it. Runs anywhere. You own it. | Needs somewhere to run on a schedule — which is a whole extra decision (see Decision 4). | ✅ CHOSEN |
| Node.js / JavaScript | Also fine. Same tier. Same hosting options. Claude Code equally good at it. | Data-wrangling story is slightly weaker for beginners. Dates are more painful. | REJECTEDA coin flip. Python wins on readability for non-programmers, and that is the only tiebreak that mattered. |
| No-code Zapier / Make |
Fast to demo. No environment setup. A real business could ship rule #2 this afternoon. | Monthly cost. Logic caps out quickly — the 4-month rule is painful. You don't own it. It teaches you nothing transferable. | REJECTED…for a learning project. Honest note: viable for a business that only wants rule #2. |
Decide fast on coin-flips. Think hard on one-way doors.
- Python or Node
- Which email library
- Tabs or spaces, folder names, file layout
- Whether the report is CSV or a printed table
Test: could you switch in an afternoon? Then stop debating.
- Do we store movements or snapshots? (Session 1 — the big one)
- What is the source of truth?
- Who owns the credentials?
- Does the client become dependent on a vendor we can't leave?
Test: would being wrong cost weeks, or data you can never recover? Then slow down.
Delivery
| Option | For | Against | Verdict |
|---|---|---|---|
| Universal. Free. Trivial to send from any language. Everyone has one. Archivable, searchable, forwardable. | People ignore email. An 18:05 Friday email is opened Monday at 10. | ✅ CHOSEN FOR v1Because it's the simplest thing that pushes. Simplicity beats perfect for the skeleton. | |
| LINE message | Where Thai businesses actually look, all day. It arrives in the group chat the team already argues in. | Requires LINE Messaging API setup — a second credential ceremony in a course that already has one. | CHOSEN FOR v2The case's real ending, and a Session 2 stretch goal. |
| Dashboard web page | Pretty. Demo-friendly. Impresses the boardroom. Genuinely useful for browsing history. | Nobody visits dashboards. It is a pull medium for a push problem. | REJECTED…for alerts. Perfectly fine as a bonus artifact once alerts exist. |
| Red rows in the Sheet | Zero new channels. Zero new credentials. Zero cost. | Someone must open the sheet to see it — the same pull problem, wearing a different hat. | KEPT — AS A BY-PRODUCTWe write an
alerts tab anyway, as the audit log. Free. |
Push vs pull
It arrives whether you asked or not
Email. LINE. SMS. A phone ringing. The information finds the human.
Cost: you're spending someone's attention, so you'd better be right. Alert fatigue is a real failure mode.
You must go and look
A dashboard. A report folder. A red row in a spreadsheet. A tab you bookmarked in January.
Cost: it depends entirely on a human remembering. On a Friday. At 18:05.
Build the dashboard second. Build it because it's nice, not because it's an alert.
Automation
| Option | For | Against | Verdict |
|---|---|---|---|
| A human runs the script on Friday | Zero setup. And honestly? Fine. A runnable script is the walking skeleton. | Defeats the word "automation". Humans forget, take holidays, and leave companies. | ✅ CHOSEN FOR v1 |
| Scheduler on someone's laptop cron / Task Scheduler |
Free. Easy. Ten minutes of setup. | The laptop must be on, awake, online, and still employed on Friday at 18:00. | ACCEPTABLE v1.5 |
| Cloud scheduler GitHub Actions cron |
Always runs. Free tier covers this a hundred times over. Forces the code into git, which we wanted anyway. | New concepts on day two: repository, YAML, secrets. And cron runs in UTC, which will bite us. | ✅ CHOSEN FOR v2Session 2. |
| Google Apps Script trigger | Lives inside Google. No server at all. No credential ceremony — it's already inside the sheet. | JavaScript only. Weaker tooling and testing. Harder to drive from VS Code + Claude Code. | RUNNER-UPThe strongest counter-proposal to our entire stack. It deserves the next slide. |
You could build this entire project inside Google Apps Script, and it would work.
Why it would genuinely be good
- No credential ceremony — the script lives inside the sheet
- No server, no hosting, no GitHub
- Time-based triggers built in
- Can send email in one line
Why we're not doing it
Because the goal of this course is a transferable stack: VS Code + Claude Code + Python. Those skills move to your next problem. Apps Script skills mostly stay inside Google.
The final architecture
Compare with v1. The boxes did not move. Only the labels changed.
Four decisions, one page
| Question | Chosen | In one line, why | What we gave up |
|---|---|---|---|
| 1 · Where does data live? | Google Sheets | The humans already live there, and the scale is trivial. | Real data integrity. We'll pay for this. |
| 2 · What runs the logic? | Python script | Readable by non-programmers; Claude Code is excellent at it; we own it. | It needs somewhere to run — that's Decision 4's problem. |
| 3 · How do answers reach a human? | Email → LINE | Alerts must push. Email is the simplest push; LINE is where the team already is. | Email gets ignored. That's why LINE is v2. |
| 4 · What makes it run? | Human → GitHub Actions cron | A runnable script first; then a free scheduler that never sleeps. | Repos, YAML, secrets — and cron speaks UTC. |
How Building With Claude Code
Actually Works
We have an architecture. Now: what does the building itself feel like?
What Claude Code is
A coding agent that lives in your terminal or inside VS Code. It reads your files, writes code, runs it, sees the errors, and fixes them.
You converse. It does.
terminal the text window where you type instructions to your computer instead of clicking. Now Claude sits inside it.
agent a program that can take actions on your behalf — not just answer, but open files, run commands, and try again
📄 CLAUDE.md
📄 rules.py
📄 movements.csv
✓ read movements.csv
✓ wrote rules.py
✓ ran python rules.py
✗ KeyError: 'last_out'
✓ fixed, re-ran
✓ 1 dead SKU found
DEAD STOCK (1)
TRC-30x30-TERR
last out: 154d ago
You've heard my description. Here is theirs.
I've just told you Claude Code reads files, writes code, runs it and fixes it. That is my summary of someone else's tool. Watch the people who build it describe what it is for, and see whether their framing matches mine.
- What does the human do, in every example they show?
- How often does the first attempt work?
- Where does the agent get its context from?
The workflow loop
Notice which boxes are highlighted. Describe and correct are yours. They are the same skill — saying precisely what you want — applied before and after.
Round two is not failure. It is the method. Expect three to five rounds on anything interesting, and stop apologising to the AI.
Accepting code you haven't run. If you didn't watch it work on real data, you don't know that it works. You know that it compiles.
What the loop looks like when it's a habit
The four-box loop on the previous slide is a diagram. This is the same loop performed by people who do it every day — which looks messier, faster, and much more conversational than any diagram can.
- How much of what they type is English, not code?
- What do they do when Claude gets it wrong?
- Does anyone apologise to the AI? (You'll want to. Don't.)
What CLAUDE.md is
A project memory file that Claude reads at the start of every session.
Your business rules, your conventions, your decisions live there — so you never re-explain them. It is the difference between an assistant who joined today and one who has been on the project for a month.
CLAUDE.md.
# Stock Alerts — project memory
## Business rules (decided, do not re-litigate)
- A "week" runs Saturday → Friday, matching
the client's Friday update habit.
- "Dead stock" = no OUTBOUND movement for
> 4 months AND the SKU is >= 4 months old.
- Low stock threshold is per-SKU,
default 200 sqm.
- Quantities are square metres (sqm).
## Data
- movements: date, sku, type(in|out), qty_sqm, note
- sku_master: sku, name, color,
is_bestseller, low_stock_threshold
## Conventions
- Never write credentials to the repo.
- Report bad data; never silently fix it.Good prompt vs bad prompt
✗ Bad
Claude will build something. It will be confident, plausible, and built on a dozen assumptions it made silently on your behalf.
✓ Good
Which sheet, which tab
The column names, spelled the way they're spelled
"A week runs Mon–Sun" — the ambiguity, killed in advance
"Don't write any files yet" — the scope, fenced
The human's three irreplaceable jobs
Decide what "correct" means
Nothing in the data says dead stock ignores inbound movement. That came from a human who understood why the alert exists.
Test against reality
Real, messy data. Not the clean examples. The SKU with negative stock is out there right now, waiting.
Notice when Claude is confidently wrong
The code runs. The output is formatted beautifully. The answer is nonsense. Only you know the business well enough to flinch.
AI writes the code.
You own the truth.
If you want the longer version
A conference talk from Anthropic's Claude Code lead. Too long for this room and exactly right for the train home. Everything in Chapter 0.4 is a compressed version of ideas like these.
- Which of the three human jobs does he keep circling back to?
- What does he say gets harder, not easier?
- What would he do differently from us on this project?
Close
What we'll build in Sessions 1 & 2
Make the logic real
- VS Code + Claude Code installed and obeying you
- The data model — movements vs snapshots, the one-way door
- Sample data with bugs planted on purpose
- All three rules working, on a laptop, printing to a screen
End state: the walking skeleton walks.
Make it reach a human, by itself
- Google Sheets connected — the API, and the credential ceremony
- MCP: chatting with your own spreadsheet
- Email alerts that a tired human can act on
- A Friday schedule that runs without you
- The retro: everything that went wrong
End state: you close the laptop and it still works.
Homework
- Install VS Code
code.visualstudio.com — the free editor we'll live in. - Install Node.js (LTS)
nodejs.org — Claude Code needs it. You will never write JavaScript. - Create a Claude account
claude.ai — then install Claude Code:npm install -g @anthropic-ai/claude-code - Bring a Google account
Any Gmail works. We'll make a spreadsheet with it in Session 2. - Bring the laptop you'll actually use
Not a borrowed one. Corporate laptops with locked-down installs are the #1 Session 1 delay.
npm. Finding out on the morning of Session 1
costs the whole room 30 minutes.No Python install needed in advance — we'll do it together. No prior programming. No GitHub account yet.
You now know the four questions.
You will
never look at an app request the same way again.
Where does the data live?
What turns data into answers?
How do answers reach a human?
What makes it run without a human?
And the one rule: don't jump to solutions.