Tools & Technology Decisions · Decision Framework

Keep, connect, replace, automate or build: how to choose

A practical way to make the system decision before the software decision.

Last reviewed: July 17, 2026

3 min · Read

Summary

Start by checking whether a frustrating work process is useful and stable. Then decide whether the missing value comes from configuration, connection, replacement, automation or purpose-built software.

Start with the work process

Write the current path from trigger to completion. Name who owns each decision, what information enters, where it is stored, which exceptions occur and what proof marks the work complete.

This keeps a product demo from defining the problem for you.

Use five distinct decisions

Keep when the tool performs its core function, the team can use it and the data is accessible. Connect when two useful tools create a problem at the handoff. Define the reference information before synchronizing fields.

Replace when the product blocks the operating model, creates unacceptable risk or costs more to keep than to transition. Automate when the input, rule, owner and exception path are stable. Build when available products impose excessive compromise on a specific operating need.

Test the decision against reality

Compare implementation effort, migration risk, ongoing ownership, data portability, permissions, vendor dependency and the cost of doing nothing.

A smaller connection can be the right first phase even when a custom system remains the long-term target.

Practical checklist

Can we describe the work process from trigger to completion?
Is the current tool’s core job useful?
Is the reference information clear?
Are exceptions documented?
Is the decision reversible?
Who owns the system after launch?
What evidence will show the change works?

See how this decision applies to your business.

The diagnosis connects the framework to your real process, data and constraints.

Check my operations