We build custom web applications, so you can reasonably expect this article to argue for building one. It is not going to, because for most businesses most of the time, buying is the right answer — and a development partner who cannot say that is not giving you advice, they are quoting.
What follows is the comparison we actually walk clients through, including the costs on both sides that tend to surface late.
The two options, defined properly
Off-the-shelf software is a product built for many businesses. You configure it, you work within its model of your industry, and you share its roadmap with everyone else who uses it. Most of it is SaaS now, billed per user per month.
A custom web application is software built for one business. It implements your process rather than a generalised version of it, you own the result, and you are responsible for its upkeep.
There is a third option people forget, and it is often the best one: buy, then integrate. Keep the packaged products that do their jobs well, and build only the thin layer that connects them or covers the part none of them handle. Far more of our work looks like this than like a from-scratch replacement.
What each one is genuinely good at
| Off-the-shelf | Custom | |
|---|---|---|
| Time to running | Days to weeks | Weeks to months |
| Up-front cost | Low | Significant |
| Cost at 5 years | Grows with users | Largely fixed, plus maintenance |
| Fit to your process | You adapt to it | It is built around you |
| Features you get free | Everyone else's requests | Only what you commission |
| Who fixes a bug | The vendor, eventually | Whoever you choose, now |
| Who sets the roadmap | The vendor | You |
| If the supplier disappears | A migration project | You still have the code |
| Compliance and audit | Vendor's posture | Yours to build and prove |
Where off-the-shelf wins
The problem is genuinely standard. Accounting, payroll, email, CRM, helpdesk, file storage. These are solved problems where decades of accumulated edge cases are built into the product. Building your own invoicing system to save a subscription fee is one of the more expensive mistakes available.
You need it working next week. Nothing custom competes with this.
You cannot predict your requirements. Early-stage businesses change shape quickly, and packaged tools absorb that better than code written around last quarter's process.
The feature budget is shared. Every other customer's feature request is partly paid for by them. That is real value, and it compounds.
Where custom wins
Your process is the competitive advantage. If the way you schedule, price, route or fulfil is genuinely different from your competitors — and it is the reason customers choose you — software that flattens it into an industry-standard workflow is actively costing you something.
No product covers the shape of the work. Businesses that operate across two categories are the classic case: a cleaning company that does both fixed-rate and hourly jobs, with subcontractors, service areas and weekly pay, is not one product's customer. It is three products and a lot of copying between them.
The integration is the product. When the actual job is making five existing systems behave like one, that connective layer has to be built. We look at that pattern in detail in how API integrations help businesses automate work.
Per-user pricing has stopped making sense. Fifteen users at £40 a month is £7,200 a year, and it rises with headcount. At that level the arithmetic deserves checking — though see the warning about this below, because it is also the most commonly miscalculated argument for building.
The data has to stay where you control it. Sometimes regulatory, sometimes contractual, sometimes a client requirement you have agreed to.
The cost comparison people get wrong
The seductive version is: the SaaS costs £7,200 a year, the custom build costs £30,000, so we break even in just over four years.
That calculation is wrong in both directions, and both errors matter.
What it understates about building. The build is not the cost of ownership. A custom application also needs hosting, security patching, dependency updates, backups and monitoring; the occasional change as the business changes; a developer reachable when something breaks; and at some point a modernisation when the framework it was built on reaches end of life. Budget for maintenance as a real annual line, not an afterthought — somewhere between 15% and 25% of the original build cost a year is a realistic planning figure for an actively used system, and what that actually covers is worth understanding before you sign up to it.
There is also the cost of specifying the thing. Custom software requires you to decide what your process is, precisely, including the awkward exceptions everyone currently handles by asking a colleague. That decision-making is work, it is your work, and it cannot be outsourced.
What it overstates about buying. The subscription is rarely the real cost of packaged software that does not fit. The real cost is the workarounds: the spreadsheet that bridges two systems, the data re-entered by hand, the report compiled manually every Monday, the process step that exists only because the software cannot do it. Those hours are invisible on an invoice and substantial in aggregate. Before comparing numbers, count them.
So the honest comparison is not subscription versus build. It is (subscription + workaround labour + opportunity cost of the misfit) against (build + annual maintenance + your specification time), over a horizon of about five years.
Workflows: the decisive question
If you take one test from this article, take this one.
Watch somebody do the job. Not describe it — do it. Count how many times they leave the software to complete a step that the software ought to handle: opening a spreadsheet, copying a value into an email, checking a paper note, asking a colleague, re-entering the same data into a second system.
Few of those, and your tooling fits. Build nothing.
Many of them, and you are already paying for custom software — in salary, quietly, indefinitely, with none of the reliability that actual software would give you.
Integrations
Integration capability is the thing to check hardest before buying, and the thing most often assumed.
For any packaged product you are considering, ask:
- Is there a documented API, and is read and write supported for the data you care about?
- Is it included in your price tier, or does it need the enterprise plan?
- Are there rate limits, and do they suit your volume?
- Can you export everything, in a usable format, if you leave?
- Are there webhooks, or is polling the only option?
"It integrates with Zapier" is not the same as having an API. It means someone else's connector covers some operations, chosen by them, and it may not include the one you need.
A custom application has no integration problem in principle, but it has an integration cost: every connection is something you build and then maintain, including when the other party changes their API. That maintenance is permanent, and it is the part of integration work people forget to budget for.
Maintenance and scalability
Off-the-shelf: the vendor maintains it. In exchange, you accept their changes — the interface redesign you did not ask for, the feature that gets retired, the price rise, the plan restructure. Your scalability is their scalability, which is usually good, until it turns into a higher pricing tier.
Custom: nothing changes unless you change it, which is both the advantage and the obligation. Security patches do not apply themselves. Scaling is an engineering question with an engineering answer, and for the overwhelming majority of business applications the answer is "this will be fine for years" — most custom systems we maintain serve their entire organisation comfortably from a single modest server. Scaling becomes genuinely hard only at a volume that most businesses never reach, and if you do reach it, you will have the revenue to address it properly.
A decision framework
Work through these in order. The first clear answer usually settles it.
1. Is the problem standard? Accounting, payroll, email, CRM, storage, helpdesk — buy. Do not build these. Stop here.
2. Does a product exist that fits without workarounds? Trial it properly, with real data and the people who will use it. If it fits, buy it. Stop here.
3. Does your differentiation live in this process? If the way you do this thing is why customers choose you, custom is worth serious consideration.
4. How much workaround labour is the misfit costing? Count the hours. Annualise them. Compare with a build estimate plus five years of maintenance.
5. Would integration solve it? Often the answer is to keep the products and build the connecting layer, which is a fraction of the cost of replacing them.
6. Can you sustain ownership? A custom application needs a budget line and a responsible party, permanently. If neither exists, a packaged product that fits badly is still better than a custom one that nobody maintains.
7. What does five years look like? Not three months. Headcount, volume, likely process changes, and what happens if your vendor is acquired or your developer moves on.
The answer for most businesses
Buy the standard things. Buy anything a mature product does well. Build only where your process is genuinely yours, or where the connective tissue between systems is the work — and when you do build, budget for owning it rather than just making it.
If you are somewhere in the middle of that and want a second opinion, we are happy to look at what you have and tell you honestly which side of the line we think you are on. Our case studies include several businesses that arrived expecting to need a full custom platform and left with a smaller, cheaper answer.
