First, do the arithmetic
Before debating anything, add it up. Open your active subscriptions, take the monthly cost of each, multiply by twelve and by the number of users wherever pricing is per seat.
Most companies have never seen that number in one place, because licences get approved one at a time and at different moments. Seeing it summed is, for many, the uncomfortable part of the exercise — and it is the honest starting point for this decision.
Next to each tool, also note what share of its features you actually use.
What is the cost that is not on the invoice?
It decides the comparison, and it appears on no accounting line:
- Processes bent around the tool instead of the reverse. Every extra step your team takes “because the system wants it that way” is cost.
- Data split across five places. The symptom is any business question that needs three tabs and a spreadsheet to answer.
- Fragile integrations. The connectors holding it together break with each update, and somebody fixes them.
- Team time on bridging work. Export here, paste there, check they match.
- The question nobody can answer because the data lives in three systems and none holds the complete version.
What changed?
Custom development stopped being a six-month project requiring significant capital. The cost of building fell far enough that the comparison is no longer “cheap versus enormously expensive” but an arithmetic problem you can actually work through.
That does not mean building is always better. It means you now have to think about it, where previously the answer was given.
When building IS the right call
- Processes that are your competitive differentiator. If how you operate is part of why customers pick you, a generic tool flattens it.
- Flows no product covers. When you have tried three and in all three ended up with a “notes” field doing the real work.
- A genuine need for centralised data. If the important questions span several systems, no single tool will answer them.
- Licence costs that scaled with headcount. Per-seat pricing grows linearly with the team; an owned system does not.
When it is NOT the right call
This is the section that keeps this article from being a brochure.
- Commodity and regulated functions. Accounting, payroll, e-invoicing, payments. Building them is only half the job — keeping them current with regulation is forever. Buy.
- When a SaaS solves 90%. That remaining 10% almost never justifies building and maintaining the whole 100%.
- When nobody can maintain it. An owned system with no internal owner and no support contract is a liability with an expiry date.
- When the process still changes weekly. If it has not settled, anything you build is out of date on arrival. Stabilise first.
The middle path, which is usually the right answer
It is rarely all-or-nothing. The configuration we recommend most often: keep SaaS where it is commodity and build custom only the layer where your differentiator lives, with data centralised in your own database consolidating what is currently split.
You keep buying accounting and payroll, the operation that distinguishes you runs on something you own, and business questions get answered against a single source.
What about maintenance and vendor lock-in?
This has to be answered directly, because it is the number one objection and dodging it is obvious.
An owned system needs maintenance: regulatory changes, new needs, updates. That is a real cost to budget from day one, not a surprise later.
On lock-in: the protection is not trust, it is four concrete conditions. Code in a repository you can reach. Data on infrastructure you control. Documentation that exists. A standard, non-proprietary stack another team could pick up. If all four hold, changing vendor is inconvenient but possible. If any fails, the dependency is real — and that is a valid reason not to proceed.
A five-question decision framework
Answer these and you will have your answer without anyone selling it to you:
- Is this process part of why customers choose you? If yes, that argues for building.
- How much do you pay per year in licences to handle it, across every tool?
- How many hours a week go to bridging work between systems? Multiply by hourly cost and by 52.
- Is there anyone — internal or contracted — who can maintain what gets built? If no, the decision is already made: buy.
- Has the process been stable for at least six months? If it changes constantly, not yet.
If the answers are yes, a high number, a high number, yes and yes, building probably makes sense. If either question 4 or 5 comes back no, it does not matter how the others went.