A licence pays off when your process is standard and a market tool covers it without forcing it. Custom software pays off when the process is your own, when no tool fits without workarounds or when licence costs grow with every user. The decision is not ideological: it is made by comparing total cost over several years and how well each option fits the process.
What custom software is
Custom software is an application designed and built for a specific process in a specific organisation, rather than bending the process to fit a generic tool. It can be a complete system or a component that connects and completes the systems already in place.
When an off-the-shelf licence makes sense
A market tool is usually the best option when these conditions hold:
- The process is standard and does not differentiate you from competitors, such as accounting or payroll.
- The tool covers most of what you need without additional development.
- The number of users is moderate and stable.
- You need to go live quickly and the vendor has comparable deployments.
In these cases, building your own means reinventing what someone else already maintains.
When custom software makes sense
Custom software pays off in other circumstances:
- The process is distinctive. It is part of how your organisation competes, and you do not want to limit it to what a tool allows.
- Nothing fits without workarounds. Available tools force parallel spreadsheets or manual steps to cover the gaps.
- Cost grows with every user. Per-user licences multiply as more people need access.
- You need full control. Over data, infrastructure, security or the pace of change.
How the two options compare
| Off-the-shelf licence | Custom software | |
|---|---|---|
| Upfront cost | Low to moderate | Higher |
| Recurring cost | Per-user or per-volume licences | Maintenance and infrastructure |
| Fit with the process | The process adapts to the tool | The tool adapts to the process |
| Ownership | The vendor’s | Yours, if the contract says so |
| Vendor dependency | High: pricing, roadmap and continuity | Low, with documented code |
| Time to go live | Fast | Delivered in stages |
Neither column wins every row. That is why the decision depends on which rows matter most to you.
How to compare five-year total cost of ownership
The most common mistake is comparing the first-year price. The useful comparison is total cost over five years, with every item included.
Example with round, illustrative figures for 200 users:
- Licence: €60 per user per month comes to €144,000 a year. With €50,000 of implementation, the five-year total is €770,000.
- Custom software: €180,000 to build, €30,000 a year for maintenance and €6,000 a year for infrastructure. The five-year total is €360,000.
With 20 users, however, the licence would cost €72,000 over five years plus implementation, and would clearly be the cheaper option. User numbers, volume and expected lifespan change the answer. Run the numbers with your own figures.
The middle path: integrate rather than replace
In many organisations the best answer is not choosing between buying and building. It is keeping what works and building only what is missing.
The ERP stays the ERP. The CRM stays the CRM. What gets built is the work people currently do by hand: the integration between systems, the missing portal, the automation that stops data being copied from one screen to another. That is the approach of our custom software service, often combined with process automation.
What the contract for custom software should make clear
Custom software reduces dependency when the contract makes five points clear:
- The source code: who owns it and where it is kept.
- The data: which formats it is stored in and how you can export it at any time.
- Technical and functional documentation, enough for another team to maintain it.
- Hosting: on your infrastructure or the provider’s, according to your technology and security policy.
- Licences: which third-party or provider licences the system needs to run.
If any of these is left vague, your dependency on the provider will be greater than it looks.
The risks of custom software and how to avoid them
- Depending on whoever built it. Avoided with documented code and clear ownership terms from the start.
- Nobody evolving it. Avoided by agreeing from the start who supports the system after go-live and how it adapts when the business changes.
- Scope that never ends. Avoided with detailed specifications before development and partial deliveries that already work.
- A system only one person understands. Avoided with automated tests and documentation as part of every delivery.
How to decide in practice: four questions
If you need to make the call this week, answer these four questions in writing:
- Does this process set us apart? If not, start by looking for a market tool.
- What share of the process does the best available tool cover? If many steps fall outside it, count the yearly cost of covering them by hand.
- How many users will there be in three years? Per-user licences behave very differently with 20 users than with 500.
- What would happen if the vendor raised prices or stopped maintaining the tool? If the answer worries you, ownership has a value that never appears on the invoice.
How custom software goes live
Custom software should not be handed over all at once at the end. It is built in deliveries: each one solves part of the process, is tested on real cases and goes into use before the next begins.
That way the organisation gets value early, the team validates each piece in its daily work and the risk of a system that does not fit disappears. The content of each delivery is defined in the specifications, before development starts.
Where to start
List the tools you use in the process today, what they cost each year and the steps still done by hand. With that list, the decision often becomes clear on its own. If you would like a second opinion, request a first conversation and we will tell you what we would buy, what we would integrate and what we would build.