When custom software makes more sense than another SaaS tool

The build-versus-buy conversation is usually held at the wrong altitude. It becomes a debate about principles - speed versus control, cost versus flexibility - when it should be a fairly dry assessment of where cost and constraint actually sit in a specific process.

The honest starting position is that buying wins most of the time. What follows is about the cases where it does not, and how to tell the difference before committing.

When buying is obviously right

Three conditions make purchase the clear answer, and when all three hold there is no serious argument for building.

The process is standard. Accounting, payroll, email, expense management, helpdesk ticketing, document storage. These work the same way across thousands of companies, and any difference in how you do them is almost certainly accidental rather than advantageous.

The product is mature. Someone has already encountered the edge cases you have not thought of yet, and they are handled. The value in mature software is mostly the accumulated handling of situations nobody anticipated.

The process is not a differentiator. If no customer will ever choose you because of how you run it, owning it is a liability rather than an asset.

A useful test: if you were explaining to your board why you were building this yourself, would the explanation be embarrassing? If so, buy.

When workflow uniqueness genuinely matters

Every company believes its processes are special. Most are not. The distinction worth drawing is between processes that are different and processes that are different for a reason that produces value.

A distributor that allocates constrained stock across customers using a policy reflecting contractual commitments, relationship history and margin is doing something specific, and that specificity is commercially meaningful. A manufacturer scheduling production around particular machine constraints and changeover costs is doing something a generic planning tool will approximate badly.

Conversely, an approval workflow with four steps instead of three because of a decision made in 2014 is not a differentiator. It is a habit, and the right response is usually to change the habit rather than to build software to preserve it.

The question to ask the business owner is direct: if we adopted the standard product's way of doing this, what would we lose? If the answer is a specific commercial consequence, it is worth building around. If it is discomfort, it is not.

Integration gaps: the most underestimated case

The strongest case for building is often not a workflow at all. It is the space between systems.

A company might run a perfectly good ERP, a perfectly good CRM, a perfectly good warehouse system and a perfectly good e-commerce platform, and still have a serious software problem - because the process that matters crosses all four, and no vendor sells the connection between that particular combination.

This case is underestimated because each individual system is fine. Nobody is unhappy with any single tool. The cost is distributed across people who export, re-key, check and chase, and it appears on no software budget line.

Integration work is also where buying is least likely to help. Integration platforms move data; they do not encode the business logic about what should happen when the systems disagree - and that logic is usually the actual requirement.

The manual work generic systems create

The most reliable signal that a product-process gap has become expensive is the spreadsheet that sits next to the system.

Someone exports data every Monday. Someone maintains a list the system cannot hold. Someone checks one system against another before a decision. Someone chases a colleague because a status is not visible anywhere. None of this appears in a process document, and all of it is load-bearing.

This work is worth quantifying properly, because it is the basis of any credible business case. Count the hours per week, at loaded cost, across everyone doing it. Then consider how that scales: does it grow linearly with volume? Most reconciliation work does, which means it is a fixed tax on growth.

Add the cost of the errors. Manual re-keying has an error rate, and those errors have consequences - a wrong price, a missed delivery, a credit note, a lost customer. These are harder to quantify and usually larger than the labour cost.

Then add the cost of delay. If a decision waits two days for a manual process, what does that lateness cost across a year?

The operational cost of owning software

An honest comparison includes what building actually commits you to. Custom software has to be hosted, monitored, patched, occasionally fixed at an inconvenient hour, and changed as the business changes. Somebody must own it after the people who built it have moved on.

This is the strongest argument against building, and it is the one most often waved away during the enthusiasm of a business case. It is also the reason the scope question matters so much: a small, focused system is a modest ongoing obligation, while a large one is effectively a permanent internal product team.

The ownership question should be answered before the build decision, not after: who maintains this in two years, and does that person exist today?

Focused layers, not replacements

The framing that resolves most of these cases is that custom software need not replace anything.

The most effective systems we build are usually thin: they sit on top of existing platforms, hold the logic and the workflow the business actually needs, and leave each system of record doing what it does well. The ERP remains the ERP. The CRM remains the CRM. What gets built is the part that did not exist.

This keeps the build small, keeps the ongoing obligation proportionate, and avoids the largest category of enterprise software failure - the multi-year replacement programme that delivers, at enormous expense, roughly what the business already had.

It also means the decision is reversible in a way a platform migration is not. A focused layer can be replaced later if a vendor eventually ships the capability. A core system replacement cannot be undone.

Questions worth asking before deciding

• What exactly does the standard product not do, stated as a process step rather than a feature name?
• How many hours per week are spent compensating for that gap, and does that number grow with volume?
• If we adopted the product's way of working, what specific commercial consequence would follow?
• Is the requirement really a workflow, or is it an integration between systems we already own?
• What is the smallest version of this that would remove most of the manual work?
• Who owns and maintains it in two years, and do they work here today?
• If a vendor shipped this capability in eighteen months, would we regret having built it - and how much would we have saved in the meantime?

Related reading

• Custom Enterprise Software - how we scope and build these systems
• Connecting marketing data to actual sales