"And what if we end up dependent on it?" — I hear this question almost every time custom software comes up. It's a fair concern. But it's aimed at the wrong risk.
The real risk isn't the software — it's a lack of process understanding
The worry sounds logical at first: if you build a tailored solution, you become dependent on whoever built it. With standard software, the thinking goes, you're freer.
That's rarely true. The real risk isn't the software itself — it's a partner who never truly understood your process. And here's an honest look at what that means in practice: more than 70 percent of SMEs have not fully documented their end-to-end processes. The knowledge lives in the heads of experienced colleagues, not in manuals.
That's the dependency that really matters: the dependency on individuals. And it's why off-the-shelf software fails at the critical points. A standard product assumes a cleanly defined, ideally structured workflow. Your business, however, runs on processes that have grown organically — processes that do exactly what makes you successful — and that are written down nowhere. Anyone who doesn't understand those real processes builds a solution that looks good on paper and stumbles in practice. The problem then isn't the technology, it's the failure to listen.
Standard software locks you in too — just without the proximity
The comparison "custom = dependent, standard = free" doesn't hold up in practice. Standard software locks you in as well: to licensing models, to prescribed update cycles, to a vendor who raises prices and discontinues features without asking you.
Experts call this vendor lock-in and explicitly count it among the strategic risks for SMEs — with three concrete consequences: cost increases that are hard to control, limited ability to innovate, and a structural dependency that blocks strategic decisions. Unlike large corporations, SMEs rarely have the resources to absorb a costly migration on the fly. When a vendor announces end-of-support for a version, there's effectively no choice but to follow the prescribed — and expensive — upgrade path.
The difference, then, isn't dependency yes or no. The difference is proximity. With standard software, you're one number among thousands with no negotiating power. With a custom solution, someone who knows your process sits across from you and stays reachable.
Software is a product, not a project
The most common misconception is treating software as a one-off project: build it once, done. The numbers say otherwise. Over the lifecycle, industry benchmarks consistently show that 60 to 80 percent of total software costs arise not during development, but in everything that follows — operations, support, maintenance, and ongoing development.
That turns the key question around. It's not "Who builds it cheapest?" but "Who keeps it running well for years?" The feared "frozen" system that nobody touches any more arises precisely where ongoing care is absent — not where something was built custom.
Good custom software is therefore a managed product: maintained, evolved, adapted to new requirements. The ongoing partnership isn't a liability — it's the actual value. As a decision-maker, you can pin this to two simple metrics: How quickly is a change request implemented? And how plannable is further development? Where both are solid, you don't incur standstill costs from software nobody maintains any more.
How to recognise a reliable partner
If the risk isn't the software but the partner, then what to look for in a selection shifts accordingly. Less about team size — more about understanding.
And yes: I'm writing this as someone who builds custom software — I don't want to hide that interest. That's exactly why I'll say it plainly: not every process needs its own software. Where standard fits, standard is the better choice — and a good partner will tell you that too.
A reliable partner asks the right questions about your process before talking technology. They'll occasionally advise against a feature rather than nodding at every request. They make it transparent how they measure success. And they stay reachable after go-live — with short response times instead of a ticket system, a fixed point of contact instead of rotating project numbers.
Size doesn't decide it — proximity does. Anyone who understands your process and stays reachable makes custom software the safer choice, not the risky one.
What that looks like in practice: at a spare-parts wholesaler with around 60 employees, procurement planning ran through an established system — but nobody trusted it any more. Purchasing had long been working with their own spreadsheets alongside it, because nobody could see how the order suggestions were generated. The software wasn't the problem — the lack of transparency was. Once every suggestion showed its reasoning, trust returned — and over- and under-stocking fell by 82 percent. The full story is in our reference Order Optimisation with Transparent Forecasting; further projects we continue to support are in our References.
The next two parts of this series get more specific: what a lean, effective process solution looks like — and how to recognise which of your processes actually deserve custom software and which are better bought off the shelf.