Build It, Buy It, or Leave It Alone

Technology decisions are usually framed as a choice between building something bespoke and buying something off the shelf. Framed that way, the answer is always to acquire software, and the only question is which kind.

There is a third option that belongs in every one of these conversations: change nothing, or change the process instead. It is frequently the correct answer, and it is systematically underweighted because nobody's role involves advocating for it.

Leave it alone

Consider this option seriously when:

The process is genuinely working. Slightly awkward is not broken. If people know what to do and the outcome is reliable, the return on replacing it may be close to zero once you account for the disruption.

The problem is organisational. Unclear ownership, disagreement about priorities, an unresolved dispute between two teams. Software does not resolve any of these, and implementing it usually surfaces them under time pressure.

The volume does not justify it. Twenty transactions a month rarely justifies a system. A well-organised manual process is cheaper and more flexible.

It is temporary. A situation that resolves in a year does not need a permanent solution.

Nobody will own it. Any system needs someone responsible for it after launch. Without a name, the honest projection is abandonment.

The last three initiatives are still bedding in. Organisations have a limited capacity to absorb change. Adding to a queue that is not clearing makes everything in it worse.

Buy

Buying is the default for good reasons, and it is right when:

• The problem is common. Accounting, payroll, CRM, email, scheduling, helpdesk. Thousands of businesses have this problem; someone has built a good answer.
• Your version is not meaningfully different. If you find yourself explaining why your invoicing is unusual, examine whether it needs to be.
• The cost of being wrong is low. A subscription can be cancelled. A build cannot be un-built.
• You need it soon. Weeks rather than months.
• You lack the capability to maintain software, and are not planning to acquire it.

The main risks of buying are fit and dependency. Fit problems appear as workarounds accumulating around the tool. Dependency problems appear as price rises, discontinued features, or an acquisition that changes the product. Both are manageable if you know your exit path — which requires confirming that your data comes out before you commit.

Build

Building is justified in a narrower set of circumstances than it is chosen in:

• The process is genuinely specific to you and is part of how you compete. Not "we do it slightly differently", but a real difference customers notice.
• You have evaluated the market properly and the gap is fundamental rather than cosmetic.
• The integration requirement is the actual product. Sometimes the value is entirely in connecting three systems you already run, which nobody else can sell you.
• You can maintain it. Not just build it. Ongoing ownership, monitoring, dependency updates, and a plan for the person who wrote it leaving.
• The volume or duration justifies the total cost, including maintenance over several years.

The most common mistake is building because an off-the-shelf tool was ninety per cent right and the remaining ten per cent felt intolerable. That ten per cent is often a process preference rather than a requirement, and the cost of the custom build will be many times the cost of adapting.

The second most common is underestimating maintenance. A build is not an expense; it is a subscription you pay in attention, indefinitely.

A workable sequence

1. Write the problem as a sentence describing the business outcome, not the solution. "Enquiries wait too long for a first response", not "we need a CRM".
2. Quantify it. Frequency, time, cost, or lost revenue. If you cannot, the case for spending anything is weak.
3. Argue for leaving it alone. Deliberately, in writing.
4. Consider a process change with no technology. Reassign an owner, remove a step, change a rule. Surprisingly often this is the whole answer.
5. Check what you already own. Existing systems frequently have the capability unused. This is the single most overlooked option.
6. Evaluate buying, against your written problem rather than a feature list.
7. Only then consider building, with maintenance costed over three years.

Steps three to five are the ones usually skipped, and they are where most of the savings are.

The hybrid worth knowing about

Many good answers are a bought system with a small amount built around it — a connection between two tools, an automated step, a small internal interface for one workflow. This gets the maintained core of a commercial product with the specific behaviour the business actually needed.

The failure mode to avoid is the opposite: a large custom build with a small commercial component inside it. That combination carries the maintenance burden of a build and the dependency risk of a purchase.

The most useful thing a technology adviser can say is often that you should not spend the money. It is also the least likely thing to be said by anyone whose income depends on the project going ahead — which is worth remembering when choosing who to ask.