Not a philosophy — just what I've learned running four production systems mostly solo.
01 Plan in plain language first
Before I write a line of code or a prompt, I write out the plan the way I'd explain it to my business
partner — no jargon, no assumed architecture. If I can't describe what a system should do in plain
sentences, I'm not ready to build it. That plan becomes the spec I hand to the model, and it's the
first thing I check when something breaks: usually the bug is that the plan was wrong, not the code.
02 Delegate the research, save judgment for what matters
I run most of my systems through Claude Code, and I've learned to treat model choice like a budget.
Cheap, fast models do the research — scanning county websites, summarizing scraped pages, checking
whether a scraper's output looks right. I reserve the expensive, high-reasoning model for the calls
that actually require judgment: architecture decisions, data-quality tradeoffs, anything where a wrong
call is costly to unwind. That split is what let one person build and maintain 27 county-specific
engines without burning unlimited time or money.
03 JSON is the source of truth, generated files are disposable
Every pipeline I run keeps its real state in structured data — JSON, a spreadsheet, a database — never
in a one-off script's local variables. Scripts, dashboards, and reports get regenerated from that data
whenever they're stale; I never hand-edit an output file, because the next run would just overwrite it
anyway. That discipline is what makes it safe to delete and rebuild almost anything in these systems
without losing real information.
04 Build for the person who isn't technical
My business partner and the operators who use these tools day to day aren't developers, and they
shouldn't have to think like one. The call pipeline is written only in Python's standard library, on
purpose, so a routine dependency update can't break a tool a non-technical person depends on to do
their job. The lead dashboards are a map with taps and clicks, not a database console. If a tool needs
a manual to use, I consider that a bug.
05 Automate for the failure, not just the success
Anything that runs unattended will eventually fail unattended — a site changes its HTML, an API
rate-limits, a scheduled task silently doesn't fire. I design for that from the start: runs that are
safe to retry, logs that say what actually happened, and scheduled jobs that pick back up rather than
requiring a person to notice and restart them. That's the difference between a demo and a system three
people depend on every day.