Custom Software vs Off-the-Shelf: How to Decide
Off-the-shelf is cheaper until it isn't. Custom is more expensive until it isn't. The decision comes down to whether your process is a competitive advantage or just a habit.
The default advice is to buy rather than build, and for most business functions it is correct. Accounting, payroll, email, CRM - these are solved problems with mature products, and building your own is almost always a mistake.
But “almost always” leaves a real set of cases where it is wrong, and the cost of getting it wrong runs in both directions. Buying something that does not fit produces years of workarounds. Building something you could have bought wastes money and creates a maintenance burden you did not need.
Here is how to tell them apart.
The question that decides it
Is this process a source of competitive advantage, or is it just how you happen to do a standard thing?
If it is standard - invoicing, expenses, email marketing - buy it. Your version is not going to be better than a product with a dedicated team and thousands of customers, and being different here earns you nothing.
If the process is genuinely how you compete - the thing you do differently that customers notice - then forcing it into someone else’s software means gradually giving up the difference. Products encode assumptions about how work should be done. Adopting one means adopting its assumptions.
Most businesses have one or two processes in the second category and a dozen in the first.
What off-the-shelf actually costs
The licence fee is the visible number. The real cost includes:
Per-seat pricing that scales badly. Fine at ten users, painful at two hundred. This is where the buy-versus-build maths often flips as a company grows.
Workarounds. Where the tool does not fit, people invent processes to bridge the gap - a spreadsheet alongside the system, a naming convention that encodes information the software cannot store, a step everyone knows to do but which is written down nowhere.
Integration work. Rarely free, sometimes not possible. If the tool does not connect to your other systems, someone is re-entering data.
Features you pay for and never use. Not just money - complexity your team navigates every day.
Vendor risk. Pricing changes, feature removal, acquisition, shutdown. Your data is in someone else’s system on someone else’s terms.
What custom actually costs
The build is the visible number and usually not the largest one.
Maintenance. Software decays. Dependencies need updating, security patches applied, browsers change. Budget for ongoing work indefinitely, not just the build.
Specification. Deciding exactly what it should do is genuinely hard and mostly your work, not the developer’s. Projects fail here more than in development.
Change. Every new requirement is a development task, where in a product it might be a setting.
Key-person risk. If one developer knows the system and leaves, you have a problem. Mitigated by documentation and readable code, not eliminated.
Opportunity cost. Time your team spends specifying and testing is time not spent on the business.
The honest comparison
Compare over three to five years, not at the point of purchase.
Off-the-shelf: licence costs including growth, implementation, integration work, and a realistic estimate of what workarounds cost in time.
Custom: build cost, plus annual maintenance - a reasonable planning figure is 15–25% of the build cost per year - plus the internal time to specify and test.
Then add the thing that does not show up in either column: what does it cost you to run the process badly? If a mismatched tool means every order takes six extra minutes, multiply that out. That number is frequently larger than either software cost and it is almost never in the comparison.
When custom is clearly right
- The process is your differentiator and no product supports it without compromise.
- You have tried products and they do not fit. Not “we prefer ours” - actually evaluated and found a specific structural gap.
- Per-seat costs have become absurd relative to what you use.
- Integration is the whole problem. Sometimes the need is a layer connecting systems you already have, not replacing them.
- The workaround has become the system. A spreadsheet several people depend on and nobody trusts is a specification waiting to be written.
When off-the-shelf is clearly right
- It is a standard business function. Someone has solved it better than you will.
- You need it soon. Buying is faster.
- Requirements are still moving. Build when you understand the problem, not while discovering it.
- You have no capacity to maintain software. Custom software without an owner degrades.
- Compliance is heavy. Established products carry certifications that are expensive to replicate.
The middle options people forget
The choice is not binary.
Configure and extend. Many platforms allow significant customisation, or expose an API you can build against. You get the maintained core and the specific behaviour you need.
Build the gap only. Keep your existing tools and build the small piece connecting them. Often this is a fraction of a full custom build and delivers most of the value. Frequently it is automation rather than an application - see AI automation.
Fix the process instead. Sometimes the process is bad, and neither buying nor building fixes it. Automating a broken workflow gives you a faster broken workflow.
A decision sequence
- Write down what the process actually does, including the exceptions. The exceptions are where products fail.
- Evaluate two or three products properly. Not a demo - a trial with your real data.
- List the specific gaps. Not preferences. Structural things the product cannot do.
- Cost the workarounds. Time per occurrence, times frequency, times a year.
- Get a build estimate for the gap only, not the whole system.
- Compare over three years, including maintenance.
Most of the time this exercise points at buying, and often at buying something you had dismissed. When it points at building, it usually points at building something much smaller than what was originally imagined - which is the right outcome.
If you are weighing this decision, describe the process and we will tell you honestly which way we would go, including when the answer is a product we do not sell. More on our approach to app development.