The build-versus-buy meeting is the most re-run meeting in a technology organization. Same conference room, a different project, and somehow the identical argument every quarter. An engineer says we could build this in two sprints and own it end to end. Someone else says we shouldn't reinvent the wheel when a vendor has already solved it. The room sorts itself by temperament, builders against buyers, and the decision goes to whoever argued with the most conviction that day. Then, a quarter or two later, a new project walks in and the whole thing runs again from the top.
It repeats because it was framed wrong. Build versus buy gets argued as an engineering question: which approach is more elegant, more controllable, more fun. It is a financing decision. You are choosing how to fund a capability across its entire life, and who carries the maintenance, the risk, and the eventual exit. Build finances the capability with your engineers' time now and a maintenance liability that never ends. Buy finances it with a recurring payment and a dependency you don't control. Those are two capital structures for the same asset. The technical merits are a small input to that sum, not the sum itself.
I should be precise about the chair I'm writing from. I don't sign the whole IT P&L. I run a real slice of it (security, DevOps, and the internal platform my team ships), and I report its return to a board. So I look at this call from the engineering side of the table, and the answer still has to hold up for people who think in capital rather than commits. The gap between those two languages is the actual problem. One caveat first: the accounting treatment of build versus buy, what capitalizes and what expenses, is a real and separate question that belongs to your CFO. I'm making the capital-allocation argument, not the accounting one.
Total cost is the whole life, not the sticker
The build column is almost always underpriced, because the expensive parts are invisible in the meeting where the decision gets made. The salary to write the first version is the cheap part, and it's the only part anyone estimates. The costs that dwarf it arrive later and quietly: the dependency upgrades, the security patching, the on-call rotation the moment it touches production, the documentation nobody wrote, and the second engineer you have to train so the first can take a vacation without the thing becoming unmaintainable. A tool you build is a tool you've adopted for life, and adoption has a payroll.
The buy column gets underpriced too, just differently. The sticker subscription hides the integration work, the renewal escalator that compounds every year, the seat creep as adoption spreads, and the professional-services line you'll sign in year two when you outgrow the default configuration. Neither column is honest at sticker price. The only fair comparison is fully loaded, over a horizon long enough to outlive the enthusiasm that started the project. Five years is a reasonable default: long enough to capture the maintenance tail on the build and the escalators on the buy, both in the same currency. Most build-versus-buy decisions that later look like mistakes were priced on year one alone.
Engineering time is the capital you're actually short of
Suppose you run the five-year numbers honestly and build still comes out cheaper. It can still be the wrong decision, because the salary was never the real cost. The real cost of building is the roadmap you didn't ship while you were building. Amazon has a durable phrase for this: "undifferentiated heavy lifting," the plumbing every company needs and no customer will ever reward you for. Every engineer-quarter you spend on undifferentiated heavy lifting is a quarter you did not spend on the one capability only your company can build.
In most technology organizations the binding constraint isn't money. It's engineering attention; there are almost always more good ideas than people to build them. That changes which resource you should be protecting. Buying spends the abundant resource, cash. Building spends the scarce one, attention. When you frame the decision as capital allocation, the question stops being "can we build this." Of course you can; that is the trap. The question becomes "is this the best possible use of the scarcest thing we have." For commodity capability, the honest answer is usually no.
Price the exit before you sign the entrance
Every option has an exit cost, and most teams only price it on one side of the ledger. Buy has an obvious switching cost: data portability, re-integration, retraining a team that learned the vendor's mental model. That risk is real and deserves its own line. The more of your workflow and your data that accumulate inside a platform, the more expensive leaving becomes, and vendors price renewals knowing exactly that. But build has an exit cost too, and it's the sneakier of the two. The internal tool that no one can bring themselves to kill, maintained by the single person who still understands it, is what shows up in every diligence review as key-person risk and technical liability.
So price the exit on both columns before you commit to either. Ask the same question of each option: what does it cost, in money and in months, to get out of this in three years? A rough number is enough to change the decision. The pattern to fear is the option that's cheap to enter and expensive to leave, because that asymmetry is invisible on the day you choose it and dominant on the day you want out. Cheap entrances are how both bad vendor contracts and unkillable internal tools get adopted.
Build only what makes you different
This is the axis that should carry the most weight, and it's the one engineers judge worst, because to an engineer everything is interesting to build. Two public frameworks sharpen the cut. Simon Wardley's mapping work separates the genesis, the genuinely novel thing that is a source of advantage, from the commodity everyone consumes the same way; build the genesis and rent the commodity. Gartner's pace-layered application model, as I understand it, makes a parallel distinction between systems of record, systems of differentiation, and systems of innovation, and argues you should govern and fund them differently. Both point at the same test: if a vendor sells this as a category with an analyst quadrant attached, it is probably not your differentiator, and building it is closer to vanity than to strategy.
We drew that line deliberately when my team built AgentOS, our governed internal agent platform. The model inference underneath is a commodity. We rent it through a single governed AWS Bedrock egress, and I'd treat the provider behind that egress as replaceable. The governance and control plane on top of it, the part that makes an agent safe to point at systems serving more than 1,500 financial institutions, was not something we could buy in the shape a regulated environment demanded. So we bought the commodity and built the differentiator, inside one system. That is exactly the split the decision is supposed to produce: rent what makes you the same as everyone else, build only what makes you different.
Write the rubric down once, so you argue it once
The meeting keeps repeating because the decision has no home. It lives in whoever was most persuasive in the room, which means it evaporates the moment they leave, and the next project starts the argument over from nothing. The fix is unglamorous and permanent: write the criteria and their weights down once, score each candidate decision against them, and keep the scored sheet. A weighted rubric turns a recurring debate into a recurring calculation. Here is the shape I use. The weights are illustrative; the point is that your organization tunes them once, in the calm, rather than per project in the heat.
- Strategic differentiation, highest weight. Does this capability make you distinguishable to a customer or an examiner, or is it table stakes everyone already has? Weight it heaviest and be ruthless, because this is the axis teams flatter themselves on.
- Total cost of ownership over five years. Both columns, fully loaded, same horizon, same currency, including the maintenance tail on build and the compounding escalators on buy.
- Opportunity cost of the engineering time. What does the build displace on the roadmap? Score a build worse when your engineers are the binding constraint, which is most of the time.
- Exit cost and lock-in, both columns. The money-and-months price of getting out in three years, scored for the vendor contract and the internal tool alike.
Give the rubric a version number and an owner, the same way you'd treat any other governing document. When someone wants to overturn a decision, they argue their score on a named criterion, not the entire philosophy. That is the whole benefit. You still have hard debates, but you have them about one number on one axis, and you have them once. The organization stops re-litigating build versus buy as a matter of taste, because taste is no longer the mechanism.
Before the next build-versus-buy meeting
Price both columns fully loaded over five years and never argue from the sticker. Weight differentiation highest, and be honest about whether this capability is genuinely yours to differentiate or just fun to own. Put an exit number on build and buy alike, because the cheap entrance with the expensive exit is the one that bites. And write the rubric down, version it, and give it an owner, so the argument happens once instead of every quarter. Build versus buy stops being a fight the loudest engineer wins and becomes what it always was: a financing decision the organization makes on purpose.