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

Buying is the correct default

For accounting, payroll, email, helpdesk, storage and most horizontal functions, a mature product is cheaper than anything you can build, is maintained by someone else, and improves without your effort. Building these is almost always a mistake dressed as a preference.

So the question is not whether to build in general. It is whether this specific process is one of the exceptions.

Four conditions that justify building

1. It is how you compete. If the process is a genuine differentiator, buying it means operating the same way as everyone who bought the same product.
2. No product fits without distortion. Where every candidate requires changing how the business works in ways that cost real money or lose real advantage, the licence fee is not the whole price.
3. Integration cost exceeds build cost. Six products with five integrations between them, each needing maintenance, is often more expensive and more fragile than one system that covers the same ground.
4. The data is the asset. Where the accumulated data is the long-term value, ownership and structure of that data matters more than the convenience of the interface around it.

The costs on each side that get missed

Missed on the buy side

• Per-seat pricing that scales with headcount rather than with value
• Integration and data-sync work, and its ongoing maintenance
• Process distortion — the cost of working the way the product assumes
• Switching cost, which grows every year and is rarely modelled
• Feature roadmap controlled by someone whose priorities are not yours

Missed on the build side

• Maintenance, which continues for the life of the system
• The security, access control, audit and backup work a product includes silently
• Key-person risk if only one or two people understand it
• Opportunity cost of engineering capacity spent here rather than elsewhere

The middle path is usually right

The most common good answer is neither pure option: buy the commodity layers, build the differentiated one, and invest properly in the integration between them. That means treating integration as engineering with contracts, versioning, monitoring and error handling — not as a spreadsheet export.

A useful test: if the process were described to a competitor, would they recognise it as ordinary or as yours? Ordinary processes should be bought. Yours should be built.