Every growing business hits the moment where a tool no longer fits, and the question arrives: do we buy something off the shelf, or build our own? It is one of the most consequential decisions a company makes about its software, and it is routinely made on instinct. Engineers lean toward building because building is what they do; executives lean toward buying because a licence looks cheaper than a project. Both instincts are wrong as often as they are right, because the real question is not which is cheaper to start, but which is worth owning for years.
Custom software is a commitment, not a purchase
The most common mistake in a build-versus-buy decision is comparing the build quote to the licence fee. That comparison is almost meaningless, because the two things are not the same kind of cost. A licence is a subscription to something someone else maintains, secures, updates, and improves. A custom build is a permanent commitment to do all of that yourself, forever, for as long as the software is used.
When you buy, the vendor spreads the cost of maintenance, security patching, compliance, and new features across every customer they have. When you build, you carry that entire load alone. The initial build is the smallest and most visible part of the cost. The invisible part, the years of ownership that follow, is where build-versus-buy decisions are actually won or lost, and it is the part most likely to be ignored in the moment of deciding.
When buying is the right answer
For most of what a business runs on, buying is not just cheaper, it is better. Payroll, accounting, email, standard customer relationship management, help desks, the market has already solved these problems thoroughly, with products refined over years across thousands of customers. Building your own version means spending heavily to recreate something you could license for a fraction of the cost, and then maintaining it forever, in exchange for almost no advantage.
The test is whether the capability is a commodity or a differentiator. If it is something every business in your industry needs and does roughly the same way, it is a commodity, and commodities should be bought. Nobody wins by having a slightly different in-house accounting system. Spending your scarce engineering capacity rebuilding solved problems is how you end up with a large maintenance burden and nothing distinctive to show for it.
When building genuinely wins
Custom earns its place in a narrow but important set of cases. The clearest is when the software supports a genuine differentiator, something your customers value that competitors cannot easily copy, and no product on the market captures it. If the way you fulfil orders, price your work, or run your core operation is a real edge, bending it to fit a generic product can quietly hand that edge away. There, a focused custom build protects what makes you distinctive.
Building also wins when the fit is simply too poor to buy. Sometimes the available products are so misaligned with how you operate that adopting one would mean heavy customisation, a tangle of workarounds, and integrations to paper over the gaps, until the total cost and fragility of the bought solution exceeds what a purpose-built one would have cost. And occasionally a critical need sits entirely outside what any product covers, and there is nothing to buy. In these cases, custom is not indulgence, it is the cheaper and more reliable answer.
The question that actually decides it
Strip away the instincts and the decision comes down to one honest question asked twice. First: is this capability a differentiator or a commodity? Commodities are bought; differentiators can be built. Second: what is the full lifetime cost of each option, not the upfront price, but the years of ownership, maintenance, and change that follow? Compare those two lifetime costs, not the project quote against the licence fee, and the right answer usually becomes clear.
Most businesses should buy more than they build, reserving their custom effort for the few places where it defends a real advantage. The failures come from the extremes: building everything, and drowning in the maintenance of reinvented commodities; or buying everything, and slowly grinding down the very processes that made the business distinctive. The discipline is knowing which is which, and deciding deliberately.
A worked example
A logistics company was about to build a full custom platform to run its business, on the reasoning that its operation was unique. Working through it capability by capability told a more useful story. Most of what they did, invoicing, accounting, standard fleet tracking, communications, was entirely standard, and building it would have meant years of maintaining commodity software for no advantage. But one thing genuinely was distinctive: the way they optimised multi-stop routes against a set of constraints no product handled well, and which customers chose them for. We bought everything else off the shelf and built only the routing engine, integrating it with the purchased systems. They got their differentiator as custom software, avoided owning a mountain of commodity code, and spent a fraction of what the all-custom platform would have cost to build and maintain.
Build the edge, buy the rest
Build or buy is not a question of principle, it is a question of where custom software earns its lifetime cost. Buy the commodities, because the market maintains them better and cheaper than you ever could. Build the differentiators, because those are worth owning and worth defending. And in every case, decide on the full cost of ownership rather than the upfront price, because the cheapest thing to start is rarely the cheapest thing to live with. Get that discipline right and your engineering effort goes where it actually creates advantage, instead of into maintaining software you should have simply bought.
If you are weighing a custom build against an off-the-shelf product and want the decision made on lifetime cost and real advantage rather than instinct, that is worth getting right before the budget is committed. Our team builds custom platforms and applications precisely where custom earns its keep, and will tell you honestly when it does not. Book a discovery call and we will help you draw the line.
Frequently asked questions
Should we build custom software or buy off-the-shelf?
Buy off-the-shelf for anything that is not a source of competitive advantage, where a mature product already does the job well, and building would only recreate what you can license. Build custom when the process is genuinely a differentiator, when no product fits without heavy compromise, or when the work is so specific to how you operate that adapting to a product would cost more than building. The default should be buy, with custom reserved for where it truly earns its lifetime cost.
What is the real cost of building custom software?
The build is the smallest part. Custom software is a permanent commitment to maintain, secure, update, document, and evolve the system for as long as it is used, work that an off-the-shelf vendor otherwise absorbs across all their customers. When comparing build to buy, weigh the lifetime cost of ownership, not just the project quote, because that ongoing cost is where most build-versus-buy decisions are actually won or lost.
When is off-the-shelf software the wrong choice?
When the product would force you to change a process that is a genuine competitive advantage, when it fits so poorly that you would spend heavily on customisation and workarounds anyway, or when critical needs sit outside what any available product covers. In those cases the apparent savings of buying are eaten by compromise and integration, and a focused custom build can be the cheaper and better answer.
How do you decide between building and buying?
Ask whether the capability is a differentiator or a commodity. Commodities, payroll, accounting, email, standard CRM, are almost always better bought, because the market has already solved them well. Differentiators, the things customers value that competitors cannot easily copy, can justify a custom build. Then compare the full lifetime cost of each option, not the upfront price, and choose deliberately rather than by instinct.