Custom software or off-the-shelf: how to decide without asking a salesperson

Off-the-shelf wins more often than a custom software company likes to admit

Most processes in most businesses are not special. They feel specific from the inside because you do them every day, but their shape is shared with thousands of other organisations, and someone has already built a good product for it.

Off-the-shelf is the right answer, clearly, when any of these hold:

• The process is defined for you by legislation or standard practice. Payroll, superannuation, BAS and GST, the general ledger, employment records. Xero, MYOB and Employment Hero absorb every regulatory change across their whole customer base. On your own you would pay for each change forever and gain no advantage from it.
• Few people use it, or the volume is low. A handful of users and a few dozen transactions a week rarely justify a build.
• The process is still changing shape. A service line that works differently every quarter is not ready to be built. Software makes a process rigid, and rigidity is only valuable once the process has settled.
• A shortlisted product fits most of it, and the gap is preference rather than economics. "We would rather it looked like our old system" is not worth what a build costs.
• Nobody inside the business will own a system. Custom software needs someone accountable for decisions, priorities and testing changes. Without that person it decays, whoever built it.
• You need it working in weeks. Nothing custom arrives that fast.

If three or more describe your situation, stop reading and go shortlist products. That is the honest answer, and the more common one.

The sticker price is the smallest number in the decision

Both quotes understate. Compare over three to five years and count everything.

Off-the-shelf, five-year cost: licence fees, per user, per month, for sixty months. Tier upgrades when you cross a user or record threshold. Modules bought later because a feature you assumed was included is not. Implementation and configuration. Data migration. Integration work to make it talk to what you already run. Annual price rises. Training as staff turn over.

Custom, five-year cost: discovery and process mapping. The build. Hosting and any third-party services it calls. Changes, which are not a defect but the normal condition of a system in use. Support and maintenance. And the internal person who owns it, a real cost that never appears on an invoice.

What is unusual is writing both lists down before deciding, instead of comparing an implementation quote against a monthly licence rate and calling that a comparison.

The per-seat trap: your licence bill tracks your headcount, not your value

This is the number people miss, and often the one that changes the answer.

Per-seat pricing ties your software cost to how many people you employ, not to how much the software does for you. Hire twelve people and the bill rises by twelve seats, whether or not the software delivers anything more than it did last month. Grow to three times your size and you pay roughly three times as much for the same functionality.

Work it out. Take the per-seat rate on your current invoice, multiply by seats and by twelve for year one, then apply your hiring plan year by year, add a realistic annual price rise, and sum five years. For a stable ten-person business the total is modest and this argument is weak. For a business planning to double, the five-year figure is often well beyond what anyone assumed at signing.

Two things to check on your own contract. Tier thresholds: crossing a user or record limit can move you to a materially different rate, so find the threshold before planning around it. And seasonal workforces — retail through Christmas, construction and mining through a shutdown. Most annual agreements let you add seats mid-term but not remove them until renewal, so you pay peak rates for a trough workforce.

Custom software is usually priced against scope and support rather than seats, so the cost curve flattens as you grow. That is the strongest financial argument for building, and it only applies if you are actually growing.

The cost of process compromise, and when bending is fine

Every product asks you to work its way, and sometimes that is a gift: vendors have watched thousands of businesses do the same job, and their way is often better than the one you invented under pressure five years ago. Adopting it is free improvement.

Bending is fine when the compromise is one-off — you retrain once, people adjust, nobody thinks about it again — and when the process is not a source of advantage. Nobody wins work because of how they file a remittance.

Compromise gets expensive when it recurs per transaction. A workaround performed on every job, every invoice, every timesheet is not an inconvenience, it is a running cost. Price it: minutes per occurrence, times occurrences per week, times fifty weeks, times a loaded hourly rate, times five years. Small numbers per transaction become uncomfortable totals at volume, and almost nobody does this arithmetic before signing.

Two tells that the compromise costs more than the licence. First, a spreadsheet living beside the product, doing the part the product cannot — job costing, allocation, a register the product has no field for. You are paying for software and maintaining a system anyway. Second, and more serious: the compromise changes what you sell. You stop offering a service, or bill differently, or turn down an unusually structured job, because the system cannot represent it. Once a product constrains commercial decisions, its true cost has left the licence line entirely. Mapping the process before choosing anything is what surfaces those cases while they are still cheap to act on.

Switching costs and lock-in, in both directions

Whatever you choose, you are choosing what it will cost to leave. Both options lock you in, differently.

Off-the-shelf. Ask a vendor to run a full export and show you the file before you sign, not after. Exports commonly give you current state, not history — no audit trail, no attachments, sometimes no custom fields, rarely the relationships between records. Then count what you have built around the product: integrations against their API, reports, automations, habits. Retraining a team is a real project, and so is a notice period nobody has read.

Custom. The lock-in is a dependency on the people who built it: undocumented decisions, a hosting account in the developer's name, code nobody else has read. Manageable, but only if you manage it deliberately at the start.

Ask the exit question during the sales conversation, of both sides. A vendor who will not demonstrate an export, and a developer vague about where the repository lives, are telling you the same thing.

Who owns what, and what happens if the developer disappears

Settle five things in writing before custom work begins.

• Intellectual property. Assigned to you, or licensed to you? Both can be reasonable, and subscription arrangements more often licence than assign — but know which you have, and what happens to it if you stop paying.
• Source code. In a repository owned by your organisation with your own administrator access, or in escrow. Not on a laptop.
• Hosting and domains. Accounts in your business's name, billed to your card, with your people as owners. The most common failure, and the most annoying to unwind.
• Data. Exportable in a documented format on demand, without needing anyone's cooperation. Know which country it sits in, and under whose terms.
• Documentation and environment. Enough that a developer who has never seen it can stand it up. If nobody has tested that claim, treat it as untested.

We price on a subscription rather than a fixed project fee, which makes the ownership question sharper rather than softer. Any provider working that way should answer all five plainly and in writing, and hesitation on any of them is itself the answer.

Off-the-shelf has the same failure mode in a better suit: vendors are acquired, products withdrawn, pricing changed. Neither option removes your dependency on someone else. They relocate it, and you are choosing which dependency you would rather manage.

The middle ground nearly every business actually lands on

Almost nobody ends up all one or the other. Buy the commodity, build the part that is genuinely yours.

Buy accounting and payroll — Xero, MYOB, Employment Hero. Buy rostering, email and file storage. Buy the CRM if your sales process is ordinary, and the industry platform where it fits: Shopify or Cin7 in retail, Procore or SimPRO in construction and trades.

Build the part nobody sells, because it is specific to how you operate. How you price a complex job. How you plan a shutdown. How you onboard contractors against a client's requirements. The register carrying your actual compliance obligations rather than a generic version. These are usually the processes where a spreadsheet already sits beside a product, which is a reliable indicator of where the boundary falls.

Then the real work is joining them, so the custom part reads from and writes to the packages and nobody rekeys anything. That integration between the systems you already run is what makes a hybrid work; skipping it leaves you with one more island.

One warning. This only holds if the boundary is drawn deliberately and then defended. The common failure is a custom build that creeps outward over three years and slowly reimplements accounting, badly. Write down what the custom system is for and what it will never do.

A test you can run yourself

Run it per process, not per business.

1. Is this process defined for everyone by legislation or standard practice? 2. Could you describe how you do it to a competitor without giving anything away? 3. Did you shortlist three products and find one that fits most of it, with the remainder being preference rather than cost? 4. Over five years, with your real hiring plan and the recurring workaround cost priced, does the product still come in comfortably below build and support? 5. Is the process still changing shape every few months? 6. Is there nobody inside the business who would own a custom system?

Four or more yes. Buy the product, and do not let anyone talk you out of it, us included.

Two or three yes. Hybrid territory. Buy for this process, then check whether the compromise concentrates in one adjacent process that is the real candidate for something built around how you work.

Nought or one yes. A build is proportionate here — not for everything else. Run the test again on the next process and expect a different answer.

If you cannot answer question four because you do not have the numbers, that is the task that comes before the decision.