"Custom is expensive" is one of those statements that is true often enough to go unexamined. For a five-person business that needs invoicing, it is completely true — buy the product. But the comparison that actually matters is not licence cost against build cost. It is total cost of the current arrangement against total cost of the alternative, and the current arrangement usually has costs nobody has written down.
The three costs that get left out
When organisations compare a subscription against a build, they compare the invoice against the quote. Three substantial costs sit outside that comparison.
1. The reconciliation labour
If two systems hold overlapping data, somebody is keeping them aligned. That person rarely has "data reconciliation" in their job title, so the cost never appears as a line item. It appears as headcount. Before comparing anything, measure it: how many hours per week are spent moving information between systems, and at what loaded cost?
2. Per-seat scaling
Subscription pricing scales with headcount. Your process complexity generally does not. An operations platform at R450 per user per month is R27,000 a year at five users and R270,000 a year at fifty. The work the software does has not changed. If you are growing, model the licence cost at your projected headcount rather than your current one — that is the number the build has to beat.
3. The workaround tax
Every off-the-shelf product forces some accommodation, and each accommodation has a cost. A spreadsheet that exists because the system cannot express a rule. A status field used for something it was not designed for, which everyone must be told about. These are individually minor and collectively significant, and they compound as staff turn over and the reasons are forgotten.
Where the line actually falls
In our experience the arithmetic tips toward custom when several of these are true at once:
- Annual licence spend across overlapping tools is into six figures
- One or more full-time equivalents are consumed by moving data between systems
- The process being supported is genuinely a differentiator, not a commodity
- Headcount is growing faster than process complexity
- A rule central to how you operate cannot be expressed in the current tools
One of these on its own is rarely enough. Three or more, and the build usually pays back inside two to three years — which is roughly the horizon over which a subscription decision should be judged anyway.
When you should not build
Equally worth stating plainly. Do not build when your process is standard and the product does it well — accounting, payroll and email are solved problems and you will not beat them. Do not build to avoid changing a process that is inefficient in the first place; encoding a bad process in software makes it permanent. And do not build if nobody internally can own the system after launch, because software without an owner decays regardless of who wrote it.
The honest middle path
The answer is frequently neither replacement nor status quo. It is integration: keep the accounting package, keep the CRM, and build the connective layer that makes them share a single customer record. That is a materially smaller project than a platform rebuild, and it removes the reconciliation labour, which is usually where most of the hidden cost was.
Before quoting anyone a build, we ask them to measure the hours currently spent moving data between systems. Sometimes that number makes the case on its own. Sometimes it shows the problem is not worth solving with software yet — and that is a useful answer too.