The question is usually framed as a budget decision: off-the-shelf is cheaper, custom is expensive, choose according to what you can afford.
That framing produces bad outcomes in both directions. Businesses buy a product because it is cheaper, spend two years working around it, and abandon it. Or they commission a custom build because they believe their operation is unusual, and discover eighteen months later they paid to rebuild something they could have configured.
The useful question is not cost. It is where your operation genuinely differs from the assumptions the product makes — and whether that difference is worth owning software over.
There are three options, not two
The framing hides a middle option that is frequently the right answer.
Off-the-shelf. A finished product. You adapt to its model of how the work is done.
Configured. A capable platform shaped to your vocabulary, workflow and module set. The architecture is shared; the fit is specific.
Custom. Software written for your operation. You own it, including forever.
Most decisions presented as a binary are actually a choice between the first and the second, with custom brought up as leverage. Recognising the middle option changes the economics considerably.
The real cost of off-the-shelf is not the licence
Product pricing is visible and comparable, which is why it dominates the evaluation. The costs that matter are the ones that do not appear on the quote.
Process adaptation. Every product encodes an opinion about how work should be done. Where yours differs, someone changes — and it is not the software. That change has a cost paid in retraining, in exceptions, and in the workarounds that reappear within a year.
Permanent translation. If the product's vocabulary differs from your team's, every user translates on every interaction, indefinitely. This is invisible in a demo and corrosive in production.
Capability you do not use. Products are built for the widest viable market, so most businesses pay for substantial functionality they never touch — and navigate around it daily.
The gap at the edges. Products are strong in their core and weak at the boundaries. A product excellent at appointments may be poor at stock, and the gap gets filled by a spreadsheet, which reintroduces the exact problem the purchase was meant to solve.
None of this argues against off-the-shelf. It argues for pricing it honestly.
The real cost of custom is not the build
Custom is quoted as a project and lived as an obligation.
You own maintenance forever. Dependencies age, platforms change, security patches are required. Nobody else is doing this for you.
You own the knowledge. If the people who understand the system leave — yours or the vendor's — the cost of the next change rises sharply. This is the most common way custom software becomes a liability.
You own every change. Every adjustment is a small project with a cost and a queue. Products ship improvements you did not pay for; custom software improves only when you fund it.
You lose the shared road. A product used by thousands has had its bugs found by thousands. Your custom system has been tested by you.
The correct reason to accept those costs is that the process is the advantage and encoding it compounds. "We are different" is not sufficient. Almost every business believes that.
The four questions that decide it
Answer these about your operation before evaluating any vendor.
Is the difference structural or vocabulary?
This is the decisive one. Structural difference means the shape of the work is genuinely unlike the product's model — a different transaction lifecycle, a regulatory obligation, a unit conversion running through everything.
Vocabulary difference means you do the same things with different words. That feels significant from inside and is solved by configuration, not by a build.
Most businesses that commission custom software had a vocabulary problem.
Is the process a competitive advantage or just a habit?
If how you do the work is why customers choose you, encoding it in software is defensible. If it is how you have always done it, adopting a well-designed product's process is frequently an improvement rather than a compromise.
Being honest here is difficult and worth the discomfort.
What happens at the edges?
Map what the product does not cover. If the answer is "we'll use a spreadsheet for that", you have not eliminated your reconciliation problem — you have renamed it. Why multi-system operations leak money is the same failure in another form.
Can you leave?
Ask about export before you buy anything, product or custom. A system whose data cannot leave in standard formats is a system with a rising switching cost, and that cost becomes a negotiating position against you at every renewal.
What we have actually seen
We have delivered ten systems, and the pattern is consistent: the businesses that came to us convinced they needed something entirely bespoke usually needed the middle option — a shared architecture configured to their vocabulary and module set.
Those ten deployments are genuinely different systems: a multi-outlet retail ERP, clinic management, inventory, warehouse, delivery, logistics, production monitoring, factory operations, and billing and operations management. What varied was rarely the underlying structure. It was language, reporting, regulatory obligation, and which modules were needed at all.
That is why our first phase is documenting how the operation actually runs rather than collecting requirements. You cannot tell whether a difference is structural or vocabulary from a specification document — but you can usually tell within a day of watching the work. The full method is in how Truffaire builds software.
When we say buy the product
Where a sector has a genuinely unusual regulatory structure and a mature vertical product already encodes years of that domain, buying it is often the better decision. Choosing between vertical, general and custom by sector covers how to tell.
Where a business is single-location with simple stock and one person holding the full picture, the honest answer is usually to change nothing yet.
Frequently asked questions
Is custom software always more expensive?
Over the first year, usually yes. Over five, not necessarily — a product requiring constant workarounds, paid seats you do not use, and a spreadsheet filling its gaps has a real cost that never appears on an invoice. Compare total cost over a realistic horizon.
Can we start off-the-shelf and move to custom later?
Yes, and it is often sensible — provided you confirm export before you start. Businesses that discover at migration time that their data cannot leave cleanly end up paying twice.
How do we know if a vendor is selling us custom unnecessarily?
Ask them what they would configure rather than build, and why. A partner who cannot identify anything reusable in your requirements is either not looking or is billing by the hour.
What about low-code platforms?
They sit near the configured option and suit well-understood, low-complexity workflows. The failure mode is that as complexity grows, you end up maintaining something with the constraints of a product and the obligations of custom.
Does configured software cost more than off-the-shelf?
Upfront, generally yes, because configuration is work. The comparison that matters is against the adaptation cost of the product — retraining, workarounds, and the spreadsheets filling its gaps.
Where to start
Do not begin with vendors. Begin by classifying your own difference: structural or vocabulary. Almost everything follows from that answer.
If it is structural and legally binding, a specialist product or a build is justified. If it is vocabulary and workflow, configuration will fit better and cost less to live with. If the process is genuinely your advantage, custom may be right — with clear eyes about owning it for years.
The expensive mistake is not picking wrong. It is picking before you know which category you are in.
What a business operating system actually is covers the architecture behind the middle option, and SPEXA is our implementation of it. If you want a straight read on which category your operation falls into, get in touch — including if the answer is to buy something other than ours.