Why I am writing about this
The first time I had to make a build vs buy decision, I didn't even realize I was making one.
I didn't know buying software off the shelf was on the table. I skipped the whole exercise and went straight into building, because I thought that's what was expected of me.
A year later, new product leadership reviewed the whole portfolio to see what still deserved a place in it.
Our custom, ever-growing product stood out.
Someone asked me: "Why don't we just buy something that already exists?"
I was stumped. It had genuinely never crossed my mind.
So I teamed up with our platform and architecture experts to look at what was actually available in the market, and made an unbiased assessment. That's when I finally learned what it takes to make a build vs buy call.
Here's the thing though: missing my window to evaluate build vs buy before we started did not make it a failure.
This decision can be reassessed at different points in a product's life: before you start, after the pilot, or after it's been running for a while.
Steps to make a build vs buy decision
I like to keep things simple. This process doesn't need to be overcomplicated. Here are the steps:
- Understand core competency
- Define product requirements
- Assemble the assessment team
- Vendor outreach
- Product assessment (POC, TCO, ROI)
- Vendor assessment
- Results review and recommendation
As always, let's take an example to make this concrete.
Say you own a current finance tool that lets your marketing team plan budgets. The tool was built custom, in-house.
Your users want a new capability: not just forecasting budgets, but seeing actual spend updated live.
Since this expands on the original forecasting scope, you're wondering if there's an off the shelf product that already does this. If there is, you'd just need to buy and integrate it, without building anything new with your team.
1. Understand core competency
Before you look at any product or vendor, ask a more basic question: is this capability part of your company's competitive advantage?
A simple way to think about this is the core vs context framework. Core activities are the ones that differentiate you and directly drive competitive advantage. They deserve sustained investment, including building in-house. Context activities are necessary for the business to run, but customers don't choose you because of them.
Ask yourself:
- Does this make our company unique, or does it just need to work?
- Would customers notice or care if we built this ourselves vs bought it?
- Is this something competitors would build to compete with us, or something they'd just buy too?
If the answer points to core, build has a strong case. If it points to context, buy already has a bias in its favor, before you've even looked at a single vendor.
For the finance tool example: live spend tracking is important, but it's not what makes your company competitive in the market. That's context, not core. Buy starts with an edge here.
2. Define product requirements
Before you can compare build vs buy, you need to know what "good" looks like.
Separate your must haves from your nice to haves. Vendors will try to sell you on the nice to haves. Don't let them distract you from the must haves.
Example, for the finance tool:
Must haves: real-time sync with actual spend data, budget vs actual reporting by department, existing forecasting features preserved, single sign-on with our identity provider
Nice to haves: mobile app access, custom dashboards, AI-generated variance explanations
3. Assemble the assessment team
This isn't a decision to make alone in a corner with a spreadsheet.
The team needs to be cross-functional. Buying doesn't just touch functional and technical requirements. It also touches finance, procurement, security, and compliance. Each of them has requirements the vendor needs to meet, and each can be involved at different stages of the assessment.
Bring in the people who'll catch what you'd miss on your own:
- Platform or architecture experts, to assess technical fit and integration risk
- Finance stakeholders, to validate the requirements actually solve their problem
- Procurement or legal, if a vendor contract is realistically on the table
Example, for the finance tool:
a platform architect to assess integration with the existing forecasting system, the marketing finance lead who owns budget reporting today, and procurement to handle vendor contracting once a finalist is chosen.
4. Vendor outreach
Identify vendors that could realistically meet your requirements, and reach out for demos or trial access.
Don't just shortlist the two names everyone already knows. Give yourself a real comparison.
Example, for the finance tool: reach out to three budgeting and forecasting platforms that advertise live spend integration, and request sandbox access from each so your team can test against your actual requirements list, not just a sales demo.
5. Product assessment (POC, TCO, ROI)
This is where the real work happens. And what you need to do comes down to three acronyms:
POC, proof of concept. TCO, total cost of ownership. ROI, return on investment.
Run a proof of concept with your top vendor options. Then compare that against what building in-house would actually cost, not just to build, but to run for years afterward.
What to look at:
- POC results: does the vendor's product actually do what your requirements say, or close enough with configuration? Is it flexible enough? Does it cover 80 to 90% of what you need, and can you live without the rest?
- TCO: build a TCO calculation for both the buy and build alternatives, and compare apples to apples. Every option carries hidden costs. When you buy, you're not just paying for the license. Factor in implementation, support, infrastructure, integration effort, and the switching cost if the vendor stops being the right fit down the line. You're also taking on some dependence on the vendor's own roadmap and pricing decisions. When you build, you're taking on the ongoing cost of maintenance, upgrades, and the internal team hours needed to keep it running, long after the build is "done." We covered this in more detail in an earlier newsletter, including a TCO template: My Product Almost Got Killed. One Number Saved It
- ROI: what value does this unlock (time saved, risk reduced, revenue protected) against what it costs?
Example, for the finance tool:
the POC shows real-time spend sync and working out of the box on BudgetFlow, the strongest vendor in your sandbox testing, but approval workflows need custom configuration, that's your 10%.
TCO over 3 years lands at roughly $180,000 for BudgetFlow (license, implementation, and integration included) vs an estimated $340,000 to build and maintain the same capability in-house.
ROI shows finance saving around 15 hours a month once manual reconciliation goes away, plus fewer month-end reporting errors.
6. Vendor assessment
Technical fit is only half the picture. The vendor itself needs scrutiny.
- Stability: how long has this vendor been around, and are they likely to still exist in 3 years?
- Support: what does their SLA actually guarantee?
- Roadmap: does their product direction match where you're heading?
- Security: does it meet your organization's requirements, not just the vendor's marketing page?
- Sustainability: is their business model financially healthy, or are they burning cash with no clear path to profitability?
- Vendor reputation: what do their existing customers and independent reviews say, beyond the case studies on their own website?
Example, for the finance tool:
BudgetFlow has been in the market for 8 years and is backed by a profitably run parent company.
Their SLA guarantees 99.9% uptime with a dedicated support line for enterprise customers. Their roadmap already includes deeper ERP integrations planned for next year, which lines up with where your own systems are heading.
Reference calls with two existing customers came back positive, with no major complaints beyond a slower-than-expected onboarding.
7. Results review and recommendation
Bring your findings back to the team and make the call.
Document the reasoning, not just the decision. You or someone else will need to revisit this in a year or two, and "we just felt like it" won't hold up in that conversation.
Example, for the finance tool:
recommend buying BudgetFlow, since live spend tracking is context, not core, and both the TCO and ROI favor buying over a multi-quarter build. Flag the approval workflow gap as a short configuration effort post-purchase, not a reason to reconsider.
