Every growing company reaches the same fork in the road. A spreadsheet that once held the whole operation starts breaking. A subscription tool that fit last year now needs three plugins and a manual export to do what the team actually needs. Someone in a meeting finally says it out loud: should we just build our own?
That question is usually framed as custom software vs off-the-shelf, as if it were a matter of taste. It isn’t. It is a maths problem wrapped in a strategy problem, and most teams get it wrong because they compare the wrong numbers — licence price against development quote — and ignore everything that happens in the three years after launch.
This guide gives you a practical way to decide. No vendor cheerleading, no “it depends” cop-out. A test you can run on your own process this week.
What each option actually means
Off-the-shelf software is a product built for a market, not for you. Think of a CRM, an accounting suite, a help desk, a project tracker. You rent it per seat, you get updates and support, and you adapt your process to the way the product thinks.
Custom software is built around a process you already own. The data model, the screens, the rules and the integrations are decided by your business instead of by a product manager at a company that has never seen your warehouse.
There is a third option that gets ignored far too often, and we will come back to it: a thin custom layer sitting on top of off-the-shelf products. In practice this is the right answer more often than either extreme.
The five-question fit test
Before anyone asks for a quote, run your process through these five questions. Score each one from 0 to 2. Be honest — optimism here is expensive later.
1. How unusual is the process?
Score 0 if a stranger from your industry could look at your workflow and recognise it immediately. Score 2 if your process is the reason customers choose you — a pricing model nobody else runs, a quality check you invented, a logistics route that only works because of how you sequence it.
Standard processes have excellent products already built for them. Payroll, bookkeeping and email marketing are solved problems. Paying a team to rebuild them is burning money to end up behind.
2. How many people touch it, and how often?
Score 0 for a handful of people a few times a month. Score 2 for dozens of people every single day. Volume is what turns small friction into real cost. Ninety seconds of unnecessary clicking, done forty times a day by fifteen people, is roughly one full-time salary a year evaporating into a user interface.
3. How much manual glue is holding it together?
Count the workarounds: the CSV exported from one tool and imported into another, the WhatsApp group where approvals actually happen, the person whose job is quietly “fixing the sync”. Score 2 if removing the glue would change how the team works, not just how it feels.
4. Is the data a competitive asset?
Score 2 if the information in the system is something you would want to analyse, model or eventually sell insight from. Data that is trapped in a vendor’s schema, accessible only through an export button and a rate-limited API, is data you do not really control.
5. How long will you live with this decision?
Score 0 if you expect the process to change beyond recognition within eighteen months — an early-stage startup still hunting for product-market fit, for example. Score 2 if this is core operations that will still be running in five years.
Reading the score. Under 4, buy off the shelf and stop deliberating. Between 4 and 7, build a thin custom layer on top of tools you buy. Above 7, custom software is likely the cheaper option over the life of the system, not the more expensive one.
The cost comparison nobody runs properly
Off-the-shelf looks cheaper because its cost arrives in small monthly pieces while custom development arrives as one large invoice. Put both on the same five-year timeline and the picture changes.
Here is an illustrative comparison for a forty-person operations team. Your numbers will differ — the point is the shape of the curve, not the figures themselves.
| Cost line | Off-the-shelf | Custom build |
|---|---|---|
| Upfront (build / setup / migration) | Low | High — the entire first-year cost |
| Recurring licences | Per seat, rises with headcount | None |
| Hosting and infrastructure | Included | Modest and predictable |
| Maintenance and changes | Included, but only what the vendor chooses to build | Ongoing, and entirely your priority list |
| Workaround labour | Often the largest hidden line | Near zero if the build was scoped well |
| Cost of a price increase | Unavoidable | Not applicable |
Two lines decide most of these comparisons.
The first is workaround labour. It never appears on an invoice, so it never gets discussed, yet it is usually the single biggest expense of staying with a tool that nearly fits. Measure it before you decide: ask three people to log, for one week, the minutes they spend doing things the software should have done. That number, annualised and multiplied by salary, is the real price tag on “good enough”.
The second is seat growth. Per-seat pricing scales with your success. A custom system’s cost does not — adding the hundredth user costs roughly what adding the tenth did. If you expect to double headcount, model both curves out to that point rather than pricing today’s team.
One caution on the other side: a custom system is never “done”. Budget fifteen to twenty per cent of the original build cost per year for maintenance, security updates and changes. A build presented to you without that line in it has been under-quoted, and you will pay the difference later in emergencies. We cover how to spot this in the questions to ask before hiring a software development agency.
When off-the-shelf is clearly the right call
- The function is regulated and standardised. Tax filing, payroll and compliance reporting change with legislation. Let a vendor carry that burden and the liability that comes with it.
- You need it running next month. Buying compresses months into days. Speed is a legitimate business reason, and sometimes the only one that matters.
- The process is still being invented. Building software around a workflow you will abandon in six months is the most common way early-stage teams waste their runway. Rent flexibility until the process stops moving.
- The market product is genuinely better than anything you would build. Mature categories have a decade of edge cases handled. Respect that.
When custom software wins
- The workflow is the differentiator. If your advantage lives in how you operate, encoding it in generic software flattens it into whatever your competitors also use.
- You are paying for three tools to do one job. Overlapping subscriptions plus the integration work between them frequently costs more per year than a focused build.
- Integration is the whole problem. When the hard part is making six systems agree — inventory, invoicing, field staff, customer portal — a purpose-built layer is usually the only clean answer.
- The vendor’s roadmap is not yours. If you have been waiting eighteen months for a feature request, you are not a customer at that point. You are a spectator.
- Licence cost is scaling faster than revenue. The point where seat fees outrun the value they deliver is the point to model a build seriously.
The hybrid option most teams should take
The framing of custom software vs off-the-shelf as a binary choice is the biggest mistake in this whole debate. In real architectures, the sensible pattern is to buy the commodity and build the difference.
Keep the accounting suite. Keep the email platform. Keep the payment processor. Then build a single custom layer — a dashboard, an internal portal, a small service — that pulls those systems together, applies your business rules, and gives your team one place to work instead of seven tabs.
This pattern is cheaper than a full custom platform, dramatically better than living with the glue, and it fails gracefully: if a vendor disappoints, you replace one connector rather than rebuilding everything. Scope it as a focused first release and cut hard — the same discipline described in our guide to deciding what belongs in an MVP.
Five red flags in the decision process
- Comparing a licence quote to a build quote. Compare five-year totals including labour, or you are not comparing anything.
- Letting a demo decide. Demos are performances run on clean data. Insist on a trial with your own messy records and your own awkward edge case.
- “We’ll customise it later.” Heavy customisation of an off-the-shelf product often costs more than a build and breaks with every vendor update.
- Nobody asked the people doing the work. The team living inside the process knows exactly where it hurts. They are the requirements document.
- No exit plan. Before you commit either way, answer this: if we leave in three years, how do we get our data out, and in what format? If nobody can answer, you have found a risk, not a solution.
How to make the decision in two weeks
You do not need a consulting engagement to settle this. You need a fortnight of discipline.
Week one: map the process end to end on one page, with every handoff and workaround marked. Have three people log their workaround minutes. Pull the last twelve months of actual spend on the tools involved — including anything charged to a personal card, which is where shadow subscriptions hide.
Week two: shortlist two off-the-shelf products and trial them with real data. In parallel, get a scoped estimate for the narrow custom layer, not a grand platform. Then put the five-year totals side by side and run the fit test above.
By the end of week two the answer is usually obvious, and more importantly it is defensible to whoever signs the cheque.
Frequently asked questions
Is custom software always more expensive than off-the-shelf?
No. It is almost always more expensive in year one and often cheaper by year three to five, because licence fees scale with headcount and workaround labour never stops. The comparison only means something over a multi-year horizon.
How long does a custom build take?
A focused internal tool or portal is typically a matter of a few months, not a year. Timelines stretch when scope is vague rather than because the engineering is hard. Narrow the first release and the schedule tightens with it. Our breakdown of app development costs explains how scope drives both budget and calendar.
Can we start with off-the-shelf and move to custom later?
Yes, and it is a sound strategy — provided you check the exit route on the way in. Keep your data exportable in a usable format, avoid burying business logic inside vendor-specific automations, and document the process as you run it. That documentation becomes your specification later.
Who owns the code in a custom build?
You should, in writing, in the contract, with repository access from day one rather than at handover. If a development partner hesitates on this point, treat it as the answer to a different and more important question.
What about no-code and AI-generated tools?
They have genuinely moved the line, and they are excellent for internal tools with modest complexity and few users. They struggle at scale, under real concurrency, with complex permissions and with regulatory requirements. Think of them as a fast way to validate whether a custom tool is worth building properly.
The short version
Buy what is common. Build what makes you different. Refuse to treat the choice as all-or-nothing, measure the cost of the workarounds you have stopped noticing, and judge both options on five-year totals rather than the first invoice.
If you are weighing this decision right now and want a scoped, honest estimate for the custom layer — or a straight recommendation that you should just buy the product and save your money — talk to the team at DevForc. We will tell you which one it is.
