Build vs. Buy: A Decision Framework for Product Managers

Vantly, a 90-person property-management SaaS company, spent seven months and roughly $340,000 in engineering time building an in-house notification system: SMS, email, and push, unified under one internal service. Support tickets tagged “notifications broken” had been climbing for a quarter, and the team believed building would be faster than negotiating a vendor contract and living with someone else’s rate limits. Fourteen months later, they ripped it out and replaced it with a combination of Twilio and Customer.io, because maintaining deliverability across three carriers and two email providers had quietly become a full-time job for one and a half engineers — engineers who were supposed to be building the actual product. It’s the kind of build vs. buy call product managers get wrong constantly, and rarely for the reason they think.

The build vs. buy debates that go worst are almost always the ones framed as a spreadsheet exercise: engineering-hours-to-build versus annual-license-cost, decide, move on. That framing misses the actual question. Build vs. buy for product managers is a strategy decision wearing a cost decision’s clothes, and getting it backwards is how teams end up rebuilding Vantly’s notification system twice.

Why Build vs. Buy Is a Strategy Question, Not a Cost Question

The advice you’ll hear most often is some version of “buy commodity, build differentiation,” and it’s usually right. If a capability doesn’t touch what makes your product different to a customer, buying it frees your team to spend engineering time on the thing that does. If it is the differentiator, owning it gives you the freedom to shape it exactly to your product, rather than waiting on a vendor’s roadmap to catch up to a feature you need this quarter.

Where that advice breaks down is in the middle, where most real decisions actually sit. A notification system isn’t your differentiator, but reliable delivery absolutely affects retention. A search feature isn’t your core product, but a bad one drives real churn. This is where a clear product principles document earns its keep: not by giving you a mechanical rule, but by forcing the team to say in advance what “differentiator” actually means for your product, so you’re not re-litigating the definition every time a build vs. buy question comes up. Marty Cagan makes a version of this argument from the engineering side: outsourcing a genuine core competency, even when it looks cheaper in the short run, tends to leave a product organization dependent on outside teams for the very thing that was supposed to set it apart.

The Real Cost of Building: What Product Managers Underestimate

Build estimates consistently understate one thing: the maintenance tail. The Vantly team’s $340,000 figure was the build cost. It didn’t include the ongoing cost of keeping up with carrier API changes, monitoring deliverability rates across providers, and handling the edge cases that only show up at volume — the actual reason they eventually walked away from it. This isn’t a Vantly-specific problem: a widely cited Harvard Business Review analysis of nearly 1,500 IT projects found an average cost overrun of 27%, with one in six projects blowing past budget by 200% and slipping schedule by almost 70%, and a CIO.com piece citing Forrester research puts it even more starkly for this specific decision: 67% of software project failures trace back to the build-or-buy call itself, not execution quality afterward. Products That Count frames this well: it isn’t really build vs. buy, it’s build-and-maintain vs. buy, and most teams only budget for the first half of that phrase.

This is the same dynamic that shows up in how teams talk about managing technical debt: a build decision isn’t a single expense, it’s the first payment in a recurring bill that comes due for as long as the system exists. If a proposed build can’t survive the question “who owns this in three years, and what happens when they leave,” it’s not ready to be a build decision yet. Teams that skip this question are the ones who discover, a year in, that the system works but nobody left on the team fully understands why.

AI-assisted development has genuinely shifted part of this equation, and it’s worth being precise about which part. Tools like Cursor, Claude Code, and GitHub Copilot have made a specific category of build faster and cheaper: narrow internal dashboards, integration glue between two systems, admin tooling that used to eat a sprint and now takes a couple of days. That’s real, and it’s shifted a slice of build vs. buy decisions toward build that wouldn’t have made sense two years ago. What it hasn’t changed is the maintenance tail. AI tools write the first version faster; they don’t monitor carrier deliverability rates at 2 a.m., patch a security issue in a dependency six months from now, or onboard the next engineer who has to maintain code they didn’t write. Teams that treat faster initial development as proof the whole cost curve has flattened are making the same mistake as the Vantly team, just with a shorter runway before it shows up.

The build side also tends to underweight opportunity cost. Every engineer-quarter spent on a notification service is a quarter not spent on the feature that was actually supposed to move the roadmap. A build case that only compares to license cost, without pricing in what the same engineers would have shipped instead, isn’t a real comparison — it’s a partial one that happens to favor building.

When Buying Is the Wrong Call for Product Managers

Buying isn’t automatically the safe choice either, and treating it that way is its own failure mode. Three situations make buying the worse call even when it looks cheaper on paper:

The capability is genuinely close to your core differentiator, and a vendor’s roadmap will never move at the pace your product needs. If you’re building a developer-facing product where API product management practices are core to how customers experience you, outsourcing your API gateway to a generic vendor tool often means shipping on someone else’s timeline for something customers judge you on directly.

Your data residency, compliance, or latency requirements are unusual enough that no vendor’s standard contract covers them, and the “enterprise tier” workaround costs more over three years than building would have.

The vendor’s pricing model doesn’t match how your product scales. Per-seat or per-event pricing that looks reasonable in a demo can turn into a real cost problem within two years, sometimes scaling into the ten-to-fifteen-times range as usage compounds — a jump few procurement teams model at signing, and no one runs that three-year projection until the renewal invoice arrives. Anyone who has written a pricing strategy document for their own product will recognize this pattern immediately, because it’s the same mechanism in reverse: the model that looks generous at low volume is often designed to become expensive at the volume the vendor expects the account to reach.

A Build vs. Buy Decision Framework You Can Actually Use

Rather than a single yes/no test, run the decision through four questions in order, and stop as soon as one gives you a clear answer.

Does this capability define your competitive edge with customers? If yes, lean build. If it’s genuinely commodity — authentication, payments infrastructure, basic analytics — lean buy and move on quickly.

What does three years of ownership actually cost, not one year of build? Price the build against three years of maintenance, not the initial sprint estimate, and price the buy against three years of the vendor’s realistic renewal trajectory, not the intro-tier quote.

Can you get 80% of the value from a vendor and build only the remaining 20% that’s actually differentiated? This middle path gets ignored more than it should. Buying the commodity infrastructure and building a thin, differentiated layer on top of it is often better than either pure option.

Who evaluated the actual alternatives, and how? A rushed buy decision based on one vendor demo is nearly as risky as a rushed build decision based on one engineer’s gut estimate. Running a real competitive analysis across three or four vendors, not just the one whose salesperson called first, is what separates a defensible decision from a guess with a contract attached.

Build vs. Buy: Quick Reference

Question	Leans build	Leans buy
Is this your core differentiator?	Yes	No
Does a vendor’s roadmap move fast enough for your needs?	No	Yes
Do you have unusual compliance or data residency needs?	Yes	No
Does the total 3-year cost favor ownership?	Yes	No
Do you have engineering capacity to maintain it long-term?	Yes	No

What Happens When a Build vs. Buy Call Goes Wrong

Two failure modes account for most of build vs. buy regret, and they run in opposite directions.

The first is the build that never really finishes. Someone pitches an in-house version of something buyable, scope creeps as edge cases surface, and eighteen months later the team has an 80%-functional internal tool that nobody has time to finish the last 20% of, and switching to a vendor now feels like admitting the sunk cost was wasted, so it doesn’t happen. The system limps along half-built indefinitely, doing enough to make replacing it feel unnecessary and too little to make keeping it feel comfortable, and every quarterly planning cycle it gets deprioritized again because there’s always something more urgent than finishing a tool that mostly works.

The second is vendor lock-in with a renewal cliff. A tool gets adopted at a reasonable price when the company is small, workflows and integrations get built around it for two years, and then a renewal comes in at three times the original price because switching costs are now high enough that the vendor knows the team won’t leave. This is the scenario every build vs. buy framework warns about in theory, and the one teams still walk into in practice, because the pain shows up two renewal cycles after the decision that caused it, long after the person who made the call has moved to a different team.

Recovering from either requires the same unpleasant step: building a real business case for the product investment required to fix it, with the actual three-year cost comparison the original decision skipped, and taking it to leadership as a correction rather than pretending it was the plan all along.

How One Team Actually Made the Call

Back to Vantly. The disagreement that mattered wasn’t build vs. buy in the abstract — it was between the engineering lead, who wanted to keep improving the in-house notification system because “we already built most of it,” and the PM, who argued that sunk cost wasn’t a reason to keep paying the maintenance tax. The team ran the four-question framework above: notifications weren’t the differentiator, the vendor landscape had matured significantly since the original build decision two years earlier, and a real three-year cost projection showed the in-house system costing more in engineering time than Twilio and Customer.io combined, even accounting for the sunk build cost as a loss. They shortlisted three vendors instead of going with the one the engineering lead had already used at a previous job, scored each on deliverability track record, API stability, and total cost at their projected two-year volume, and only then brought a recommendation to leadership.

The migration took six weeks. Deliverability complaints dropped by roughly 60% in the following quarter, and the 1.5 engineers who had been maintaining the notification service went back to product work. The lesson the team took away wasn’t “always buy.” It was that they’d never actually re-run the decision after the original build, and a capability that was the right call to build two years earlier had quietly become the wrong one to keep, simply because the vendor market had changed underneath them.

Should You Build This, or Buy It?

Run the four questions before you run the numbers, because the numbers will almost always tell you whatever story your existing assumptions already believe going in. Vantly’s mistake was never the initial build decision — the vendor landscape at the time genuinely justified it. The mistake was letting that decision calcify into a permanent assumption, never re-examined as the market underneath it changed. A build vs. buy call is a snapshot of conditions at one point in time, not a verdict that ages with the product.

References

• Harvard Business Review — Bent Flyvbjerg and Alexander Budzier, “Why Your IT Project May Be Riskier Than You Think” (https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think)
• Silicon Valley Product Group — Marty Cagan, “Outsourcing Core Competencies” (https://www.svpg.com/outsourcing-core-competencies/)
• Products That Count — “Build vs. Buy: A Product Manager’s Guide to Not Building Things” (https://productsthatcount.com/build-vs-buy-a-product-manager-s-guide-to-not-building-things/)
• CIO — “Build vs. buy: A CIO’s journey through the software decision maze” (https://www.cio.com/article/4056428/build-vs-buy-a-cios-journey-through-the-software-decision-maze.html)