The most common framing of build vs buy is that buy outsources the operational burden to the vendor and build keeps it in-house. That framing is too clean. The vendor takes some of the operational burden, but a meaningful portion stays on your side of the line, and the spreadsheets that compare build to buy tend to undercount it.
This piece is about which operational responsibilities actually transfer when you buy a SaaS tool, which ones stay in-house regardless, and what that means for the cost analysis.
Photo by Startup Stock Photos on Pexels
What the vendor actually owns
Vendor SLAs describe what the vendor commits to. They typically include core service uptime, response time on incidents, and time to resolution by severity. The vendor's engineering team handles the underlying infrastructure, the application code they wrote, and the security perimeter around their service.
That is real value. The Wikipedia article on service level agreement walks through the typical structure. The vendor's investment in keeping the core service up exceeds what most internal teams could match for the equivalent dollars; that is the legitimate efficiency argument for buying.
But that is also where vendor responsibility usually ends. The integration between the vendor's service and your systems is your team's problem. The data quality on your side of the integration is your team's problem. The user experience inside your company is your team's problem. The decisions about which features to use and which to ignore are your team's problem.
What stays on your side regardless
Five operational responsibilities survive the buy decision, and they often surprise the people who made the decision.
Integration code maintenance. SSO configuration, data feeds, webhook handlers, custom field mappings, audit log integrations. All of this lives in your code base. When the vendor changes an API, your team adapts. When your internal system changes, your team adapts. When the integration breaks at 3 AM, your team is on call.
This is the largest underestimated line item in most buy-side cost analyses. Budget 15 to 25 percent of the original integration cost per year as ongoing maintenance. For non-trivial integrations, that number can be larger than the vendor's annual subscription.
Data quality and reconciliation. A vendor tool that ingests data from your systems is only as good as the data flowing in. Schema drift, late-arriving records, format changes, deduplication, and reconciliation against authoritative sources are all your responsibility. The vendor will not call you to say "your data feed dropped 3 percent of records last Tuesday." That detection is on your side.
User support inside your company. When the marketing team needs to know why a campaign report shows different numbers in two places, the vendor's support team is not the right place to escalate. The right place is an internal owner who understands both the vendor tool and the context. That role exists; it does not disappear with the buy decision. The Project Management Institute frameworks treat this as "business process ownership" and assign it explicitly during procurement.
Vendor relationship management. Quarterly reviews with the vendor, feature request submission and tracking, escalation when SLAs slip, contract renewal preparation. Someone on your team owns the vendor relationship. That ownership has real time cost; the more strategic the vendor, the more time it consumes.
Roadmap alignment. You are betting that the vendor's roadmap stays close enough to your needs for the duration of the contract. That bet has to be re-evaluated periodically. Someone on your team watches the vendor's releases, attends the vendor's roadmap webinars, and flags drift early. Without this, vendor drift catches the team by surprise at renewal.
The cost shape of all-of-the-above
Rolled up, these five lines typically add 30 to 70 percent on top of the vendor's annual subscription as internal operational cost. A $80,000 per year SaaS subscription often costs the buying organization $25,000 to $55,000 per year in internal time and integration maintenance. The combined total is the line that should be compared to the build alternative.
The build alternative has its own operational line, and it is larger. But it is not 100 percent larger in many cases, because some of the operational responsibilities (data quality, user support, business process ownership) survive regardless. The honest comparison is build's incremental operational cost (engineering on-call, internal development, ongoing feature work) against buy's vendor cost plus internal operational cost.
The hub article on how to run a build vs buy analysis walks through how to surface this in a spreadsheet. The Federal Trade Commission procurement guidance and the Wikipedia overview of total cost of ownership are useful background reading on the cost categories.
Why this matters for the decision
When the spreadsheet undercounts the internal operational cost of buy, it overstates the cost advantage of buy versus build. That distortion can flip the decision in close cases.
It also distorts how the team allocates capacity post-decision. A team that signed up to buy and expected the vendor to handle everything will be surprised by the integration code, the data quality work, and the user support load. That surprise typically lands in months 2 through 6 of the engagement, by which point the team has already committed to the vendor and cannot reverse the decision without writing off the implementation cost.
The fix is not to never buy. The fix is to model the internal operational cost honestly in the original spreadsheet. We do this analysis routinely as part of 137Foundry services engagements, including the data integration work where the integration code maintenance line is often the most underestimated item. The main site carries the case studies.
A short checklist
- Identify the five operational responsibilities that survive the buy decision.
- Estimate the engineering and product-management hours each one consumes per year.
- Convert to dollars at loaded internal rates.
- Add the total to the vendor's annual subscription as the "true buy" cost.
- Compare to a "true build" cost that includes engineering opportunity cost.
A build vs buy spreadsheet that gets the operational ownership line right is more likely to produce a decision the team can actually live with. A spreadsheet that does not is producing an answer to a different, easier question than the one the business is actually asking.
A common failure mode worth flagging
The most consistent failure mode we have seen is that the team making the buy decision is not the same team that will own the operational responsibility post-deployment. Procurement runs the spreadsheet. Engineering ends up owning the integration code. Operations ends up owning the data quality. User support ends up answering questions about the tool. Procurement's spreadsheet did not include any of those lines because procurement is not running them.
The fix is to involve the post-deployment owners in the original spreadsheet. Engineering should sign off on the integration code estimate, including the ongoing maintenance line. Operations should sign off on the data quality and reconciliation lines. User support should sign off on the support load estimate. When those sign-offs happen before the contract is signed, the spreadsheet is more honest about the full cost.
When they do not happen, the buy decision shifts the operational burden to teams that did not have it on their roadmap and did not estimate it in their capacity plan. The resulting friction looks like cross-team conflict, but it is actually a cost-estimation problem that was created at the procurement phase.
What does this look like on a real engagement
On a recent integration project, we found the original buy-side spreadsheet had budgeted 40 hours of one-time engineering work for the integration. The actual integration consumed about 240 hours of engineering work in the first year, plus an ongoing 80 hours per year of maintenance. The procurement team had quoted the vendor's "easy integration" line; the engineering team had not been asked to validate it.
The economic impact was modest because the tool was still useful and the cost overrun was within tolerance. The reputational impact on the procurement team was larger. The next time a similar decision came around, the engineering team insisted on a written estimate before the contract could be signed. That practice has been worth it on every subsequent decision.
Top comments (0)