Automation is attractive because it promises to remove friction permanently. Build it once; it runs forever. But the promise obscures a straightforward calculation that most automation projects skip: the break-even point. If the automation costs more to build and maintain than the manual process would have cost to run for the next year, the automation is overhead. It is not progress. It is a system that costs money to keep alive while solving a problem that was cheaper unsolved.
The ninety-day rule is a filter, not a formula. It asks: does this automation pay for itself within ninety days of going live? If the answer is no, the priority is probably wrong. If the answer is yes, it is worth building.
What the rule is not
The ninety-day rule is not a hard deadline. It does not mean that automation projects that take longer to recoup their cost are worthless. It means they are lower priority. Capital allocation for automation should follow the same logic as capital allocation for any investment: start with the highest-returning options and work down. Projects that pay in thirty days come before projects that pay in ninety. Projects that pay in ninety come before projects that pay in a year.
The rule is also not a cap on complexity. A complex automation that pays in sixty days is better than a simple one that pays in two years. The recoup timeline is a single metric: (build cost + ongoing maintenance cost per period) versus (cost of the manual process per period). The math is straightforward even when the engineering is not.
Automation that does not pay in ninety days is not bad automation. It is automation that should be a lower priority.
How do you run the calculation?
Before building any automation, run four numbers.
First: the manual process cost. How many hours per week does the process consume? Multiply by the loaded hourly cost of the person running it (salary, benefits, overhead, management time). This is the cost you are eliminating. Be precise about frequency: a process that runs once a quarter costs far less than it appears to on a weekly basis.
Second: the build cost. How many hours will it take to design, build, test, and deploy the automation? Multiply by the cost of the person or firm doing the work. Include scope discovery in this estimate. Most automation projects are underestimated at the design stage because the edge cases are invisible until someone maps the full workflow.
Third: the ongoing maintenance cost. Automations are not free to run. They break when upstream APIs change. They require updates when the underlying process changes. They need monitoring so that failures are caught before they compound. A realistic maintenance estimate is five to fifteen percent of the build cost per month, depending on how many external dependencies the automation has. Ongoing monitoring and upkeep of this kind is exactly what an operations retainer is built to cover.
Fourth: the break-even point. Divide the build cost by (monthly manual process cost minus monthly maintenance cost). The result is the number of months until the automation pays for itself. If that number is less than three, build it. If it is between three and twelve, build it when higher-priority automations are done. If it is more than twelve, reconsider whether the process should be automated at all.
The four numbers, and what each one is:
| Number | What it measures | How to find it |
|---|---|---|
| Manual process cost | The cost you are eliminating each period | Hours the process consumes, times the loaded hourly cost of the person running it, adjusted for true frequency |
| Build cost | The one-time cost to make the automation | Hours to design, build, test, and deploy, times the cost of the person or firm, including scope discovery |
| Maintenance cost | The ongoing cost to keep it running | Roughly five to fifteen percent of the build cost per month, depending on how many external dependencies it has |
| Break-even point | Months until it pays for itself | Build cost divided by (monthly manual cost minus monthly maintenance cost) |
What does the rule catch?
The ninety-day rule consistently surfaces two categories of automation projects that should not be built yet.
The first is automation of infrequent processes. A process that runs once per quarter and takes two hours costs around 100 USD per quarter in manual effort. An automation for this process is rarely worth the build investment unless the process is going to run much more frequently in the future, or unless the two hours consistently falls at the worst possible moment.
The second is automation of unstable processes. If the underlying workflow changes every few months because the business is still figuring out how it works, automating it now means rebuilding the automation every few months. The right answer is to stabilise the process first, then automate it. Automating an unstable process does not make it stable. It makes the instability harder to change.
What should not be automated at all?
The rule implies a lower bound: some manual processes are cheap enough that automating them is not worth the overhead. A process that costs 200 USD per year in manual effort and 2,000 USD to automate has a ten-year payback period. Unless the business scales dramatically, this process should stay manual.
There is no shame in a manual process. Most well-run businesses have dozens of them. The goal of automation is not to eliminate human involvement; it is to eliminate human involvement in work that does not benefit from it. The judgment call at the boundary of that distinction is the highest-value thing an experienced operator can offer. The ninety-day rule is one tool for making that call systematically rather than on instinct. The same arithmetic scales up. Deciding whether to build a content production engine instead of buying the output by the asset is the ninety-day rule applied to a larger number.
