The simple rule still holds. Buy the work that does not make your business different. Build the work that does. Most arguments about SaaS and custom software come down to one issue: where that boundary sits.
Buy the systems many companies need in the same way
Some business problems are shared by thousands of companies. A vendor whose whole business is solving one of those problems will usually solve it better than you would with your own engineering budget.
These are the common examples:
- Payroll.
- Email.
- Accounting.
- Helpdesk.
- Storage.
Building any of these means spending engineering time on something that will never distinguish you from a competitor. For that kind of work, buying usually wins.
Build the workflow your business actually runs on
Custom software makes sense when the software is close to how your business operates. If the process is specific to you, forcing a general product to imitate it can become more expensive than building the thing that already does it.
The usual examples are the rules and paths that shape daily work:
- Pricing rules.
- Approval chain.
- Operational process.
We have seen two years of configuration produce something the team still worked around. That is the danger of treating a distinctive workflow as if it were a standard one.
The visible price is only part of the cost
Vendor pricing is the number everyone can see. The number that often decides the outcome is integration: getting the bought system to exchange data with everything else you run, then keeping that connection working as both ends change.
That cost is routinely underestimated by a factor large enough to reverse the decision. A product that looked cheaper can stop looking cheaper once the data has to move correctly between systems.
A vendor roadmap can become a business dependency
One practical test is to ask what happens when the vendor says no. If a capability you need is on their roadmap for next year and your business depends on it this quarter, you have found a dependency rather than a supplier.
That dependency can be acceptable when you choose it deliberately. It should be a decision you make with your eyes open, rather than a surprise you discover later.
Most organisations need both, with the boundary made explicit
Most organisations buy the commodity layer, meaning the shared systems every business needs, and build the differentiator on top. The two have to be connected properly.
The common failure is choosing without ever making the boundary explicit. Then the business discovers the real boundary during an incident, when the cost of the choice is already showing up.
