Repair, Connect, or Build? A Better Way to Make Software Decisions

A business usually does not wake up wanting custom software. It wakes up with a handoff that failed again. Someone copied the same information into three places. A status changed in one system but not another. A spreadsheet became mission-critical without anyone deciding it should. A customer waited because the team could not tell who owned the next step.

That is the moment when technology conversations often go sideways. The discussion jumps straight to products: a new CRM, an AI assistant, a portal, a replacement platform. But choosing a tool before defining the failure is how a contained problem becomes an expensive transformation project.

I use a simpler decision: repair, connect, or build. There is also a fourth option that deserves more respect: leave the workflow alone for now.

Start with the failure, not the feature

Before choosing a lane, write down what actually happens when the workflow fails.

• What information is missing, late, duplicated, or wrong?
• Where is the current system of record?
• Which person discovers the problem, and how?
• How often does the exception happen?
• What does the failure cost in rework, delay, customer trust, or risk?
• Who will own the system after a fix ships?

This turns a vague request for “better automation” into a testable problem such as “approved customer records are sometimes created without the documents the next team needs.” That distinction matters. The first statement invites a shopping spree. The second invites diagnosis.

Repair when the intended system is basically right

Repair is the right choice when the existing tools fit the business and the breakdown is contained. The cause may be a failed integration, an expired credential, a field mapping that drifted, a brittle automation, a permission change, or an error path nobody can see.

A proper repair is more than making the happy path run once. It should answer: Why did this fail? Could records have been skipped or duplicated? How will someone know if it happens again? Can the fix be tested without putting live customer data at risk? What is the recovery procedure?

Repair is often the least glamorous option and the most valuable. It preserves the team’s existing habits, keeps replacement risk small, and gets the operation back to a known state.

Choose repair when:

• the current tools still fit the job;
• the failure has a traceable cause;
• data can be reconciled safely;
• the vendor platforms remain supported; and
• the repaired workflow can be monitored.

Do not call it a repair if the underlying process has outgrown the system. Patching the same structural gap every month is deferred replacement, not maintenance.

Connect when the tools work but the handoff does not

Connection work is useful when each system does its own job, but people have become the integration between them. The team downloads a file, renames it, copies values into another screen, sends a message, and later checks whether the next step occurred.

A good integration removes repetitive handling without hiding responsibility. It defines which system owns each field, what event starts the handoff, how identities are matched, which exceptions require review, and how retries avoid creating duplicates.

Choose connect when:

• the source and destination systems are both worth keeping;
• their APIs or export paths are dependable enough;
• the mapping rules are understandable;
• the same handoff happens often; and
• exceptions can be routed to a person.

The goal is not to automate every click. The goal is to make the state of the work clear. A small integration with visible failure handling is more useful than an elaborate chain nobody trusts.

Build when the missing workflow is part of how the business operates

Custom software makes sense when the business needs a durable capability that off-the-shelf tools cannot provide without constant workarounds. That may be a customer intake experience, an internal review queue, a specialized document workflow, a narrow operational dashboard, or a product the business intends to sell.

Build is the highest-commitment lane. It creates flexibility, but it also creates ownership: testing, security, deployment, support, backups, and future changes. The business should be able to explain why that responsibility is worth taking on.

Choose build when:

• the workflow is specific and important enough to justify ownership;
• existing products repeatedly force the wrong process;
• the required experience spans several systems or roles;
• the business can name a bounded first release; and
• someone will own decisions after launch.

Custom does not have to mean sprawling. The strongest first release is usually a focused system around one valuable workflow, with clear boundaries around everything it does not yet do.

Leave it manual when automation would create more risk than value

Some work is infrequent, ambiguous, or dependent on judgment. Automating it may cost more to build and monitor than it saves. A manual checklist can be the correct system while the process is still changing.

This is not a failure of ambition. It is a decision to avoid turning an unstable process into rigid software. Measure the workflow, improve the instructions, and revisit it when the pattern is clearer.

AI is an ingredient, not a fourth lane

AI may help inside a repair, connection, or build. It can classify an incoming message, summarize a record, extract fields from an inconsistent document, or produce a first draft. It should not decide the architecture merely because it is available.

Use deterministic rules for facts that can be checked exactly. Use AI where the input is genuinely variable and the output can be reviewed. Put important decisions, unusual cases, and high-consequence actions in front of a person.

A useful first engagement ends with a decision

For a stuck workflow, the most valuable initial output is often not code. It is a short system map that names the failure, the source of truth, the affected people, the likely repair path, the exceptions, and the evidence required to call the work complete.

That map should make one of four conclusions defensible:

1. repair the existing path;
2. connect the systems around a clear handoff;
3. build a bounded capability; or
4. keep the work manual and revisit it later.

The best technology decision is not the one with the newest tool. It is the smallest responsible change that makes the operation more dependable—and leaves the business able to understand what it now owns.