Off-the-shelf software is faster and cheaper upfront, but is it really the right choice for your business? The honest answer is that it usually is, and any agency that tells you otherwise before understanding your situation is selling rather than advising.
There is a real threshold, though, beyond which standard software starts costing more than it saves. This article sets out where that threshold sits, how to recognize it, and what each option actually costs over several years.
Start with the assumption that standard software wins
Standard software carries advantages that custom development cannot match at any price:
- The development cost is shared across thousands of customers
- It works on the day you buy it
- Bugs have been found by other people already
- Someone else maintains it, patches it, and keeps it compliant
- You can hire people who already know it
- If it disappoints, you can leave
For accounting, email, CRM, project management, and most e-commerce, excellent standard products exist and building your own would be an expensive way to arrive somewhere worse.
The four signals that standard software has stopped fitting
1. Your process is your competitive advantage
If the way you do something is genuinely different from your competitors, and that difference is why customers choose you, forcing it into software designed for the average case erodes the thing you sell. A logistics business with an unusual routing method, a manufacturer with a distinctive quality process, a service firm with a proprietary methodology: these are cases where the software should follow the business.
2. You are paying people to move data between systems
Count the hours your team spends exporting from one tool and importing into another, or copying numbers into a spreadsheet that then feeds a third system. Multiply by salary. This number is frequently large and almost always invisible, because it is distributed across many people in small daily increments.
Note that the fix here is often integration rather than replacement. Connecting your existing tools properly is far cheaper than rebuilding them.
3. Licence costs scale badly against your growth
Per-user, per-month pricing is excellent at ten users and painful at two hundred. Work out what your current stack costs at the size you expect to be in three years. When that figure approaches the cost of building and running something you own, the arithmetic has changed.
4. The workarounds have become the system
The clearest signal of all. When new staff need a document explaining which fields mean something other than their label, which reports to ignore, and which spreadsheet holds the real numbers, the software is no longer supporting the business. It is a liability being managed.
The real cost comparison
Most comparisons fail because they measure the purchase price of one against the build price of the other. Compare total cost over a realistic horizon, usually five years.
Standard software over five years includes licenses, which typically rise; implementation and configuration; integration work; training; the labor cost of workarounds; and the risk of a forced migration if the vendor changes direction or is acquired.
Custom software over five years includes the initial build; hosting and infrastructure; maintenance and security updates, sensibly budgeted at fifteen to twenty percent of the build cost annually; further development as needs change; and the concentration risk of depending on whoever built it.
That last item deserves attention. Insist on owning the source code outright, on documentation, and on a stack that other developers can pick up. Custom software that only one agency can maintain is a different kind of lock-in from the one you were trying to escape.
The middle path most businesses should consider first
The choice is rarely binary, and the best answer is often a combination.
Integration keeps your existing tools and connects them properly, eliminating manual data movement at a fraction of the cost of replacement. This is the option we recommend most often, and it is frequently dismissed too early.
Extension keeps a standard platform for the common work and builds custom modules only where you are genuinely different.
Custom front end on standard back end gives your team a purpose-built interface while proven systems handle data and compliance underneath.
Full replacement should be the last option considered, not the first.
A decision framework
- Write down the actual problem. Not “we need a new system” but “quotes take three days because pricing lives in two places”. Problems stated this way often have cheap solutions.
- Cost the current pain. Hours lost, errors made, deals delayed. If you cannot quantify it, you are not ready to invest in fixing it.
- Re-examine standard options properly. Including configuration you have not tried and products you dismissed early.
- Price integration as a serious alternative. Compare it against replacement honestly.
- Only then consider building, and start with the smallest version that solves the specific problem rather than the complete system you imagine.
Frequently asked questions
How much does custom software cost?
A focused first version solving one clear problem typically starts in the low tens of thousands of euros. A full platform with multiple user types, integrations, and reporting is a substantially larger commitment. The variable that moves the number most is scope discipline, which is why we push hard to cut version one down to what is genuinely necessary. Our engagement models are on the SaaS development page.
How long does it take?
A well-scoped first version usually takes eight to twelve weeks. Anything promised in two weeks is either trivial or will be rebuilt within a year.
What happens if we stop working with the agency that built it?
Provided you own the code, hold the infrastructure accounts in your own name, and the stack is mainstream, another team can take over. Confirm all three before signing anything. We transfer the repository and accounts on final payment as standard.
Can we start small and expand later?
Yes, and you should. Build the smallest version that solves the real problem, put it in front of actual users, and let their behavior direct what comes next. Businesses that specify everything upfront routinely build features nobody uses.
The short version
Buy standard software unless you have a specific, quantified reason not to. When you do have that reason, be precise about which part of your operation is genuinely distinctive, and build only that.
We build custom platforms when they are warranted and say so plainly when they are not. If you are weighing this decision, describe the problem to us and we will tell you which of the options above we would choose in your position, including when that option is to change nothing.
