Build, Buy, or Configure: A Cost Analysis of Custom Software vs SaaS

The build-versus-buy decision is usually argued on philosophy and settled on arithmetic. This guide gives you the arithmetic: a five-year model comparing custom software, off-the-shelf SaaS, and configured platforms, plus the four situations where building is clearly the wrong answer regardless of what the spreadsheet says.

We build custom systems for a living, which makes our bias obvious. So we have written the cases against building first, and we mean them, a discovery session that ends with "keep your current subscription and fix two integrations" is a good outcome for everyone.

Options

The three options, honestly described

Buy (off-the-shelf SaaS). Fast, low upfront cost, professionally maintained, and your process must bend to fit the product. Cost scales with seats or transactions, and you rent rather than own, pricing, features, and terms can change without your consent.

Configure (a platform plus customisation). A mid-point: a mature platform extended with your workflows. Moderate upfront cost, faster than a build, but you inherit both the platform's constraints and its upgrade cycle, and heavy customisation is the classic way to end up unable to upgrade at all.

Build (custom software). Highest upfront cost, exact process fit, no per-seat pricing, and you own the asset. You also own the responsibility: maintenance, security, and the consequences of every decision the SaaS vendor would otherwise have made for you.

Model

A five-year cost model

The example below is a 25-user operations system for a mid-sized company. Adjust the numbers to your own case, the shape of the result is what matters.

Two things skew this model, and you should test both. It assumes seat growth, which favours the build, flat headcount pushes the crossover years later. And it assumes the custom system is genuinely maintained; underfund that line and the comparison becomes dishonest, because you are comparing a maintained product against a decaying one.

Threshold

Where the crossover actually falls

Three variables move the crossover point more than anything else.

1. Seat count. Per-seat pricing is linear; a build is close to fixed. At 10 users, SaaS wins comfortably. At 25, it is close. At 100, the build usually wins by a wide margin in year three.
2. Number of tools replaced. Companies rarely replace one subscription. They replace four, plus the spreadsheet holding them together. Count all of them, plus the staff hours currently spent moving data between them.
3. Process fit. If off-the-shelf software requires two manual workarounds per transaction, price those workarounds in staff time. This is the single most under-counted number in the entire comparison, and it is frequently larger than the licence fees.

Restraint

Four cases where you should not build

• The process is standard. Payroll, accounting, email marketing, help desk, HR records. These are solved problems with mature products and regulatory maintenance burdens you do not want to own. Building your own payroll system is a decision you will regret annually.
• Fewer than about fifteen users on a stable process. The arithmetic rarely closes, and the maintenance obligation lands on a team too small to carry it.
• You cannot fund year two. A build with no maintenance budget becomes a liability within eighteen months, as dependencies age and security patches go unapplied.
• The requirement is still changing weekly. If nobody can describe the process consistently, buy something cheap, run it for six months, and let reality write the specification for you.

Justification

Five cases where building pays

• The process is your differentiator. If how you operate is why customers choose you, generic software will erode exactly that advantage.
• You are paying for overlap. Four subscriptions with four partial views of the same customer, reconciled by a person. That person's time is the real licence fee.
• Per-seat cost is taxing growth. When adding staff means a licensing conversation, the software has started making your hiring decisions.
• You need a specific integration nobody supports. Local payment rails, regional logistics providers, government filing systems, legacy hardware. This is where off-the-shelf products stop and custom work is the only path.
• Data ownership is strategic or regulated. When residency, auditability, or exit rights are contractual obligations, renting is a compliance risk.

Pragmatism

The hybrid most companies should choose

The best answer is usually not one of the three. Keep off-the-shelf products for solved problems, accounting, payroll, email, support tickets, and build custom software only for the part of your operation that is genuinely yours. Then connect them properly.

This keeps the build small, which keeps it affordable, maintainable, and replaceable. A $12,000 custom module that orchestrates four commodity subscriptions delivers most of the benefit of a $60,000 platform at a fifth of the risk. When we scope a custom business system, this is the shape we recommend more often than any other.

Sustainability

Budgeting for the years after launch

Custom software is not a purchase; it is a commitment with a running cost. Plan for four lines every year:

• Dependency and security updates, the frameworks and libraries underneath your system release patches continuously, and skipping them compounds.
• Hosting and monitoring, modest for most business systems, but never zero.
• Small enhancements, the changes your team asks for once they actually use it, which is when the most valuable requirements finally surface.
• Support, a defined response commitment for when something breaks at a bad moment.

Fifteen to twenty percent of build cost per year covers all four comfortably. A vendor that does not raise this before you sign is either inexperienced or hoping you will not ask.

$100 for a one-hour session, billed at $25 per 15 minutes with a one-hour minimum. You choose your time on Calendly immediately after checkout. Pay by card or M-Pesa.

FAQ

Frequently asked questions

Is custom software cheaper than SaaS in the long run?

Sometimes. Custom software has a high upfront cost and a low, predictable running cost. SaaS has a low upfront cost that scales with headcount or transaction volume. The crossover typically arrives between years three and five, and arrives sooner the more seats you add. Below roughly fifteen users on a standard process, SaaS almost always wins.

When should a business build custom software instead of buying it?

Build when the process is genuinely your competitive advantage, when no product fits without changing how you operate, when you are paying for several overlapping tools that do not talk to each other, or when per-seat licensing has made growth expensive. Buy in every other case.

What does custom business software actually cost to maintain?

Budget 15 to 20 percent of the original build cost annually. That covers dependency and security updates, hosting, monitoring, small enhancements, and support. Software with no maintenance budget does not stay static. It degrades, because the platforms underneath it keep moving.

What is the biggest risk in building custom software?

Building the wrong thing well. The second biggest is key-person dependency, a system only one developer understands. Both are mitigated the same way: a short paid discovery phase before commitment, and a contractual requirement for documentation and owned code from the first commit.