Keep, Improve, Connect, Replace, Build

The wrong first question

When a business system isn't working, the instinctive first question is almost always "what should we replace it with." That question assumes an answer before the diagnosis has happened, and it's usually the most expensive of the five real options available. Technology should serve the business problem, not dictate the solution. Before any platform, vendor, or rebuild gets discussed, there's a simpler, five-word framework worth running the situation through: keep, improve, connect, replace, build.

The five honest options

Keep

What already works. This is the option most often skipped, because "keep it as it is" doesn't feel like doing anything. But if a manufacturing floor's production tracking is fundamentally sound and the real problem is that nobody downstream can see it in real time, the fix is visibility, not a new tracking system. Keeping what works and addressing the actual gap is usually cheaper and faster than replacing something that was never the problem.

Improve

What's underperforming. Sometimes the tool is right and the way it's used is wrong. A finance team's month-end close might depend on the right software, used inconsistently: no standard process for data entry, no shared definition of "done." Improving how an existing system is used and governed often outperforms switching platforms, at a fraction of the cost and disruption.

Connect

Systems that should talk to each other but don't. A sales team's lead source and a support team's ticket history frequently live in tools that were never designed to share data, so the two get reconciled by hand or not at all. Connecting them, through integration rather than replacement, can resolve more day-to-day friction than swapping out either system.

Replace

What's fundamentally unsuitable. Sometimes a system genuinely doesn't fit anymore: it was built for an operation a third of the current size, or a way of working the business no longer follows. Replace is a legitimate answer, just not the default one, and it shouldn't be reached for before keep, improve, and connect have been genuinely ruled out.

Build

What's missing entirely. Occasionally there's no system at all for a function that now needs one: a business that has scaled past the point where a founder's personal judgment alone could route every inbound lead, for instance. Build is the right call when the gap is real and nothing existing can reasonably be adapted to close it.

Why the order matters

The framework is written in this order deliberately, and the order is the point. Keep, improve, and connect are almost always faster, cheaper, and lower-risk than replace or build, and a large share of "underperforming system" problems turn out to live in one of the first three categories once someone actually looks. Reaching for replace or build first isn't wrong because those options are bad. It's wrong because it skips past three cheaper, faster answers that haven't been ruled out yet.

The right answer is rarely "replace everything." It's usually cheaper, faster, and closer than that.

This is also, not coincidentally, the opposite of how most vendors are incentivized to answer the question. A platform vendor's default recommendation is close to "buy our platform." A framework that starts with keep and improve is a genuinely different lens: one built around what the business actually needs, not what's being sold.

Applying it without a full diagnosis

This framework is useful even before any formal engagement. For a single underperforming process, it can be run honestly in a short conversation:

• Is the underlying system sound, and the problem is visibility or adoption? Keep, and fix the real gap.
• Is the tool right but poorly used or configured? Improve how it's run.
• Do two systems hold pieces of the same truth without talking to each other? Connect them.
• Has the business genuinely outgrown what's in place? Replace it.
• Is there simply nothing there yet? Build it.

Most systems land in more than one category depending on which part of the process you're looking at, which is exactly why a single technology purchase rarely fixes an operating problem on its own. The value of the framework isn't picking one word. It's forcing the question to be asked honestly, for each part of the system, before money moves.