Momentum
A production line that nobody attends. A row appears in a database and, several scheduled runs later, an episode exists: written, voiced by two synthetic hosts, given cover artwork, published to a podcast host, and folded into a static site that rebuilds itself from the same database. The interesting part is not any single step. It is what the thing does when a step fails at four in the morning.
A pipeline with seven stages, four external providers and no human watching has a specific failure profile. Nothing crashes loudly. Instead a quota runs out mid-run, a publishing API accepts the same upload twice, a long job outlives its own credentials, and one bad item at the head of a queue quietly blocks everything behind it for a week before anyone notices the output stopped.
So the architecture is shaped almost entirely around resumption. Every stage records that it happened, the next stage looks for that record rather than being told, and the unit of work is deliberately one item, in its own process, so that whatever goes wrong goes wrong to one episode and not to the batch.
> two languages ride the same machinery, and the final publish to the web is the one step deliberately left to a human.
Status flags in the database, not a queue
Each stage asks the store for an item whose previous stage is marked done and whose own is not, does the work, then sets its flag. There is no broker, no workflow engine, no lease to expire. A process killed halfway leaves nothing to reconcile, because it never claimed anything: the next scheduled run finds the same item still waiting and picks it up. The cost is paid in queries that scan more than they should and filter in code, which is a fair trade at this size and would not be at a thousand times it.
One item per run, in its own process
A scheduled run handles exactly one item and shells out to do it, which looks wasteful and is not. Each item gets fresh credentials, so a long job never dies of a token that expired while it was working. A failure is contained to one item, flagged, and skipped next time rather than sitting at the head of the line blocking everything behind it. Throughput is bounded by the schedule instead of the machine, deliberately: this is a pipeline where nobody notices a slow week and everybody notices a poisoned queue.
Running out of quota is a state, not an error
Third-party daily limits are not exceptional in an unattended pipeline, they are Tuesday. So hitting one is not an exception to be retried into a wall: the run recognises it, stops cleanly, and the next scheduled run resumes exactly where it left off because the state lives in the flags rather than in memory. The detection is deliberately crude, matching known phrases in the output, with a note in the code about the one lookalike failure that must not be mistaken for it.
A whole product line switched off for earning nothing
The long-form premium tier was built, worked, and consumed the most expensive part of the budget: speech synthesis. It made no money. Rather than keeping it running because it existed, generation of premium audio and its publishing were turned off at the configuration level, with the reason written next to the switch so nobody re-enables it hopefully in six months. The scripts are still produced, because text is cheap and useful elsewhere. Knowing which half of a feature to kill is the decision worth recording.
A second language by namespacing, not migrating
Hundreds of existing records used a field layout that predated the idea of a second language. Rewriting them all was the clean option and was not taken: instead the original layout keeps meaning the original language, and every other language gets its own suffixed namespace, resolved by two tiny helpers that return the old names for the old case. No migration, no risk to what already shipped, at the price of a schema with a permanent historical seam in it, and an honest limitation that the newer language cannot auto-select work and has to be pointed at it.
The site is an output, never a source
Every page is regenerated from the same records the pipeline writes, so the website cannot drift from what was actually produced. That rule has a sharp edge, since a regeneration that deletes stale pages is one filter away from deleting most of the site, so the cleanup only runs on a full pass and is disabled whenever the run is scoped to a single item. The deploy itself stays manual, which is the one place the pipeline stops short of automation on purpose.
Unattended pipelines are not judged on their happy path, which anyone can build. They are judged on what the state looks like after something died halfway, and whether the next run can tell. Small, resumable units of work, state in the store rather than the process, and failure isolated to one item: that is most of it, and it applies as much to a nightly ETL or a batch of documents as to this. If you have something that has to keep running while you sleep, let's talk.