Build versus buy,
answered properly.
Build versus buy is usually argued as a technology decision and settled on price. It is neither. The answer starts from where you actually differentiate, runs through the total cost of owning the thing for years, and turns on the integration work nobody puts in the quote.
It was never a technology decision
Build versus buy arrives dressed as an engineering question, so it gets answered by engineers, on the terms engineers can defend: architecture, effort, the elegance of the stack. That framing is how organisations end up building a customer portal that three vendors sell off the shelf, and buying a pricing engine that sits at the exact point where they beat their competitors.
The decision is a strategy decision wearing a technology costume. It is a question about where you want to own capability outright and where you are content to rent someone else’s. Answer it as a strategy question and the technology follows cleanly. Answer it as a technology question and you optimise the build while getting the boundary wrong.
The rest of this article is the sequence we use to keep that boundary honest: start from where you actually differentiate, cost the thing over its life rather than at purchase, and price the integration work before you commit to either path.
Build the difference, buy the rest
There is one line that decides most of this correctly, and it has nothing to do with technology. Build where you differentiate. Buy where you do not. The hard part is being honest about which parts of your business are actually a source of advantage and which only feel that way because you have always done them yourself.
Almost everything is a candidate to buy. Authentication, billing, content management, search, notifications, the analytics pipeline — these are solved problems, sold by companies whose entire business is keeping them solved. Building them yourself buys you a maintenance liability and no advantage, because your customers were never going to choose you for your login screen.
The narrow band that justifies a build is the capability your customers actually choose you for, the workflow that would be worse if it behaved like everyone else’s. Spend your engineering budget there, and only there.
Buy the commodity
If a category of vendor exists to sell it, and your version would look the same to a customer, buy it.
Build the differentiator
If it is a reason customers choose you, owning it outright is the point, not the overhead.
Be suspicious of “we’re different”
Most claimed uniqueness is habit. Test it: would a customer notice if this worked like the market standard.
Watch the drift
Yesterday’s differentiator becomes today’s commodity. Revisit the boundary; do not defend a build past its usefulness.
The price is not the cost
Both sides of the argument quote the wrong number. Buy gets compared on its licence fee and build on its delivery estimate, as though either figure is the thing you actually pay. Neither is. You pay to own a capability for as long as you run it, and that bill lands every year, not once.
Buying does not end at the subscription. It carries configuration, the specialist who knows the platform, the upgrade you cannot decline, the price rise at renewal once you are embedded, and the day you want your data back and discover what lock-in costs. Building does not end at launch. You now employ that software forever — patching it, staffing it, documenting it, and rebuilding the knowledge every time the person who understood it leaves.
Cost both paths over three to five years, with the boring lines included, and the comparison usually inverts. The cheap build is expensive to keep. The expensive licence is cheaper than the team you would need to replace it. You cannot see either until you count past the purchase.
Buy hides its cost in renewals, seat expansion, mandatory upgrades, and the exit you have not priced.
Build hides its cost in maintenance, on-call, and the key-person risk of the one engineer who understands it.
The right number for both is the multi-year run cost, not the sticker — and the year-one figure is the least informative one you have.
The line nobody puts in the quote
Whichever way the decision goes, the thing you chose has to talk to everything you already run — your identity, your data warehouse, your finance system, your existing products. That connective work is where build-versus-buy estimates quietly go wrong, because it belongs to neither the licence nor the build estimate, so nobody quotes for it and everybody assumes it away.
Buying does not remove the integration; it relocates it. The platform is bought, but wiring it into your identity model, reconciling its data with your warehouse, and keeping both in step through every future upgrade is now permanent work you own. A tool that is 90 per cent right off the shelf can cost more in the last ten per cent of fit than a smaller build would have cost outright.
We treat integration as a first-class line in the decision, estimated before commitment rather than discovered after. It is also the part of the work that most rewards being planned deliberately — the case we make in a companion piece on the integration work nobody quotes for.
Identity and access
Every new system has to fit your authentication, roles and permissions — rarely a checkbox, never free.
Data and reconciliation
Its data must agree with your warehouse and your other systems, and keep agreeing as both change.
The upgrade treadmill
Integrations are not built once. They are maintained through every version on both sides, indefinitely.
The last ten per cent
The final stretch of fit — the edge cases and exceptions — routinely costs more than the first ninety.
Four questions, in this order
Asked in sequence, four questions settle most of these decisions without a spreadsheet war. Order matters: differentiation first, because it decides whether the other three are even worth asking. If it is not a differentiator, buy it, and skip to how well it integrates.
What this framework is really doing is refusing to let the loudest input — usually the delivery estimate or the licence fee — answer the question on its own. Each question checks the previous one, and the decision that survives all four tends to survive contact with the second year.
1. Is it a differentiator?
Would customers notice if it worked like the market standard. If no, buy. Do not romanticise the build.
2. What does it cost to own?
Count both paths over three to five years, run cost included — not the purchase price or the estimate.
3. What does it cost to integrate?
Price the identity, data and upgrade work explicitly, on whichever side you are leaning, before you commit.
4. Who owns it on day 400?
Name the team that maintains it long after launch. If you cannot, you have not finished the decision.
Before the next vendor demo
You do not need a procurement overhaul or an architecture review board to get this right. You need to move the conversation off price and effort and onto differentiation, ownership and integration — and to do it before anyone has fallen in love with a demo or a design.
If a build-versus-buy call is in front of you this quarter, three things are worth doing now.
Write one honest sentence on whether the capability is a differentiator — and be willing for the answer to be no.
Cost both paths over five years with the boring lines in, so you are comparing ownership rather than purchase.
Put a number on the integration work before you commit, not after the contract is signed.
This is the sequence our Technology & Product engagements are built around: decide where you differentiate, cost the ownership honestly, price the integration first, and name who holds the thing once the launch is over.
Explore Technology & ProductLeads our technology and product practice across India, Dubai and the US, advising on platform decisions and the architecture that follows them. Spends most of his time on the unglamorous parts — total cost of ownership and the integration work that decides whether a decision ages well.
See all articles by this author
