Build vs. buy vs. integrate: a decision framework for growing teams

TL;DR. Integration has become the default answer for most mid-market systems decisions. Building custom software makes sense in roughly one in twenty cases: when the capability is genuinely strategic, no mature SaaS covers the core, integration cannot close the gap, and the team has the engineering maturity to operate it for years. For everything else, buy well and integrate seriously.

The real question most teams are asking

The build-vs-buy question is the wrong question. For most companies between 20 and 500 people, the real decision is whether to write new software, subscribe to a mature SaaS, or glue existing tools together until they behave like one system. That third option has quietly become the default, and most frameworks still in circulation were written before it was viable.

What's changed is that integration is cheap now. In 2024 the global integration platform (iPaaS) market exceeded $9 billion and grew 23.4% year-over-year, making it the second-fastest-growing segment in the middleware market. Gartner projects it will pass $17 billion by 2028 (Gartner Market Share Analysis: iPaaS, Worldwide, 2024). What used to be a six-month custom project, passing orders from a storefront into a finance system, syncing a CRM to a support tool, stitching a billing platform to revenue reporting, is now something a capable operations engineer prototypes in a week.

That changes the calculus. If the connective tissue between systems is cheap, the set of things worth building from scratch shrinks. What's left is a narrower question, and it's the one we think teams should actually be answering: what is the small piece of capability you genuinely need to own, and how well can you connect everything else?

Why the older framework is incomplete

Martin Fowler described the cleanest version of the traditional framework in his Utility vs. Strategic Dichotomy. Utility software is the plumbing: payroll, accounting, HR, support ticketing. It doesn't differentiate you. Strategic software is what makes your business what it is, the thing that, if it works better than your competitors', wins you customers. Fowler's rule is simple. Utility you buy; strategic you build. He adds an uncomfortable observation: only about 5% of projects are genuinely strategic, and most organisations misclassify their own work.

Geoffrey Moore made a similar argument in Dealing with Darwin with the core-vs-context split: invest in core, outsource context. Both frameworks are still right. They're just incomplete for 2026.

What they miss is that "utility" is no longer one thing you either buy or build. It's a portfolio of subscriptions that don't talk to each other. The average company in the 1 to 500 employee band now runs 152 SaaS applications and spends $11.5 million a year on them, with 70% of that spend sitting outside IT's direct control, per SaaS management vendor Zylo's 2025 SaaS Management Index. (Zylo is a vendor selling into this problem, so treat the absolute numbers as directional, but the pattern is consistent across every study we've read.) The question isn't which tool to buy, because it's already been answered several times, often by people who didn't ask. The question is how to make the portfolio behave like a coherent system.

Three options at a glance

Buying a mature SaaS delivers value in weeks. The licence cost is visible on the invoice. The hidden cost is two-fold. First, every new tool increases the coordination burden: the average organisation wastes $21 million a year on unused or duplicate licences (Zylo, 2025), and 66.5% of IT leaders report unexpected charges from consumption-based or AI pricing. Second, you inherit the vendor's roadmap. You cannot differentiate on something you rent from the same catalogue as your competitors.

Building custom software delivers value in months, sometimes a year or more, and costs anywhere from $60,000 to $2M+ depending on scope. The McKinsey and Oxford study of 5,400 IT projects remains the authoritative benchmark: large IT builds run 45% over budget on average, 7% over schedule, and deliver 56% less value than predicted (McKinsey, 2012). The hidden cost is ongoing. Software you commission you also maintain, forever, or until you write it off. That maintenance is often larger than the original build.

Integrating connects SaaS tools you already own with either an iPaaS (Workato, Boomi, Tray, Make, Zapier) or a small, purpose-built connector. It delivers value in days to weeks. It is the cheapest of the three and the least glamorous. The ongoing burden is real but bounded: a handful of flows to monitor, a handful of auth tokens to rotate. It rarely makes the strategy deck, which is one of the reasons teams under-use it.

The framework we use

We go through these questions in order. Most decisions resolve at question two or three. The later you go in the list, the more the stakes rise.

1. Is this capability strategic, or is it context? Be honest. If a direct competitor running the exact same SaaS stack could still lose to you on this particular workflow, it's strategic. If not, it's context. Fowler's 5% number is worth keeping in mind. Most candidate projects fail this test the moment it's applied strictly.

2. Does a mature SaaS cover 70% or more of what you need? Not 100%. Seventy. If a well-adopted tool with a multi-year roadmap, a real support organisation, and a credible security posture handles the majority of the job, the burden of proof shifts to justifying a build. A partial fit plus integration almost always beats full custom on time, cost, and risk.

3. Can integration close the remaining gap? This is the question most teams don't ask clearly. A webhook into a queue, a scheduled sync between two systems, a small service that reshapes data between two APIs: these are not big projects. If the 30% gap can be bridged with an iPaaS flow, a small connector, or a thin internal tool sitting on top of the SaaS's API, the answer is almost always "buy and integrate."

4. Are we confident we can build this well? Building custom software is not the default setting of a 40-person company, and it isn't a safety choice for a 200-person company either. It is a specialist capability. You need people who can design the thing, people who can run it in production for years, and leadership who will protect the roadmap when other priorities arrive. If the answer to any of those is shaky, the risk profile of building is very different from what the original business case suggested.

5. If we build, what is the smallest useful version? If you've reached this question and the answer is still "build," the right next move is to define the smallest slice that proves the thesis. Teams that build everything in the first release almost always over-commit. Teams that build the strategic core first and integrate the rest for the first year have a much better track record.

Common mistakes we see

Rebuilding utility. The most expensive mistake. A team decides to replace a boring, working piece of commodity software (an admin panel, a simple workflow tool, an internal ticketing system) with a custom version because the SaaS "doesn't quite fit." The replacement takes nine months, ships 60% of the functionality, and costs significantly more to maintain than the original licence ever did. Retool, itself a low-code build platform, reports in its 2026 Build vs. Buy Report that 35% of teams have already replaced at least one SaaS tool with custom-built software. (Bear in mind the source when reading that number.) Some of those replacements will prove out. Others are this mistake with a fresher coat of paint.

Building a worse version of a mature product. If you're commissioning a CRM, a support desk, a BI tool, or a billing engine from scratch, the honest question is why you would beat a product with 500 engineers and a decade of customer feedback. Sometimes the answer is legitimate and specific. Usually, on close inspection, it's that the existing SaaS was never properly configured or integrated.

Ignoring the integration layer. Choosing to stay on a dozen disconnected SaaS tools because "we don't want to build" is its own decision, and usually a bad one. The SaaS portfolio is only as useful as the data flowing between its members. The teams who win at this give integration a single owner, a budget line, and a monthly operating rhythm. The ones who don't end up with shadow spreadsheets doing the stitching.

Underestimating the ongoing burden of custom. A build isn't done when the launch email goes out. It's done when you retire it. The ongoing cost includes security patches, dependency upgrades, staff rotation, documentation drift, and the next person who inherits the code. Anyone costing a build on the headline development number is quoting roughly half of the real bill.

The narrow case for building

We build software for a living, and we still tell clients not to more often than they expect. The short version of when custom is the right call: the capability is genuinely strategic, no credible SaaS covers the core of it, integration cannot bridge the gap, and the team has or is willing to hire the engineering maturity to own it in production for several years.

Two recent examples sit on opposite ends of this line. Klarna announced in early 2024 that an OpenAI-powered assistant was handling the work of 700 support agents, saving tens of millions in projected costs. By 2025 the company was publicly walking parts of that back and rehiring humans. The lesson isn't that the decision was wrong. It's that "replace your SaaS with something custom" is a thesis that has to survive contact with reality, and sometimes doesn't.

On the other side, 37signals moved their entire production infrastructure off AWS in 2023 and have reported roughly $7 million of savings over five years. That worked because they had three things: an engineering team that could operate hardware, leadership willing to commit publicly, and a cost structure large enough for the savings to matter. Most 20-to-500 person companies don't have any of them.

Custom can be the right call. It's just a much narrower lane than most decks imply.

How to actually decide

If you want a practical starting point: audit the SaaS portfolio you already have. List what each tool does and what it doesn't. Identify the two or three workflows that, if they worked a bit better, would genuinely move your business. Ask whether those workflows are bottlenecked by missing capability or by missing integration. Most of the time it's the second.

Build when the first test, strategic rather than context, comes back with a clear and specific answer. Integrate when the gap is data, not capability. Keep buying the things that don't differentiate you, and put real energy into configuring them well. That's not an exciting strategy. It's the one that, in our experience, leaves growing companies with systems they can keep running.

Frequently asked questions

When is custom software actually worth the cost?

Custom software is worth commissioning when the capability directly differentiates the business from competitors, when no mature SaaS covers the core requirement, when integration cannot close the gap, and when the team has the engineering maturity to operate the result in production for several years. Martin Fowler's utility-vs-strategic framework suggests this applies to roughly 5% of candidate projects. In our experience that number is about right for mid-market companies.

Is it cheaper to build software or buy SaaS?

For almost any standard business capability, buying SaaS is cheaper over a three to five year horizon, often by a large margin, once ongoing maintenance, team rotation, and opportunity cost are priced in. Custom builds become economically competitive only when the capability is genuinely strategic, or when the SaaS licence costs scale in a way that custom costs don't (very high seat counts, for example). The honest comparison must include the build cost, the first three years of maintenance, the cost of the team retaining the capability to run it, and the value you would have created working on something else.

What is iPaaS and why does it matter for build-vs-buy decisions?

iPaaS, integration platform as a service, is a category of tools (Workato, Boomi, Tray, Make, Zapier, and similar) that lets teams connect SaaS applications together with low-code flows. It matters because integration used to be an expensive custom project and is now often a days-to-weeks exercise, which shifts the economics of build-vs-buy. If the gap between a mature SaaS and your actual requirement can be closed with an iPaaS flow, building custom software for that gap rarely makes financial sense. The iPaaS market exceeded $9 billion in 2024 per Gartner, which is a fair proxy for how mainstream the approach has become.

How do we know if a capability is strategic or context?

Ask this question: if a direct competitor ran the exact same SaaS stack as you do today, could they still lose to you on the strength of this particular workflow? If yes, the workflow is strategic and worth considering a build or a differentiated configuration for. If no, it's context. It needs to work well, but the source of competitive advantage is elsewhere. Most candidate projects fail this test the moment it's applied honestly.

Should we rebuild a SaaS tool that almost fits our needs?

Usually no. The most common version of this mistake is a team replacing a boring, working SaaS tool with a custom version because the existing tool is close but not perfect. The replacement typically takes longer than expected, ships less than promised, and costs more to maintain than the subscription ever did. The better first move is to ask whether the SaaS was ever properly configured and integrated. In most cases, a few days of focused work on configuration and a small integration beats a custom rebuild on every dimension that matters.

---

Thinking through a build-vs-buy decision? Get in touch. We'll give you an honest read, including the uncomfortable answer if that's the right one. For more on how we structure engagements, see our process and technical consulting.

---

Written by the DevLume team. We advise growing teams on when to build software, when to buy it, and when the honest answer is to connect what they already have.