Put a real constraint on the page
An imperfect process can be worth keeping. The difficulty is distinguishing a tolerable inconvenience from a recurring cost that is quietly growing.
A useful decision note starts with the work the process creates today. How often does somebody intervene? How long does it take? What fails when that person is unavailable? The answers establish whether there is a problem worth solving before a team starts comparing products or designing an internal replacement.
Revised September 13, 2026. The worked example is hypothetical; the figures are not client results.
Compare three complete options
Consider a small team manually reconciling a weekly usage export with customer invoices. It takes two hours a week. At an illustrative loaded labour cost of €70 per hour, that is €7,280 a year, assuming 52 runs. This accounts for staff time only; any expected error cost would need a separate estimate.
Suppose a vendor charges €200 a month, requires 16 hours to integrate, and leaves half an hour of reconciliation work each week. Its first-year cost is approximately €5,340: €2,400 in fees, €1,120 in integration and €1,820 in residual labour.
A custom tool taking 80 hours to build and two hours a month to maintain would cost €7,280 in its first year before hosting, support and any residual reconciliation work. Calling it “free once built” hides most of the comparison.
| Option | First-year cost in this example | What could change the decision |
|---|---|---|
| Tolerate the current process | €7,280 in labour | More accounts, higher error exposure, absent operator |
| Buy the proposed service | €5,340 before unpriced costs | Integration gaps, contract terms, required controls |
| Build the proposed tool | €7,280 before unpriced costs | Reuse across products, better fit, underestimated maintenance |
These inputs make buying worth investigating. They do not prove it is the right decision. A trial might reveal that the vendor cannot represent a crucial invoice rule, or that the residual work is much larger than expected.
Give custom work a specific reason to exist
Custom engineering is strongest when the requirement is both consequential and poorly served by the available options. That can mean a distinctive product capability, a hard operating constraint or a repeated workflow where control creates value.
“Core to the business” is not enough on its own. Authentication and payments can be essential while established services remain the appropriate choice. The question is which responsibility the team needs to own and whether it can maintain that responsibility well.
The same distinction applies to internal tools. A deployment pipeline may deserve investment because it is used every day and affects release safety. A rarely used reporting screen may be adequately served by a small query and a documented procedure.
Tolerate with a review trigger
A tolerated process needs an owner and a boundary. In the example, the team might keep the manual reconciliation until it consumes four hours a week, produces a defined class of error or blocks a new customer requirement.
The trigger makes the decision observable. Without one, temporary arrangements can become permanent through neglect. With one, the team can deliberately spend its limited engineering time elsewhere and still know when to revisit the choice.
Google's SRE discussion of toil is useful here because it distinguishes recurring operational work from improvements that reduce future work. It provides a lens for the cost; it does not tell every team to automate every manual task.
Keep the decision note short
A reviewable note needs five things: the present workload, complete options, estimated costs, the main uncertainty and the revisit condition. Include a reversible next step where possible, such as a limited vendor trial or a small internal experiment.
The recommendation should explain why the chosen option fits the current constraints. If the workload doubles or the vendor fails the trial, a different choice should be easy to justify from the same note.
That is what makes the exercise useful over time. The team retains the reasoning behind the decision instead of inheriting an unexplained preference for building, buying or postponing work.