When an organisation needs new software, the choice usually comes down to three routes: buy something ready-made, build something custom, or staff up to build it in-house. The decision is often made on gut feeling or on whatever feels safest in the moment. That is a shame, because each route carries hidden costs that only surface well into the journey – when turning back is expensive.
Here is the framework we use when advising customers on exactly this.
When off-the-shelf is the right choice
Standard software wins when your need is the same as everyone else’s. Accounting, payroll, email, CRM in its basic form – these are solved problems, and someone delivers them better and more cheaply than you ever could build yourself. Building your own here is almost always the wrong use of time and money.
But off-the-shelf has hidden costs too. You adapt your processes to the software, not the other way around. You pay licences for the foreseeable future. Integrations with the rest of your system landscape are often heavier than the salesperson implies, and you are at the mercy of the vendor’s roadmap and priorities. The honest test is simple: is this need a source of competitive advantage for us, or is it just something we have to have in place? If it is the latter, buy it.
When you should build custom
Custom is the right call when the software is how you create value – when the process is your own, the requirements are specific, or no off-the-shelf product fits without contorting the business to use it. Then a bespoke solution gives you something ready-made never can: something shaped around your exact workflow, owned outright, and developed further in step with your own needs.
The hidden cost of building is not the development itself. It is everything around it: architecture that can grow, testing, operations, security and, not least, further development in the years that follow. Software is not a project with an end date – it is something that lives and demands maintenance for as long as it is in use. Many underestimate this and end up with a solution that was cheap to build and expensive to own.
Hire or use a delivery partner
Suppose you have decided to build. Then comes the next choice: do you hire people to do it, or use a partner who delivers it for you?
Hiring makes sense when the need is lasting and large enough to keep a team meaningfully occupied over time, and when the expertise is something you want in-house as a core capability. But the hidden costs are significant. Recruiting senior development talent takes months and is far from guaranteed to succeed. One or two hires do not give you a complete team – you typically lack architecture, testing, operations and leadership. And you are left with a fixed cost and the responsibility of keeping people sharp and engaged, including once the project is done.
A delivery partner makes sense when you want the result without building the organisation around it first – when you need a complete, experienced team quickly, with ownership of the whole journey from architecture to operations. Our own stance here is clear: instead of hiring, we deliver it for you. You get one senior, accountable partner who owns the whole, and you own the result – all source code and all rights are yours. It is not the right answer for every need, but for most time-bound deliveries, or when an internal team needs reinforcing with senior capacity, it is both faster and safer than building the team from scratch yourself.
Choose with your eyes open
There is no single right answer across situations. Off-the-shelf, custom and staffing up are all correct – each in its own context. What goes wrong is when the choice is made implicitly, without weighing the hidden costs or asking the fundamental question: is this a source of competitive advantage, or something we simply have to have?
Make that assessment deliberately and early, and the rest of the decision becomes much easier. That is the conversation worth spending time on – before the first line of code is written or the first licence is signed.