Calculate the ROI before you write the automation

I have watched skilled engineers spend three weeks automating a process that ran four times a year and took two hours each time. The automation worked perfectly. It will never pay for itself.

Before any code, we make students produce a one-page model: how often does this run, how long does it take, what is the fully loaded cost of the person doing it, what is the error rate today, and what does an error cost. Five numbers. It takes twenty minutes and it kills about a third of proposed projects, which is the point.

The second thing the model surfaces is where the value actually sits. Frequently the time savings are modest but the error reduction is enormous — invoice coding, eligibility checks, and compliance review all look like this. If you optimise for minutes saved you will build the wrong thing.

Then there is the maintenance line that almost nobody includes. An automation touching three external APIs will break. Budget two to four hours a month against it. If the ROI only works when maintenance is zero, the ROI does not work.

Students present this model to a real stakeholder before the studio phase begins. Defending five numbers to someone who owns the budget is a different skill from writing the pipeline, and it is the one that turns a capable builder into someone a company will hire or retain.