The honest default is buy.
Somebody has already built accounting software, and payroll, and helpdesk ticketing, and email marketing, and they have spent years finding the edge cases you have not thought of yet. They amortise that work across thousands of customers, which is why a subscription costs less per month than an afternoon of development. For most business functions, most of the time, buying is not the compromise. It is the correct engineering decision.
That is not a comfortable opening for a company that builds custom software, and it is the necessary one. The build-versus-buy decision is made badly in both directions, and the version of it made badly in our favour is the more expensive of the two.
This article is about telling them apart.
The two questions underneath the decision
Almost every real case reduces to these:
Is this process generic, or is it yours? Invoicing is invoicing. There is a right way to do double-entry bookkeeping and your business is not going to improve on it. But the way you quote a complex fabrication job, or route an engineer, or grade an application, may be the thing you are actually good at. If a process is a source of advantage, standardising it to fit a product is not a saving. It is paying a subscription to become more like your competitors.
What does adapting cost? Not the licence — the adaptation. Every off-the-shelf product asks you to change shape to fit it, and that trade is usually worth making. It stops being worth making when the workarounds become the job.
The four situations where building is justified
Building is defensible when at least one of these is clearly true. If none is, buy, and spend the saved money on something else.
One — the process is the advantage. You do something in a way competitors do not, and it wins you work. A product that standardises it would remove the thing customers are paying for.
Two — nothing on the market fits, and the gap is structural. Not "the interface is ugly" or "it is missing a report", but a mismatch in how the product models the world. If a product assumes one customer has one address, and your entire business is multi-site contracts, no amount of configuration fixes that. You are fighting the data model, and the data model always wins.
Three — the integration burden is larger than the product. You have four systems that must agree with each other. A fifth product with its own idea of what a customer is may add more reconciliation work than it removes. Sometimes the correct build is not a replacement application at all but the layer that makes the existing four agree.
Four — the workarounds now cost more than the licence. This is the most common and the least noticed, because the cost appears as salaries rather than as software. Someone exports to a spreadsheet every Monday. Someone rekeys between two systems. Someone maintains a parallel record because the official one cannot hold something you need. Each is a small, permanent tax, and nobody adds them up.
The comparison nobody runs
When people compare, they compare the subscription with the build cost, which is the one comparison guaranteed to mislead. The subscription is visible and the build is a large number, so buying wins every time. The costs that decide it are on the other rows.
| Off-the-shelf | Custom build | |
|---|---|---|
| Up-front | Low. Subscription, setup, maybe configuration | High. The whole build is paid before anything runs |
| Ongoing licence | Per user, per month, usually rising with headcount and with the vendor's pricing decisions | None |
| Ongoing maintenance | Included, and genuinely valuable — security patches, browser changes, platform updates | Yours. Real, recurring, and frequently underestimated |
| Adaptation cost | Configuration, plus workarounds where configuration runs out | Low by definition, and it can drift as the business changes |
| Time to running | Days or weeks | Months |
| Fit | Good for the generic 80%, poor at the edges that make you different | As good as your understanding of the problem, and no better |
| Change later | Whatever the vendor allows, when they allow it | Whatever you are willing to pay for |
| Risk | Vendor raises prices, is acquired, deprecates the feature you depend on, or closes | You have to keep someone able to maintain it |
| Data | Theirs to store, yours to extract, sometimes awkwardly | Yours |
Two rows deserve emphasis because they are the ones that flip decisions.
Maintenance is not zero on a custom build. Software that nobody touches still decays: dependencies get security advisories, browsers change, the payment provider updates their integration, the operating system it runs on reaches end of life. Budgeting a build as a one-off purchase is how organisations end up with a critical system nobody can safely change.
Licence cost scales with your success. A per-seat price is cheap at eight users and a serious line item at 80. It is worth calculating what your subscription looks like at the headcount you are planning for, not the one you have. That single calculation moves more build-versus-buy decisions than any other.
The trap: "it does 90% of what we need"
This sentence has ended more budgets than any other in software procurement.
The trouble is that the missing 10% is never evenly distributed. It clusters in the part that is specific to you, which is usually the part that matters commercially, and it tends to be structural rather than cosmetic. So the project starts as a configuration exercise and becomes a customisation project, then an integration project, and eventually you are paying a specialist consultancy to maintain modifications to somebody else's product — which is the most expensive of all available positions. You now carry the cost of a custom build and the constraints of a bought one.
Before accepting a 90% fit, do two things. Name the 10% precisely, in terms of specific work that people do. Then ask what happens if you simply do not do it: change the process, accept the extra step, drop the feature. Often the answer is that it is fine, and the product is a good buy. Sometimes the answer is that the 10% is the business, at which point the product is not a 90% fit at all.
The answer that is usually right: both
Most sensible technology estates are mixed, and the mixing rule is simple. Buy the commodity, build the differentiator, and spend the effort on the join between them.
A distributor buys accounting, buys email, buys the helpdesk, and builds the thing that prices a complex order using rules nobody else has. A clinic buys the practice management system and builds the patient-facing part that its particular service depends on. In both cases the build is small, because it only has to do the part nothing else does, and it is cheaper to maintain for exactly the same reason.
This also gives the cheapest possible answer to "should we build". Reduce the build to whatever is genuinely unavailable, then check whether that remainder still justifies a project. Frequently it does not, and you have saved a year.
An illustrative example
A wholesaler with 40 staff runs quotations in a spreadsheet, because their pricing depends on customer contract terms, volume breaks and a freight calculation particular to their region. They evaluate three quoting products. All three handle volume breaks, none handles the contract logic, and each can be extended by a partner for a fee.
The build-versus-buy question here is not "spreadsheet or product". It is narrower: the products handle the generic parts of quoting perfectly well, and the contract logic is the part that is theirs. The strongest option is often to buy the product and build only the pricing rule as a small service the product calls, or to build only the quoting piece and let the bought system handle everything downstream of an accepted quote.
The example is hypothetical, and the shape recurs constantly. The right build is almost always smaller than the one first imagined.
Common questions
Is custom always more expensive? Over the first year, usually. Over five, it depends entirely on the workaround cost and the per-seat licence at your future headcount. Run both, honestly, over five years, including maintenance on the custom side. If custom only wins by assuming zero maintenance, it does not win.
What about no-code and low-code tools? They are a genuine third option and belong in the comparison. They are strongest for internal tools with modest logic and a handful of users. Two things to check before committing: what happens when your logic outgrows what the tool expresses, and how you would get your data and process out if the vendor's pricing changed. Those are the same two questions as for any bought product, asked earlier.
We already bought something and it is not working. Do we rebuild? Not immediately. Establish first whether it fails on fit or on implementation, because a badly configured good product looks identical to a bad product from the inside. Ask what the workarounds are actually for. If they exist to bridge a structural mismatch, the product is wrong. If they exist because nobody set it up properly or trained anyone, rebuilding will reproduce the problem in new software.
Does buying mean we own nothing? It means you own your data and nothing else, and the extraction terms matter more than most buyers check at signing. Before committing, find out how you would get a complete export, in what format, and whether the vendor charges for it.
The short version
- Buy is the correct default. For generic business functions, a subscription beats a build comfortably.
- Building is justified when the process is your advantage, when the mismatch is structural rather than cosmetic, when integration is the real problem, or when the workarounds now cost more than the licence.
- Compare total cost over five years, including maintenance on the custom side and the per-seat licence at the headcount you are planning for. Comparing subscription against build cost always favours buying, and is the wrong comparison.
- "It does 90% of what we need" is a warning. Name the 10% precisely and ask what happens if you go without it.
- The usual right answer is both: buy the commodity, build the small part that is genuinely yours.
Where to take this next
If the decision came out as build, the next question is what that costs and why estimates vary so widely for what sounds like the same work.
If you are still deciding what kind of thing this is at all, website, web application or custom software is the earlier decision, and what to work out before you ask anyone to build software covers what to establish first.
If you would like a second opinion on a build-versus-buy call you are in the middle of, describe it and we will tell you what we think — including when the answer is to buy something. Discuss your idea.
# Visual recommendations
Concepts only. Hairline drawing, ink and brass.
Hero visual — where the cost actually sits
Concept. Two stacked bars, unlabelled by amount. The buy bar is short at the top (subscription) with a long, lightly hatched extension labelled adaptation and workarounds. The build bar is long at the top (the build) with a short repeating segment labelled maintenance, repeated four times to represent years. The visual makes clear that the visible parts are the top segments and the deciding parts are underneath.
Purpose. The article's core correction is that the usual comparison omits the rows that decide it. The hero should show what is normally left out of the picture.
Alt text. Buying shows a small subscription above a large hidden cost of adaptation and workarounds. Building shows a large up-front cost above a smaller repeating maintenance cost each year.
Supporting visual — buy the commodity, build the difference
Concept. A horizontal band of six labelled blocks representing a company's systems: accounting, email, helpdesk, payroll, stock, and one block drawn in brass labelled the part that is yours. Below, thin connecting lines showing the brass block exchanging data with two of the bought ones.
Purpose. Makes the mixed answer concrete, and shows visually how small the justified build usually is.
Placement. In the "The answer that is usually right: both" section.
Alt text. Five bought systems alongside one small custom-built component that handles the process specific to the business, connected to two of them.