CH.02Approach00:00:14:00
Four shots. One system.
Every system I build is cut the same way: listen, frame, build, operate. The storyboard is fixed; the footage is always the customer’s.
Shot 01 — Listen00:00:00:00 01 / 04Week 0–1Listen.
I sit with the people doing the work: support calls, spreadsheets, the WhatsApp threads nobody documented. The real problem is rarely the one in the brief.
- Problem statement in their words
- The metric that proves it worked
Shot 02 — Frame00:00:04:00 02 / 04Week 1–2Frame.
One page, one diagram, one decision at a time. I pick the smallest architecture that survives real load and write down what we are choosing not to build.
- System sketch and data flow
- Cost and failure budget
Shot 03 — Build00:00:08:00 03 / 04Week 2–6Build.
Full stack, shipped in thin vertical slices behind preview environments. Agents get evals before they get users; every deploy is boring on purpose.
- Working slices in production
- Evals, CI/CD, observability
Shot 04 — Operate00:00:12:00 04 / 04OngoingOperate.
I stay on the pager through rollout, training and the first bad week. The job is done when the system is unremarkable to the people who rely on it.
- Runbooks and alerts
- A team that owns it without me
Operating principles
04 rules
Stay close to the operation
The workflow shapes the system, not the other way round. I learn how the business actually runs before I open an editor.
Choose the smallest reliable architecture
Boring tech, few moving parts, and only the complexity the problem has earned. Everything else is a maintenance bill.
Own the last mile
Deployment, adoption, cost and on-call are product work. Launch day is the middle of the job, not the end.
Let production tell the truth
Real usage, evals and traces decide what gets built next. A demo is a hypothesis; production is the answer.