Custom Software vs Off-the-Shelf: Which Is Better for Your Business?
This decision is usually framed as a cost question, which is why it is so often answered badly. The better question is whether the process in question is something your business does the same way as everyone else — or something that is part of why customers choose you.
Published
Every growing company reaches a point where a spreadsheet is no longer enough and a decision has to be made: buy a product, or build something. The debate usually collapses into licence cost versus development cost, and that comparison is misleading in both directions.
Here is a more useful frame. Standard processes should be bought. Differentiating processes should be built. Everything else is detail.
Buy the processes that are the same everywhere
Payroll is payroll. Statutory contributions, tax tables and payslip formats are defined by regulation, not by your business. The same is broadly true of general ledger accounting, email, file storage and standard e-commerce checkout.
For these, a mature product is almost always the right answer. Someone else absorbs the cost of tracking regulatory changes, the software has been tested by thousands of companies, and support exists. Building your own payroll system is a way of buying yourself a permanent maintenance obligation in exchange for nothing.
Build the processes that are actually yours
Now consider how your company takes an order, schedules production, prices a quotation or manages a job through to completion. If those work the way they do because of decisions your business made — pricing structures, service commitments, the way you sequence work — that is not a standard process. It is part of your operation.
A generic product will handle roughly 70% of it. The remaining 30% becomes workarounds: a spreadsheet alongside the system, a field used for something other than its name, a step done manually because the software cannot express it. That workaround labour is a permanent cost, and it never appears in the comparison that led to buying the product.
Comparing costs properly
A fair comparison runs over three to five years and includes what each option actually consumes.
| Off-the-shelf | Custom | |
|---|---|---|
| Upfront | Low — setup and configuration | Higher — design and development |
| Recurring | Per-user licensing that grows with headcount | Hosting plus maintenance, largely flat |
| Fit | Good for standard processes, partial for specific ones | Built to the process; changes as it changes |
| Workaround labour | Often significant and permanent | Should be near zero if built correctly |
| Speed to start | Days to weeks | Weeks to months, staged |
| Change control | Vendor decides the roadmap | You decide, and you pay for it |
| Risk | Vendor pricing changes, features removed, product sunset | Depends on code quality and documentation |
Two lines in that table are usually missing from the business case. Workaround labour is the first: five staff spending forty minutes a day compensating for a system is a substantial annual cost that never appears on an invoice. Per-user licensing is the second: it is affordable at 20 users and materially different at 120, and it scales with exactly the growth you are planning for.
That said, custom development carries a risk that products do not. Badly built software with no documentation and no tests becomes its own legacy problem within a few years. The cost comparison only holds if what gets built is maintainable.
The answer is usually both
In practice, the strongest arrangement for most mid-sized businesses is a hybrid: buy the commodity systems, build the operational layer, and connect them.
Accounting stays in an accounting package. Payroll stays in a payroll product. The system your operations team lives in all day is custom, because it follows your workflow — and it posts to accounting automatically instead of someone re-typing invoices.
This keeps regulatory burden with vendors who specialise in it, keeps your differentiating process under your control, and eliminates the manual re-entry that usually sits between the two. It does require integration work, which is a real cost and a real skill, but it is far smaller than either extreme.
When customisation of a product is the trap
There is a third option that sounds like a compromise and often is not: heavily customising a purchased platform. Some products support this well. Many do not, and the result is the worst of both worlds — custom development costs, plus a vendor upgrade path that breaks your customisations, plus a consultant who is the only person who understands the configuration.
Before going down that route, ask what happens at the next major version, who can maintain the customisation apart from the original implementer, and whether the customisation survives an upgrade. If those answers are unclear, a smaller custom system integrated with a stock product is usually safer.
A short decision guide
- The process is regulated or identical across companies → buy.
- The process is standard but you use 20% of a large product → buy the smaller product, not the enterprise one.
- The process is specific and staff maintain spreadsheets alongside the system → build that part, integrate the rest.
- The process changes frequently as the business evolves → build, with the changeable rules as configuration.
- You cannot describe the process clearly enough to specify it → do neither yet. Map it first.
That last point is not filler. The most expensive software decisions we see are made before anyone has written down how the work currently happens. A process map costs days. Choosing wrong costs years.