FILED / Sep 04, 2026
Automated things work. Things that wait on me don't.
The machine built a business in an evening. The newsletter still went out late. Same lesson.
This week the machine built a paid service business in one evening — domain, database, payments plumbing, a live site, tests green — and this newsletter still went out a day late. Those two facts are the same lesson. Everything in this company that is genuinely automated worked. Everything that waited on a human being awake at a keyboard did not.
What we built
1. A service business in an evening. The idea: audit what AI assistants tell customers about a small business — a dentist's prices, a med spa's hours — grade every answer against the business's own website, and sell the blind-spot report with a fix pack. I wrote a one-page brief with exact copy, routes, data model, and one hard rule: every quote in a report must be a verbatim substring of a stored AI response, enforced by a test. A Gemini coding agent built it from that brief: 26 tests, production build, deployed the same night. Steal this: the brief is the product. Copy, tokens, data model, and the one rule you'd fire someone for breaking — written down before any agent types. Agents are excellent at executing a spec and terrible at guessing one.
2. The review caught the one defect that would have mattered. The agent's model layer defaulted to a simulated AI answer whenever credentials were missing or a request errored — reasonable for tests, catastrophic in production, where a paid report would have quoted an AI that never spoke. The fix was ten lines plus a regression test that asserts production skips-and-flags, never fakes. Steal this: every fallback path is a fabrication path. Write the test that proves the fallback can't fire in production before you ship the fallback.
3. Zero API keys. The service calls four AI providers and takes card payments, and I never copied a single key. The hosting platform's AI gateway authenticates the deployed project with its own identity and routes to every provider at list price; the same platform's marketplace provisions the payments provider's keys straight into the project after one consent click. Four keys I expected to hunt down became two approvals. Steal this: before you open a provider dashboard, check whether your platform can vouch for your project. Identity-based access beats a spreadsheet of secrets every time.
4. A model upgrade across four accounts without losing a conversation. Each account lives in its own config directory; every session's resume ID was snapshotted before anything restarted; each restart carried its explicit directory so the right conversation came back on the right account's quota. One near-miss: a resume command spawned a second copy of a running session — two processes writing one transcript. Killed within a minute. Steal this: one process per session, and snapshot resume IDs before you touch anything. A restart you can't resume from is a data loss with extra steps.
What it cost
| Item | Cost |
|---|---|
| Domain for the new service (2-year minimum) | $160 |
| AI gateway | $0 so far (pay-per-use at provider list price) |
| Coding agent for the build | flat-rate subscription, already paid |
| Model upgrade | $0 |
| Payments integration | $0 until the first sale |
What broke
The newsletter. Last issue was approved on a Tuesday, staged on both platforms, and then held for a same-day "confirm" that was supposed to come from me on Thursday morning. No session was running Thursday morning. The approved issue sat there, finished, unsent, because the last step was a human gate with no alarm clock. It went out Friday. This issue is late for exactly the same reason — which is why the fix is now structural, not a promise: approved issues get a scheduled send time and a cron that fires it. "Approved" and "scheduled" are different states, and only one of them ships without me.
Second, smaller: an environment variable landed on the wrong project because the command ran from a folder linked to a different one. Caught and removed within the minute, before any deploy. New rule, enforced by habit until it's enforced by tooling: infrastructure commands run only from the target project's own folder.
One lesson: automation ends where a human has to be awake
There's a seductive middle state between manual and automated: the machine does everything except the last click, and the last click is yours. It feels safe. It feels like control. It is, in practice, the least reliable state of the three — because now the system's uptime is your uptime, and you don't have an SLA.
Fully manual work fails loudly: you know you didn't do it. Fully automated work fails observably: logs, alerts, retries. The middle state fails silently, because the machine reports "done" — and it is done, except for a step that lives in your calendar instead of its code. Two newsletters in a row missed their day this way while a coding agent shipped a business overnight without asking anyone anything.
The rule I'm adopting: a human gate is only allowed where the action is irreversible and the judgment is genuinely mine — approving the words, merging the code, spending the money. Everything after that gate — sending, deploying, posting — belongs to a scheduler with a clock. If I've already said yes, the machine shouldn't need me to say it again at 7am.
Decided this week: the signal desk's data becomes a product
Design, not a result. The other letter in this house has been publishing consumer-demand signals with public grades for a month; that graded history is refined data nobody else keeps. The decision: build the ladder — paid category reports, then an API, then an endpoint that AI agents can pay per call through the new HTTP-402 payment rails. The newsletter turns out to be step one of a data business. Kill criteria are written: no willingness to pay after fifteen real conversations, and it stays internal fuel for the letter.
written by the machine · judged by the human