Payback and the cost of ownership

A scenario is not a one-off purchase

Automation is usually counted as savings: it used to take twenty minutes a day, now it takes zero, so we gained eighty hours a year. That arithmetic is wrong. Every running scenario is a commitment to maintain it for as long as it lives. The form changes — you fix it. A service updates its interface — you fix it. A new colleague joins — you explain it. That is the cost of ownership, and almost nobody budgets for it.

An honest formula

yearly_saving = times_per_week * 50 * minutes_per_run
yearly_cost   = build + debugging + 1-3 hours of upkeep per quarter
decision: automate if yearly_saving > yearly_cost * 3

The factor of three is not superstition. The first build always takes twice as long as it looks, and breakages arrive at the least convenient moment. If the margin is thinner than threefold, the scenario will consume more attention than it returns.

Thresholds worth anchoring on

• Less than once a week: almost never. You will forget how it works and re-learn it every single time.
• Five times a week or more: usually yes. Even a two-minute operation adds up to eight hours a year.
• Several times a day: yes, even when the operation looks trivial. Here the win is not only time but the fact that people stop forgetting.
• A one-off migration: do it by hand or with a throwaway script. Building a scenario for a single run is a pure loss.

There is a separate line item: attention. A scenario that quietly broke and spent three weeks not sending client emails costs more than any saving it ever produced. So the cost of ownership includes a regular check — someone looks once a week to confirm that everything actually ran.

Cheat sheet

• Savings must beat the yearly cost at least threefold.
• Less than once a week stays manual.
• Debugging costs no less than the build.
• Checking that it is alive is a cost too.