What is off-the-shelf software?
Software built once and sold to many businesses as it is: an accounting package, a CRM, a project tool, most of the subscriptions a business already pays for. You adapt your process to it, and its maker decides what it does next.
Today, off-the-shelf mostly means software as a service — rented monthly, hosted by the vendor, updated for everyone at once.
What does custom software mean?
Software built around one business’s process: the portal your team signs in to every day, the internal tool that replaces a spreadsheet, the dashboard that finally shows the numbers in one place. It does what was scoped and nothing else, and if it is built properly, it belongs to you.
It is what our Software practice builds: web applications, desktop programs, internal tools, and the APIs that connect them.
Custom vs off-the-shelf: the differences that matter
Feature lists compare badly, because both sides can tick most boxes. These five are where the two actually differ.
- Fit — off-the-shelf fits most businesses reasonably well; custom fits one business exactly.
- Time to first use — off-the-shelf is usable today; a custom first release typically lands six to twelve weeks after a signed scope.
- Change — off-the-shelf changes when its vendor decides; custom changes when you do.
- Dependency — with off-the-shelf you depend on the vendor’s roadmap and pricing; with custom you depend on whoever can read the code, which is why the handover matters.
- Ownership — off-the-shelf is rented access; custom can be owned outright.
When is off-the-shelf the right answer?
More often than most builders will admit. If an existing product already does the job well, buy it: paying to rebuild a subscription is an expensive way to own a worse one. We say so before quoting, not after.
The same goes for standard processes — accounting, payroll, email — where the product’s way of working is the industry’s way of working, and for needs that are still being discovered, where it is too early to know what a custom system should do.
When does custom software earn its cost?
When the workarounds cost more than the build. The signal is usually the same: three subscriptions and a workaround standing in for the system the business actually needed, with someone re-typing between them every day.
It also earns its cost when the process is the business’s advantage and no product models it, or when the data has to live in accounts you control. In each case the test is the same — the cost of the gap, measured, against the cost of closing it.
Is SaaS the same as off-the-shelf?
For this decision, yes. SaaS is off-the-shelf software delivered as a subscription, with the same trade: less to set up, less to own. The difference worth checking before you commit is the exit — whether your data can be exported whole, in a form another system can read, if the product or its price stops suiting you.
Building around the software you already pay for
Often the answer is neither. When the products are right but disconnected, the missing piece is not a new system; it is the plumbing between the ones you have — records that sync, enquiries that route themselves, reports that assemble on schedule. That is automation work, and it usually comes before any case for building from scratch.
Who owns custom software once it’s built?
You should, outright, and it should be agreed before anything is built. In practice, ownership means four things.
- The code — in a repository in your organisation from the first commit, not transferred at the end.
- The credentials — every account it runs on in your name, with the keys held by you.
- The documentation — a runbook plain enough for someone else to run it, change it and hand it on.
- The right to change it — hosted where you choose, maintained by whoever you choose.
Before you build: get the scope in writing
Whichever way it goes, write down who will use the software, what each of them needs from it, and what it will not do — before a line of code. A fixed price on an unwritten scope is a guess with a deposit. How to write that document is its own guide: how to scope a software project.