Brought to you by ExecReps.ai, AI-powered executive presence coaching for teams.
I have sat through build or buy meetings that ran entirely on architecture diagrams. Latency graphs, runtime comparisons, a schema drawn on the whiteboard, everyone fluent and engaged for forty minutes. Not one of those rooms opened by asking what the thing would cost to own in year three.
That question belongs to finance, and finance is rarely invited until the budget request arrives. By then the decision has been made in a language the budget holder does not speak.
"The hours our team spent identifying the upstream change, building a working relationship with the vendor's technical team, and reconstructing the integration spec were not in the original statement of work." Kevin Nguyen, writing in Product Coalition
The Room Where It Gets Decided
Abby Allen has spent a career running the large rebuilds most people only read about. She opens her Product Coalition piece with the one that went wrong, and she does not soften it. "At Google, I pushed the AdSense team to completely rewrite our home-grown CRM system. It was a disastrous mistake."
A CRM rewrite at Google, pushed by the person best placed to judge the engineering, and it still went wrong. That is the shape of the problem. The failure was not the code. It was who was in the room and what they were allowed to count.
Maret Kruve explains why the engineering number carries so much weight and deserves so little. "Technical estimates are often made in isolation from organisational context." An estimate answers whether a team can build the thing and roughly how long the first version takes. It says nothing about who runs it at two in the morning in 2029.
Teams I advise treat that estimate as the decision. It is one input, and the cheapest one to produce.
There is a second reason these meetings stay technical. The people who will carry the consequence are often not in them. Kevin Nguyen draws the line precisely when he describes an integration built by an offshore team against a vendor's spec. "The client product manager has political access to every system in their stack. They can call a vendor, escalate to an account manager, demand a roadmap. The offshore team building the integration has technical access only."
Authority and exposure sit in different places. Whoever chose the vendor can pick up the phone, and whoever has to make the thing work cannot.
The Costs That Never Reach the Slide
Lee Fischman writes for the executives who fund internal builds, and he starts with the cost that never appears on any invoice. "Delaying (the delivery of features while you build them) destroys value." Every month your team spends recreating something purchasable is a month your users spend without it.
His rule for funding decisions is one question, and it has teeth because of three words at the end. "Is an off-the-shelf alternative available at any price?" At any price forces the comparison to happen before somebody decides the licence looks expensive.
Kruve names the accounting failure underneath all of it. "They focus on direct costs while ignoring indirect costs and opportunity costs." Direct costs are the ones with invoices attached. Everything else gets absorbed by people who are already on payroll, which makes it look free.
Nathan Mckinley puts a shape on what owning infrastructure requires. "Cloud operations require a range of technology professionals, from cloud developers to administrators and network engineers, each of whom will add to the payroll." A decision to build is a decision to hire, and the hiring happens quietly, one backfill at a time.
Mike Ranellone describes the part of the bill that never stops arriving. "The issue of dev opportunity cost doesn't end at launch, either." He is precise about the duration. "That post-launch tail can pull at least some engineering resources away from other important projects indefinitely."
Indefinitely is the word that should end the debate. A build is not a project with an end date. It is a standing claim on capacity, renewed every sprint, for as long as the system runs.
The Bill Arrives on Both Sides
Buying is not the safe answer, and any piece that tells you otherwise is selling something.
The most quoted evidence on build risk comes from McKinsey, working with the University of Oxford. Michael Bloch, Sven Blumberg and Jürgen Laartz reported that "on average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted."
Be careful with that number. It was published in 2012, and large there means an initial price tag above fifteen million dollars. Your two-sprint integration is not that project. What the study earns is the direction of the error, which is always the same way, and never in your favour.
The same authors describe a purchase that went wrong in the opposite direction. "Another bank scored well on unit price with a software-package provider for the project phase of a trading-system implementation but encountered high costs for changes and support after the system was introduced and the bank was locked into the new technology."
A good unit price bought them a bad position. Once switching costs exceed the annual licence, the vendor sets the terms and the renewal conversation is theatre.
Kevin Nguyen shows how that lands on a delivery team. An upstream vendor changed an interface without telling anyone, and the hours spent working out why belonged to no budget line. "The project shipped three weeks behind the original deadline."
Three weeks is the visible cost. The coordination hours underneath it were paid for out of a software build budget, because that was the only budget available.
None of this makes buying the default answer. Building wins on commercial grounds more often than the sceptics allow, and the test is whether the capability is one your competitors could licence tomorrow. Own the thing your customers choose you for. Rent the plumbing that gets them to it.
The mistake is the shape of the argument rather than the answer it reaches. I have watched a team win the right to build and still lose, because they won it on capability and never priced the ownership they had just signed up for.
What I'm Hearing on the Podcast
Matthew Wensing spent two decades as a founder before becoming VP of Product and Design at Customer.io, a company that has crossed a hundred million dollars in annual recurring revenue. He was talking about AI-written code rather than vendors, and he landed on the principle the whole build or buy argument turns on.
"No different than shipping code to production that AI generated. You're responsible for the bugs. You're responsible for the maintenance. You're responsible for the quality of that work."
Ownership does not care where the code came from. It can come from your team, a model, or a vendor you fired last year, and the bugs still belong to whoever's name is on the system.
That is the real trade. Buying rents you somebody else's maintenance burden and charges you for the privilege. Building gives you the burden for free, then invoices you every month in engineering time you cannot spend on anything else.
So What Does This Mean for You?
Before the next architecture debate starts, write two numbers on the board. What the vendor costs over three years, including the integration work. What building costs over the same three years, including the people who will run it once the launch party is over.
Then ask Fischman's question out loud, with the three words on the end. If an off-the-shelf alternative exists at any price, the burden of proof sits with the build, and it is a commercial burden rather than a technical one.
The teams that win this argument stop arguing about capability. Of course your engineers can build it. That was never the question, and treating it as the question is how a decision about money ends up being made by whoever drew the best diagram.
So take the last thing your team chose to build. What has it cost to keep alive since launch, and who is still paying for it?
Got a product story worth telling? Whether you're an exceptional talent shaping the future of product, or you've got a career journey others can learn from, I want to hear from you. Apply to be a guest on the Product Coalition podcast.
👋 Jay
Product Coalition is a reader-supported publication. Paid subscribers get every issue on the day it lands.