One Runbook for Twenty Apps: Amortized Ops

I do not have twenty ways to restart a service, restore a backup, or debug a failed deploy. I have one, and it works for every product, because every product runs on the same foundation. That is the operational payoff people miss when they talk about shared foundations. It is not just that code gets reused. It is that operations gets reused. One runbook, one set of procedures, one mental model, amortized across the entire portfolio. Without it, running twenty products alone would be impossible.

How does one person run operations for twenty products?

By making the products operationally identical. The reason a solo operator drowns is not the number of products. It is the number of distinct operational patterns. If every product deploys differently, logs differently, backs up differently, and fails differently, you are carrying twenty separate operational burdens and no human can hold that.

Standardize the operations and the number of products almost stops mattering. When every product deploys through the same pipeline, the deploy runbook is one page and it covers all twenty. When every product logs to the same place in the same format, debugging is one skill, not twenty. When every product's database lives on one shared Postgres box, the backup and restore procedure is written once. This is the operational side of why one operator can beat a team here: I am not superhuman, I just refuse to maintain twenty different ways to do the same operational task.

What amortized ops actually looks like

Amortized operations means every recurring operational task is solved once at the foundation level and inherited by every product. The concrete pieces:

• One deploy procedure. Every product ships the same way through one owned pipeline. The rollback steps are identical everywhere.
• One logging and monitoring setup. Every product reports to the same place, so I watch the whole portfolio from one view instead of twenty dashboards.
• One backup and restore runbook. Because the data layer is shared, the disaster-recovery steps are written once and drilled once.
• One incident pattern. When something breaks, the diagnosis path is the same regardless of which product broke, because the plumbing under all of them is the same.

The effort to write these is fixed. It does not grow with the number of products. That is the definition of amortization: a one-time operational cost spread across every product, so the per-product ops burden falls as the portfolio grows. It is the same curve as the marginal cost of the next product falling, applied to operations instead of development.

The trap: letting products diverge operationally

The thing that destroys amortized ops is operational drift. One product deploys a little differently because it was in a hurry. Another logs somewhere else because someone was experimenting. Each small divergence is harmless alone. Together they rebuild the twenty-separate-systems problem you were avoiding, and now your one runbook has twenty exceptions and is useless.

So operational uniformity has to be enforced, not hoped for. New products inherit the standard ops setup by default, and diverging from it requires a real reason, not convenience. This is the paved road applied to operations: the standard operational path is the easy default, and stepping off it is allowed but rare and deliberate. A product that runs ops its own way for no reason is a product quietly stealing time from every other one, because it fractures the single runbook that keeps the whole thing manageable.

Own the stack so the runbook is yours

Amortized ops works best when you control the operational layer end to end. If half your products run on one managed platform and half on another, each with its own console, alerts, and quirks, you cannot have one runbook because the vendors imposed two. Operational uniformity requires owning the operations.

I run the whole portfolio on infrastructure I control, which means the deploy, logging, backup, and monitoring procedures are mine to standardize, not a patchwork of vendor dashboards. My build platform scaffolds new products already wired to the shared operational setup, so Bootspring makes the standard ops path the default a product starts on, and drift never gets a foothold. The result is that adding the twenty-first product adds almost nothing to my operational load, because the runbook already covers it. That is how one person runs a portfolio: not by working twenty times as hard, but by refusing to operate twenty different systems.