Build, buy, automate or leave alone: a decision framework

Not every inefficient-looking task deserves a system. Some happen rarely, carry little consequence or are changing too quickly to standardise. Before comparing products, estimate the current cost, frequency, failure impact and attention required. Then compare that with the migration, training, governance and maintenance cost of change.

A decision to leave the workflow alone is not resistance to innovation. It protects attention for a constraint that matters more.

Keep the current approach when the task is low-frequency, low-risk and not a meaningful bottleneck; when the workflow is still being discovered; or when a manual decision is itself the valuable work. Document the reason and a signal that would justify revisiting it.

Choose an existing product when the problem is common, the process does not create strategic differentiation and the product can fit the organisation without forcing harmful workarounds. Evaluate total operating fit: permissions, export, integration, support, data treatment and the cost of exit—not only the feature list.

A mature product can be the fastest route to capability, especially when the vendor already carries specialised maintenance and compliance work the SME should not recreate.

Automation is appropriate when inputs, rules, outputs, ownership and exceptions are already understood. It is a poor substitute for a disputed process. Automating ambiguity creates faster inconsistency.

Begin with reversible, observable actions. Preserve approval for external communications, sensitive data, financial commitments and decisions that materially affect a person. Define how the system stops or hands control back when conditions are outside its intended range.

Custom product work becomes reasonable when the workflow is strategically distinctive, existing products cannot support the required operating model and the organisation has evidence that the result will be used. The build decision includes ownership after launch: monitoring, security, vendor dependencies, model change, user support and eventual replacement.

The first build should be the smallest coherent product that can test the critical assumption. A complete prototype of the wrong system creates less learning than a narrow product used in real work.

Use a simple written comparison rather than a feature contest. Score the current approach and each option on outcome impact, time to useful adoption, reversibility, data/risk exposure, ownership cost and strategic differentiation. Make assumptions visible and name the person accountable for the decision.