The Build vs. Buy Decision Nobody Wants to Make
Comparing license cost to salary is not an analysis. It is a shortcut that costs you later.
A team I coached bought a vendor tool for case management because the annual license cost less than one engineer's salary. The math seemed obvious. Why build something you can buy for $80K a year?
Six months later, three engineers had spent four months building a custom integration layer. The vendor's API did not support a critical workflow. The data model did not match the domain. The team was maintaining both the vendor product and their own code on top of it. The total cost had already exceeded what building from scratch would have cost, and they were locked into a multi-year contract.
This is the most expensive version of build vs. buy: buy, discover it does not fit, build on top of it anyway, and now maintain both. I have seen this pattern at three different organizations. It happens because the initial evaluation was not an evaluation. It was a cost comparison on one dimension.
Why this decision is so hard
Build vs. buy sits at the intersection of product strategy, engineering architecture, and budget. Nobody owns it cleanly.
Engineers default to building. They want to solve the problem. They trust their own code more than a vendor's black box. They see integration complexity that product and procurement do not.
Procurement defaults to buying. They want to control cost and avoid custom development risk. They see license fees and vendor SLAs but not the integration effort hiding behind them.
PMs get caught in the middle. They own the business case but rely on engineering for technical assessment and procurement for budget approval. When these perspectives do not align, the decision stalls or gets made by whoever pushes hardest.
The fix is product-engineering pairing on the evaluation itself. Not engineering evaluating alone and presenting a recommendation. Not PM picking a vendor and asking engineering to integrate it. Both disciplines in the room, working through the same framework, before anyone commits.
The evaluation that actually works
The product-engineering pairing playbook includes a six-criterion framework for build vs. buy. The two criteria that teams most commonly get wrong:
Total cost on a two-year horizon. Not license cost vs. salary. Total cost includes: engineering time for integration and customization, ongoing maintenance of the integration layer, infrastructure costs, vendor price escalation after the initial contract, and switching cost if you need to move off the vendor later. That $80K license often becomes $400K when you account for everything around it.
The team I described earlier did not factor in integration effort, ongoing maintenance of their custom layer, or the cost of working around API limitations every time they needed a new feature. Each of those line items was individually small. Together they dwarfed the license fee.
Strategic alignment. Is this capability a core differentiator for your product, or is it commodity infrastructure? If it differentiates you, own it. If every competitor has the same need and the vendor solution is mature, buy it.
Authentication is almost always a buy. Your product's unique value proposition is almost always a build. The gray area is everything in between, and that is where the conversation matters most. A PM who understands the product strategy and an engineer who understands the technical trade-offs, evaluating together, will land in the right place more often than either discipline deciding alone.
The other four criteria
Time to market. A vendor solution ships faster if it fits your needs. It ships slower if you discover during integration that it does not. Time-box a technical spike before committing: can the vendor solution actually do what you need, or are you buying the promise of what it could do?
Control and customization. How much does your use case diverge from the vendor's default workflow? Small divergence means the vendor handles the hard parts and you configure. Large divergence means you are fighting the tool more than using it.
Maintenance burden. With build, your team owns everything. With buy, the vendor handles the core product but your team maintains the integration. Integrations are deceptively expensive to maintain because they break every time the vendor updates their API, and you do not control the update schedule.
Risk. Build risk is building the wrong thing or taking too long. Buy risk is vendor lock-in, price changes, and the vendor sunsetting the product. Neither risk profile is inherently better. But build risk is within your control. Buy risk is not.
The "buy then rebuild" trap
The most expensive outcome is not "we built when we should have bought." It is "we bought, customized until the vendor product was unrecognizable, and now we maintain both our custom layer and the vendor dependency."
This trap has a consistent pattern. The initial evaluation compares license cost to build cost and buy wins. The team integrates and discovers gaps. Small workarounds accumulate. Each workaround is individually justified. After a year, the custom code on top of the vendor tool is more complex than a purpose-built solution would have been. But switching cost is now high enough that nobody wants to start over.
The prevention is simple: set a review trigger at adoption time. "If we spend more than X engineering days on workarounds in the first quarter, we re-evaluate." "If the vendor raises prices above Y, we re-evaluate." "If integration complexity exceeds our spike estimate by more than 50%, we re-evaluate." When a balanced team sets these triggers together, they catch the trajectory before it compounds.
Who should be in the room
Build vs. buy decisions made by one discipline alone produce worse outcomes. Engineering choosing the tool optimizes for technical elegance. PM choosing the vendor optimizes for speed and cost. Procurement choosing the contract optimizes for risk management. None of these perspectives is complete on its own.
The minimum viable decision group: a PM who understands the product strategy and business constraints, and an engineer who can evaluate technical fit and estimate integration effort. If the delivery diagnostics show declining velocity, and the team suspects accumulated vendor workarounds are a factor, that is a signal to revisit the buy decision with fresh eyes.
The decision is uncomfortable because it requires honesty about what you do not know. The engineer does not know the full budget picture. The PM does not know the full integration complexity. Pairing makes both perspectives visible before the commitment, not after.
For the complete build-vs-buy evaluation framework and guidance on product-engineering decision-making, see the product-engineering pairing playbook. If your team is stuck on a build-vs-buy decision that keeps stalling, let's talk.