Bespoke software or platform? When made to measure costs less over time
Sometimes the right answer is a product off the shelf, and we say so. Sometimes the licence that looked cheap becomes one of the largest lines in the budget. How to tell the difference.
- By
- Andrea Belloni, CEO
- Published
6 min read
In short
- For standard processes — email, payroll, general accounting — a platform is usually the right choice.
- The total cost of a platform includes licences that grow with the company, customisation limits, integration, process fit and the cost of leaving.
- Bespoke software costs more to build and has to be run and evolved; in exchange it fits, integrates and stays under the company's control.
- A hybrid — platforms for commodity functions, bespoke software where the company is different — is often the right answer.
- It costs more; it lasts longer. But only when the process deserves it.
Every enterprise system starts with the same question: buy or build? The honest answer is not always the one that suits us. A company that builds custom software for a living should be the first to say when it isn't needed. What follows is the reasoning we go through with clients before any code is written.
When a platform is the right answer
Buy when the process is the same for everyone. Email, office tools, payroll, general accounting, standard HR: these are solved problems. A mature platform brings years of refinement, regulatory updates and a support organisation that no bespoke project can match at the same cost. It also brings something bespoke software cannot: other customers who run into its problems first.
Buy also when speed matters more than fit; when the process is still changing and nobody knows its final shape; or when nobody, inside or outside the company, is committed to maintaining a bespoke system.
If your process fits a product with light configuration, use the product. We say this in first meetings, and it is not modesty: software that doesn't need to exist is the cheapest software to maintain.
The real cost of a platform
Platforms are priced to look simple. Their total cost of ownership over five or ten years is less simple, and several of its components do not appear in the first quote.
Licences that grow with the company
A licence per user is cheap at thirty users and a different conversation at three hundred. Growth, new sites and occasional users all increase the bill, and price changes are decided by the vendor, not by you.
Customisation limits
Every platform has a point beyond which it cannot be changed, or can be changed only through specialist partners and extensions that break at the next upgrade. When the process reaches that point, the company adapts to the software.
Integration cost
A platform has to talk to the ERP, the warehouse, the transport system. Standard connectors cover the common cases; the rest is integration work, paid separately, and sometimes paid again when the platform's interfaces change.
Process fit
The least visible cost is the work around the software: the spreadsheet that fills a gap, the manual step between two screens, the export someone reworks every Monday. Multiply it by people and by years, and it is often the largest item of all.
Lock-in and exit
Leaving a platform means extracting data in a usable form, rebuilding integrations and retraining people. The cost of leaving is part of the cost of entering, even if it is paid later. Ask what it would be before you sign. Contract terms matter as much as technology: notice periods, data export formats, and what happens to your data when the contract ends.
The real cost of bespoke software
Bespoke software has its own costs, and they deserve to be stated just as plainly.
- Build. Design and development are paid up front, before the first person uses the system.
- Run. Hosting, monitoring, security updates and support, every year.
- Evolution. The business changes, and the software has to follow. A system that is not evolved slowly becomes the next legacy system.
- Dependence on the builder. Unless the system is documented and built on mainstream technologies, the company swaps a vendor lock-in for a supplier lock-in.
The last point is the one to check most carefully. Ask for architecture decision records, a changelog for every release, and technologies that any competent team can maintain. We work on .NET, Angular, SQL Server and Azure precisely because they are not exotic.
None of these costs is a reason to avoid bespoke software. They are a reason to plan for them from the start, and to be wary of any quote that leaves them out.
How to compare the numbers
A fair comparison puts both options on the same horizon, usually the expected life of the system, and counts everything, not only what appears on a quote.
- Platform: licences multiplied by the users you expect each year, not today; implementation and configuration; partner fees for customisation; integration, built and then maintained; the work around the software; and the cost of leaving at the end.
- Bespoke: design and development; hosting and monitoring; maintenance and security updates; a yearly budget for evolution; documentation and handover, in case the team changes.
The work around the software is the item most often left out, because nobody invoices it. Estimate it honestly: the hours spent each week on spreadsheets, re-keying and checks, multiplied by the people who do them and by the years the system will live.
Then look at the shape of the costs, not only the total. Platform costs tend to grow with people and time; bespoke costs come first and then flatten. Which shape suits a company depends on its plans as much as on its budget. And where an item cannot be estimated, write it down as a risk rather than as a number.
When made to measure costs less
Bespoke software tends to cost less over time when several of these conditions hold:
- The process is specific to the company and part of how it competes.
- Many people would need licences, and their number is growing.
- The system has to integrate deeply with an ERP, legacy systems or partners.
- A platform would need heavy customisation to fit.
- The system is expected to live for many years.
In our case studies this is the common pattern: a production and shipping flow for large fans shipped disassembled; a loading planner for provisioning ships in port; supplier invoices tied to shipment files. None of these is a standard process. See the case studies.
It costs more; it lasts longer.
We use that line with care. It is true only when the process deserves it, which is why the first job is to find out whether it does.
The hybrid approach
Most enterprises end up with both, and they should. Platforms for commodity functions; bespoke software where the company is different; an integration layer that makes them work as one. The ERP stays the system of record, bespoke applications and AI work around it, and platforms do what they do well.
In practice the line usually falls where the company's own knowledge begins: the way it plans, prices, ships or serves its customers. The design question then becomes where exactly to draw it, and how to keep the parts connected. That is an architecture decision, and it is worth writing down as one.
A decision checklist
- Is the process standard in our industry, or specific to how we work?
- How many people will use the system in five years, and what will the licences cost then?
- How far would the platform need to be customised, and what happens to those changes at each upgrade?
- What must the system integrate with, and who pays for that integration?
- What would it cost to leave the platform, and can we get our data out in a usable form?
- Who will run and evolve a bespoke system, and is it documented well enough to change hands?
- Over the system's expected life, which option costs less in total, including the work around the software?
If the answers point to a platform, choose the platform. If they point to bespoke, that is our work: custom software, with the architecture and operations that keep it lasting.