Outgrowing Off-the-Shelf software: A Build-vs-Buy guide
When standard software stops fitting: four signs a Swiss mid-market company has outgrown it, and how to decide what to build, configure or keep buying.
Nobody outgrows their software on a particular day. It happens gradually, and the first evidence is never a system failure — it is a spreadsheet.
Someone exports data every Monday because the reporting module cannot produce the view the business needs. Someone else maintains a parallel list because a required field does not exist. A third person re-keys orders between two systems that were supposed to be integrated.
None of that shows up as a problem with the software. It shows up as headcount.
The fit gap, and why it widens
Standard software is built for the average of its market. That is what makes it cheap. The further your process sits from that average, the more of the gap you cover yourself — with configuration first, then with workarounds, then with people.
The gap does not stay constant. It widens, for two reasons that compound:
- Your business changes. New products, new regulatory requirements, an acquisition. Each moves you further from the average the product was designed around.
- The product changes too. Vendors optimise for their largest segment. If you are not in it, each release moves the average away from you.
So the question is not “does this product fit today?” but “is the gap growing or shrinking?”
Four signs you have outgrown it
1. Process specificity — the workarounds became the process
There is a difference between a workaround and a procedure. A workaround is temporary and someone remembers why it exists. A procedure is documented, trained and inherited.
When the export-to-Excel step appears in an onboarding document, the workaround has become the process. At that point the standard system is no longer running the workflow; it is storing data for a workflow that happens elsewhere.
Test: could a new joiner do the job using only the software and its documentation? If the honest answer needs a “yes, but”, you have a specificity problem.
2. Integration surface — the middleware has its own roadmap
Most mid-market companies run five to fifteen business systems. Connecting them is normal. The warning sign is when the connective tissue becomes a system in its own right — with its own failures, its own on-call rota and its own backlog.
Test: when something breaks between two systems, is it obvious who owns the fix? If the answer is “it depends”, your integration layer is now an undocumented product that nobody maintains deliberately.
3. Configuration depth vs logic forking
Configuration means using the options the product provides. Logic forking means bending the product into behaviour it was not designed for — custom scripts in vendor hooks, fields repurposed to mean something else, plugins that patch core behaviour.
Forked logic is the expensive kind, because it breaks on upgrade. Teams then delay upgrades, which delays security patches, which turns a product decision into a risk decision.
Test: how long has it been since you took a major version upgrade, and was the delay caused by your customisations?
4. Regulatory and data-residency fit
This is where Swiss companies diverge from the generic advice, and where a global SaaS product often stops being a neutral choice.
Under revDSG/nDSG, and GDPR where EU data is involved, you have to know where data is stored and who can reach it. Those are different questions, and the second one is the one that gets missed. A vendor hosting in a Swiss or EU region still needs an answer on support access from outside it, on its own sub-processors, and on what happens to your data when the contract ends.
For FINMA-supervised businesses there is a further requirement: a documented, demonstrable exit path. “We would migrate” is not one.
If a product cannot answer these, the fit gap is not about features. It is about whether you can use the product at all in a regulated context.
What this does not mean
It does not mean build everything. The most expensive outcome in this whole discussion is a company that rebuilds a commodity — accounting, payroll, email, CRM basics — because one report was missing.
A more useful frame is to split your systems in two:
- Where you differ from competitors — the process that is genuinely yours. Here a standard product will always fit badly, because fitting well would mean being average.
- Everywhere else — buy it, configure it lightly, and stop thinking about it.
Most mid-market companies have one or two areas in the first group. If your list has eight, the list is wrong.
A decision that survives a board meeting
Four questions, answered honestly, decide it:
- Is this process a differentiator or a necessity? Necessities get bought.
- Is the gap widening or narrowing? A narrowing gap is a configuration project, not a build.
- What does the workaround cost per year — in hours, errors and delayed decisions? Convert it. An unpriced workaround always looks free.
- Can the vendor meet the regulatory requirement at all? If not, the other three questions are irrelevant.
Only if the process is a differentiator, the gap is widening, the workaround cost is material and compliance is reachable does building win.
The middle option people forget
Build-vs-buy is a false binary. A third option covers most real cases: keep the standard system as the system of record, and build only the layer where you differ — a workflow application, an integration service, a decision tool — that reads from and writes to it.
You keep the vendor’s upgrades, support and commodity features. You own only the part that is actually yours. It is smaller, cheaper and easier to reverse than a replacement.
This is the shape of most of our custom software engagements: not a rebuild, a well-drawn boundary. Where the boundary is an old system that cannot expose its data cleanly, application modernization comes first.
If you are somewhere in this decision and want a second opinion on where the boundary should sit, book a call. No obligation.