For years at Interact, this was a familiar story. We’d find a SaaS tool that handled maybe 70% of what we needed, and we’d spend real time and money duct-taping the other 30% together with spreadsheets, manual review, someone’s personal workaround system that lived in their head and nowhere else. Or we’d never really be able to close that 30% gap and go out looking for a better tool, wasting even more time. The tools weren’t bad, so much as our use cases weren’t quite the shape they were built for, and a 70% fit turned out to be expensive in ways that extended well beyond budget and time.
In the age of AI, that gap became something we could close ourselves. We started building comprehensive, full-stack solutions, running on cloud servers, solving parts across all parts of the business, and the team building and maintaining them is tiny. Not to prove a point about building versus buying, but because at some point it became entirely possible to apply the institutional knowledge we had to technology solutions that came so much closer to solving many of the problems that had for too long been partially solved with existing scaled SaaS products.
I’ve been noticing this same story showing up all over my LinkedIn feed lately, and there are two common flavors.
One version: “There’s a reason companies exist to solve this exact problem, and I should have just bought the real solution instead of duct-taping my own.”
The other version: “I can’t believe I paid someone else to do this halfway when I could have built it myself and solved the problem better.”
Here’s what I’ve come to believe after watching this play out both inside our own team and across everyone else’s feed: build or buy is not a single decision. It’s two separate questions that need to be treated independently of each other, but then contextually both impact how you answer the “build or buy” question.
The Two Questions People Collapse Into One
The first question is one of fit.
How close does the available solution come to solving your specific use case? SaaS has spent a long time selling a lot of 70% fits, tools that handle the common case well and leave you stitching together a second, informal system to cover everything else. A 95% fit barely needs a workaround, but a 70% fit needs an entire shadow process just to make the first one usable, and that shadow process is where the real cost hides. It’s what managed services teams, custom dev shops, and the era of SDKs and open APIs in the enterprise were meant to help close the gap with but still cost material time and budget.
The second question is capacity.
Does your team have the technical and strategic capability to understand the problem clearly, design a solution for it, build that solution, and then support it once it’s live? Capacity isn’t a headcount question as much as whether you have the judgment to know what “done” looks like for this particular problem and have the infrastructure in place to keep the solution running once the person who built it moves on to the next problem.
The intersection of the two questions produces a framework by which the buy vs. build question can be answered. When fit and capacity are both high, the decision barely needs debate, buy it and move on. When fit is high but capacity is low, buying is still the right call, but the real work is budgeting for the maintenance relationship rather than just the license, since even a well-fitting tool fails once nobody owns keeping it configured and connected. Building only makes sense where fit is low and capacity is high, and it’s the only quadrant where “I can’t believe I paid someone else to do this” is a correct conclusion rather than a frustrated one.
Low fit and low capacity together is where most of the LinkedIn frustration is actually coming from, and it’s the quadrant people misread most often. The fit problem is real and the instinct to build is understandable, but building without capacity doesn’t solve the fit problem – it just relocates it, from “the vendor’s product doesn’t fit” to “our internal build doesn’t fit either, and now we’re the ones responsible for fixing it forever.” Frustration with fit is evidence of a real, but different, problem.
The mistake almost everyone makes is answering the capacity question with the fit answer. “This tool doesn’t fit” gets translated straight into “we should build our own,” when the actual next step is to take an honest look at whether you have what it takes to own the build, deployment, and ongoing support and management.
The Market Is Already Answering This
Companies are both launching internal Centers of Excellence (COE) to drive design and deployment of AI-driven solutions, and enterprise-focused consulting organizations are launching dedicated groups to similarly solve the capacity problem.
Cognizant just launched a dedicated AI unit in EMEA, built specifically to help enterprises move from pilot projects to measurable, running outcomes, with client demand concentrated in multi-agent systems across pharma R&D, clinical trials, and regulatory work. That’s a company selling delivery capability, not just software, to organizations that have correctly diagnosed a fit problem and honestly assessed that they don’t have the internal capacity to close it alone.
That’s the grid playing out at enterprise scale, and it’s evidence that what you’re often buying your way out of is a capacity gap, not just a software gap.
Your Takeaway This Week
Next time this comes up in conversation, consider where your organization sits in the Fit/Capacity framework. Below I’ve dropped one example per quadrant, pulled from the marketing stack.
Build it — low fit, high capacity
A growth team needs multi-source lead scoring that blends product usage, sales-assist signals, and self-serve behavior into one model. HubSpot’s native scoring can approximate this with enough workflow gymnastics, but it never quite captures the interaction between signals. The team has engineers who understand both the business logic and the data pipeline, so instead of warping HubSpot’s workflows to fake it, they build the scoring layer themselves on top of their warehouse. Low fit against the off-the-shelf tool, high capacity to close that gap directly.
Buy it — high fit, high capacity
An enterprise sales org with a long, multi-stakeholder sales cycle buys Salesforce and staffs a dedicated RevOps function to configure and maintain it. Salesforce’s flexibility is built for exactly that complexity, and the team has the internal capability to run it well. High fit, high capacity, easy call.
Buy it — high fit, low capacity
A small e-commerce business buys Mailchimp to run email campaigns and basic automation. The tool is built to be self-serve, template-driven, and low-maintenance, which fits a team with no dedicated marketing ops person. High fit, low capacity, and the fit is exactly what makes the low capacity fine.
Reassess first — low fit, low capacity
A small marketing team without a marketing ops specialist buys Marketo, a platform built for high-volume enterprise nurture programs, to run a handful of simple campaigns. Nobody configures it properly, nobody maintains the lead scoring rules, and within a year it’s shelf-ware nobody trusts. The same trap shows up with Odoo: an all-in-one ERP and CRM that’s genuinely powerful, but only if someone has the capacity to configure its modules to fit the business. Bought without that capacity, it becomes a sprawling system nobody fully understands, which is worse than either building or buying something smaller would have been.
Leave a Reply