The question behind the question
Custom software versus off-the-shelf is usually framed as a cost comparison, which is why it is so often decided badly. The real question is narrower and easier to answer: is this particular process something we want to own, or something we are happy to have solved for us?
Once it is framed that way, most of a company’s software decides itself. Payroll is not a competitive advantage — buy it. Email is not a competitive advantage — buy it. The specific way you quote a made-to-order job in under an hour when your competitors take three days might be, and that one is worth owning.
We build custom software for a living, so treat the following with appropriate suspicion. We have also told clients to buy a product and keep their money, which is the honest test of whether a comparison like this is worth reading.
Side by side
| Dimension | Off-the-shelf | Custom-built |
|---|---|---|
| Time to first use | Days — it already exists | Weeks to months — it is being made |
| Upfront cost | Low or none; a subscription starts small | The full build is paid before the value arrives |
| Cost over five years | Rises with headcount and licence increases | Largely fixed, plus maintenance |
| Fit to your process | You adapt to the product, or work around it | The software follows the process you chose |
| Changes you want | A request on somebody else’s roadmap | A scheduled piece of work you commission |
| Who holds the data | The vendor, under their export terms | You, in a database you control |
| Main risk | Price rises, feature removal, product shutdown | Bad execution, or building the wrong thing |
| Best when | The process is standard and solved | The process is yours and worth keeping |
The row that decides most real cases is the third one, and it is the one most often assessed over the wrong horizon.
Run the comparison over five years, include your own maintenance on the build side, and include the licence increases that arrive on renewal. For a ten-person team the subscription usually wins outright. For sixty people on a per-seat product, the arithmetic often reverses well inside the period — and that is before counting the workarounds.
The costs that decide these comparisons are rarely on either invoice. They are the two hours a day someone spends bridging the gap between what the product does and what you needed it to do.
When to buy off-the-shelf
Buying is the right answer more often than a development company usually admits. It is clearly correct when:
- The process is standard. Accounting, payroll, email, calendars, helpdesk ticketing, document storage. These are solved, and the products are better than anything a bespoke budget would produce.
- Regulation keeps changing. Tax rules and statutory filings move. A vendor amortises that upkeep across thousands of customers; you would carry it alone.
- You need it working this month. No build competes with a product on time to first use.
- The requirement is still forming. If you cannot yet describe the workflow precisely, a product is a cheap way to learn what you actually need. That knowledge makes a later build far better specified.
- The team is small and stable. Per-seat pricing is kind to ten people. It is unkind to a hundred.
When to build
Building earns its cost when at least two of these are true:
- The process is part of why customers choose you. Encoding it in software you own protects it; renting it from a vendor makes it available to everyone else too.
- No product fits, and the workarounds have a name. When your team has nicknames for the spreadsheets that bridge two systems, the gap has become infrastructure.
- Per-seat cost is scaling faster than the value. Licences that grow with headcount turn into a permanent tax on growth.
- You need to combine things no single product combines. Most systems we build exist because the required view spans three products that will never merge.
- The data is genuinely yours to hold. Sometimes a client contract, a regulator or a plain commercial judgement makes vendor custody unacceptable.
The hybrid most companies land on
In practice almost nobody ends up at either pole. The pattern that works is buying the commodity layer and building the differentiating one.
Keep the accounting package. Keep the email and the helpdesk. Build the operations system that is specific to you — and connect it to the rest through their APIs so a figure is entered once and appears everywhere. That is usually a smaller build than the platform people imagine they need, because it only has to cover the part no vendor sells.
The examples guide calls this an integration layer, and it is frequently the cheapest project with the largest return.
A four-question test
Answer these honestly and the decision usually makes itself.
- Would a competitor buying the same product get the same result? If yes, buy it — there is nothing here to own.
- What does the current workaround cost per year, in salary? If nobody can answer, the case for building is not ready.
- Over five years, which is cheaper — including maintenance and renewals? One year is the wrong window, and it is the window most decisions use.
- If the vendor doubled the price or shut down, what would we do? If the answer is uncomfortable, you have found a dependency worth pricing.
If you land on building, the practical next steps are how a build actually runs and what it costs. If you are still on the definitions, start with what custom software development is.
Built rather than bought
Two systems where no product covered the span the client needed.
Emarath ERP
Inventory, procurement, finance, HR and reporting folded into one system with role-based access.
FetchKids
A made-to-order storefront where the customer designs the product and sees the result before paying.
Questions
What is the main difference between custom and off-the-shelf software?
Off-the-shelf software is a finished product built for a general market, which you configure and adapt your process to. Custom software is built around a process you have already decided is worth keeping. One trades fit for speed and price; the other trades speed and price for fit and ownership.
Is off-the-shelf software always cheaper?
Cheaper to start, not always cheaper to own. Per-seat licences scale with headcount, and the workarounds a poor fit forces — duplicate data entry, spreadsheets bridging two systems, staff time spent reconciling — are a real cost that never appears on the invoice.
When should a business choose off-the-shelf software?
When the process is genuinely standard rather than a competitive advantage. Accounting, payroll, email and helpdesk ticketing are solved problems with mature products and regulatory upkeep included. Building your own version of those is almost always the wrong use of a budget.
Can we start with off-the-shelf and move to custom later?
Yes, and it is often the sensible sequence. Running a ready-made product first tells you exactly which parts fit and which do not, which turns a vague custom brief into a specific one. Just keep your data exportable from day one so the move is a migration and not a re-entry project.