Buy off-the-shelf software when the job is standard and the tool fits without workarounds. Build custom software when the process is how you win work, when per-seat fees are growing faster than the business, or when several tools need to behave as one system. That is the short answer to custom software vs off-the-shelf software, and most growing businesses end up using both.
The longer answer is arithmetic plus a judgement call. This guide lays out both: what each option really means, how they compare line by line, what they cost over three and five years, and a matrix you can use to decide.
What custom and off-the-shelf software actually mean
In short: off-the-shelf software is built once and rented to many; custom software is built once for you and owned by you.
Off-the-shelf software (also called packaged software) is a product designed for a broad market. Today it is nearly always sold as SaaS: hosted by the vendor, used in a browser and paid for monthly per user. HubSpot, Xero, Monday.com and Shopify are familiar examples. You configure it, and where it does not match the way you work, you change the way you work.
Custom software (bespoke software) is designed and built around one organisation’s process. It can still be a cloud web app that staff use in a browser. The difference is that it does exactly what your business needs, connects to whatever you already run, and the code, data and cloud account belong to you.
Neither is better in the abstract. A £20-a-month accounting package is a far better answer to bookkeeping than anything you would commission. A generic project tool is a poor answer to a freight forwarder’s per-container costing logic.
Custom software vs off-the-shelf software, side by side
In short: off-the-shelf wins on speed and starting cost; custom wins on fit, ownership and cost at scale.
| Off-the-shelf (packaged / SaaS) | Custom (bespoke) | |
|---|---|---|
| Cost model | Low start, then a per-user subscription that rises with headcount and at renewal | One-off build, then hosting plus maintenance (typically 15–25% of build a year) |
| Time to start | Days, although proper configuration takes longer | A focused first release in about 2–4 weeks; larger systems phased over months |
| Fit to your process | You adapt to the product; gaps are filled with workarounds and spreadsheets | Built around your process, including the unusual parts |
| Integrations | Strong with popular tools via marketplaces; weak or costly with your own systems | Connects to anything with an API, on your terms |
| Scalability | Technically scales well; cost scales with every seat and premium tier | Scales with good architecture; adding users rarely adds licence cost |
| Ownership and IP | You own your data; the vendor owns the software and the roadmap | You own the code, the data and the cloud account (if your contract says so) |
| Vendor lock-in | Price rises, feature removals and export limits are outside your control | Lower, but you depend on whoever maintains it, so insist on documentation and repository access |
| Security and control | Vendor runs security on a shared platform; you assess them and configure access | You choose hosting region, access rules and audit trail, and you are responsible for maintaining it |
| Support | Ticket queues and help centres; your requests join everyone else’s | A named team that knows your system; changes cost engineering time |
Two rows deserve more than a table cell.
Security is a responsibility either way
Buying SaaS does not hand off your security responsibilities. The UK’s National Cyber Security Centre publishes 14 cloud security principles and advises customers to assess a cloud service and the company behind it against each one. For personal data, the ICO is clear that a controller remains responsible for processing carried out by a processor on its behalf and needs a binding contract with that processor. That applies to a SaaS vendor and to a development partner hosting your custom system. (This is general information, not legal advice.)
Lock-in looks different, not absent
With SaaS, lock-in is commercial: years of data and workflows live inside a platform whose prices you do not set. With custom software, lock-in is about people: if only one supplier understands the code, you are tied to them. The fix is contractual and practical. Code in a repository you own, infrastructure in your cloud account, and documentation good enough for another team to pick it up.
Custom software vs SaaS
In short: SaaS is a delivery and pricing model, not the opposite of custom, but in practice the comparison is rented generic software against owned specific software.
People often search “custom software vs SaaS” as if the two were opposites. Strictly, SaaS just means hosted and paid by subscription. A custom system can also be cloud-hosted, browser-based and updated continuously, so from a user’s point of view it can feel exactly like SaaS.
What really differs is who the software is built for and who controls it:
- Pricing. SaaS charges per seat or per usage tier, forever. Custom charges for the build, then for hosting and maintenance, regardless of headcount.
- Roadmap. A SaaS vendor builds for its whole market. If your request matters to few customers, it waits. On a custom system, your priority list is the roadmap.
- Data location and access. SaaS stores your data where the vendor chooses, within whatever regions it offers. Custom software runs in a region and account you pick.
If your team works happily inside one or two SaaS tools and the bill is stable, none of that matters much. It starts to matter when the bill grows faster than revenue or the tool shapes how you sell.
Total cost of ownership over three to five years
In short: for a growing team, subscriptions usually overtake a custom build within two to three years; for a small, stable team, they often never do.
The first invoice is the least useful number in this decision. What matters is total cost of ownership: everything you pay over the period you will actually use the system.
Illustrative example (not a real client, not a quote): a services business uses a set of SaaS tools for pipeline, job tracking and client updates that together cost £45 ($60) per user per month. It has 20 users today and adds 5 a year. The custom alternative replaces those tools with one system built for £18,000 ($24,000), hosted for about £100 ($125) a month, with maintenance at 20% of the build a year from year two. Accounting, e-mail and payroll stay off-the-shelf in both cases.
| Year (users) | Off-the-shelf SaaS | Custom build |
|---|---|---|
| Year 1 (20) | £13,300 / $17,400 (incl. £2,500 / $3,000 setup) | £19,200 / $25,500 (build + hosting) |
| Year 2 (25) | £13,500 / $18,000 | £4,800 / $6,300 |
| Year 3 (30) | £16,200 / $21,600 | £4,800 / $6,300 |
| Year 4 (35) | £18,900 / $25,200 | £4,800 / $6,300 |
| Year 5 (40) | £21,600 / $28,800 | £4,800 / $6,300 |
| 3-year total | £43,000 / $57,000 | £28,800 / $38,100 |
| 5-year total | £83,500 / $111,000 | £38,400 / $50,700 |
In this example the custom option costs more in year one and is cheaper on a cumulative basis by the end of year two. The SaaS figures assume no price rises at renewal, which flatters them.
Now run the same numbers for a team of 8 that is not growing. The SaaS bill is about £4,320 ($5,760) a year, so roughly £15,500 ($20,300) over three years and £24,100 ($31,800) over five, including setup. The custom build still costs £28,800 ($38,100) and £38,400 ($50,700). Off-the-shelf wins, comfortably.
What the example leaves out, deliberately: staff time spent on workarounds (which favours custom), change requests beyond routine maintenance (which favours SaaS), and data migration effort (which applies to both). Put your own figures in. For realistic build prices, use our UK custom software cost guide or the custom software development cost guide in US dollars.
The hybrid option: buy the standard, build the difference
In short: keep off-the-shelf tools for commodity jobs and build a custom layer only where your process is unique.
The choice is rarely all-or-nothing. Most growing businesses we work with keep their accounting package, e-mail, payroll and payment provider, and build one custom system for the workflow that makes them different, connected to everything else through APIs.
Accounting and tax filing, e-mail and documents, payroll, payments, standard e-commerce checkout. These are solved problems with mature, regulated products behind them.
Quoting and costing logic, job or case management, the client portal, scheduling rules, the operational dashboard. The parts your competitors do differently, and the glue between your other tools.
Hybrid has its own costs. Each connection needs building and looking after, and you still pay some subscriptions. But it puts custom development money where it changes how the business runs, rather than rebuilding things that already work. The business software solutions guide covers which categories of tool most SMEs should simply buy.
A build vs buy decision matrix
In short: score the process on how standard it is and how much it matters; that tells you whether to buy, configure, connect or build.
Plot the process you are trying to fix on two questions. Is it standard, meaning most businesses do it the same way? And is it central to how you win or deliver work?
| Standard process | Process unique to you | |
|---|---|---|
| Central to how you win or deliver work | Buy and configure properly. A good CRM or job tool, set up well, often covers this. Revisit if seat costs explode. | Build custom. This is where off-the-shelf forces you to change how you compete. It is the strongest case for bespoke software. |
| Back-office or supporting | Buy. Accounting, payroll, e-mail. Do not build these. | Connect or build small. Usually an integration or a small internal tool, not a whole platform. |
Then apply three tie-breakers. If seat costs will at least double in three years, lean towards building. If you need something live next week, lean towards buying. If two systems must act as one, such as a won deal that should create a job and an invoice, lean towards a custom layer between them.
If you are not yet sure the current tools are the problem, start with our companion piece on when a business should build custom software. It covers the warning signs and the cases where building is the wrong move. For sales systems specifically, the custom CRM vs off-the-shelf CRM guide applies this same logic to pipelines and follow-up.
Checklist before you decide
In short: write the process down, price five years, and decide who will own the result.
- Describe the process in plain steps, including the spreadsheets and copy-paste in between. If you cannot describe it, you cannot buy or build for it.
- Trial at least one off-the-shelf option against that process for real, with the people who will use it.
- Price five years for each route, with honest user growth and expected renewal increases on the SaaS side, and maintenance on the custom side.
- List the integrations you need: accounting, e-mail, payments, phone, anything bespoke. Check each one actually exists and does what you need.
- Check data and security: where data is hosted, who can access it, what the contract says, and whether you can export everything.
- Settle ownership: for custom, code and cloud accounts in your name; for SaaS, the exit terms and export format.
- Start with one workflow, whichever route you choose. Prove it, then extend.
How DataVolve approaches the decision
In short: we start by asking what you should keep, then build only what earns its cost.
DataVolve has delivered more than 75 projects since 2021 for clients in the UK, the US and elsewhere. Most of them were hybrid: a custom system built around the client’s own workflow, connected to the accounting, e-mail and payment tools they already used. Clients own the code, the cloud account and the domain from the first commit, and see working software at weekly demos.
If the numbers say buy, we will tell you so. If they say build, we usually start with one workflow, with a first working release of a focused tool possible in about 10 days. See how we work on our custom software development page, or our CRM development service if the problem is sales and follow-up. You can also describe your process in a few lines and get a written, scoped plan within 24 hours of a call.