The decision becomes clearer when it is broken into a few concrete questions.
Question 1: does this capability differentiate you?
Start by separating what makes your company different from what every company does.
- Commodity capabilities — accounting, payroll, email, standard CRM, document signing — work the same way everywhere. Buying is almost always right. There is no advantage in having your own payroll engine.
- Differentiating capabilities — the way you price, plan production, configure products, serve a specific customer segment — are where your know-how lives. Forcing them into a generic package can mean forcing your business to work like everyone else's.
Most companies need both: standard packages for the commodity, and targeted custom software where the business really is different — connected to each other through well-designed integrations.
Question 2: how well does the package fit?
When evaluating a product, measure the fit against your real processes, not a demo:
- Write down the ten or fifteen scenarios that matter most, with real data, and ask vendors to run them.
- Separate configuration (settings the product supports) from customisation (code changes to the product). Configuration is cheap to maintain; heavy customisation makes every upgrade a project.
- Ask what happens to your customisations at the next major release.
If the scenarios that matter most require significant customisation, the package is not a good fit, however long its feature list.
Question 3: what is the total cost over time?
Comparing a licence quote with a development estimate is misleading. Compare the total cost of ownership over a realistic period — five years, for example — on both sides:
| Cost item | Buy | Build |
|---|---|---|
| Upfront | Licences or subscription, implementation, configuration | Design and development |
| Recurring | Subscription, support contract, price increases | Hosting, maintenance, security updates |
| Change | Customisation, re-testing at every upgrade | Further development at your own pace |
| Integration | Connectors to your other systems | Same — always part of the cost |
| Internal effort | Training, process changes, administration | Product ownership, requirements, acceptance |
| Exit | Data export, migration, possible penalties | Usually lower, if you own code and data |
Neither column is automatically cheaper. The point is to see all the rows before deciding.
Question 4: who owns the data and the roadmap?
With a SaaS product, the vendor decides the roadmap, the pricing and, to some degree, where your data is processed. With custom software, you decide — and you carry the responsibility. Ask in particular:
- Can you export all your data in a usable format, at any time?
- Where is the data stored and processed, and under which jurisdiction — a question covered in our article on sovereign cloud?
- What happens if the vendor is acquired, changes its pricing or discontinues the product?
Question 5: can you maintain what you build?
Custom software is not a one-off purchase. It needs maintenance, security updates and evolution for as long as it is in use. Before deciding to build, make sure that:
- the code, documentation and infrastructure definitions belong to you;
- the technology is mainstream enough to find people who can work on it;
- there is a delivery pipeline with automated tests, so that changes stay cheap and safe over time;
- someone — an internal team or a partner with clear service levels — is responsible for running it.
The middle ground
The choice is rarely binary. Common hybrid approaches include:
- Buy the core, build the edges: a standard ERP, with custom applications for the processes that differentiate you, integrated through APIs.
- Low-code platforms for internal tools with simple logic, with clear limits on what goes there.
- Extend through the product's APIs rather than modifying the product itself, so that upgrades remain possible.
- Custom front-ends on standard back-ends, for example a mobile app for field staff on top of the ERP.
Where to start
List the capabilities you are considering, classify each as commodity or differentiating, and test the best candidate packages against your real scenarios. Where building is the right answer, our software engineering service delivers custom applications with the code, documentation and pipeline transferred to you — so that what we build is an asset you control, not a dependency on us.