Build, Buy or Extend: How to Choose the Right Software Strategy

Most companies already run ERPs, CRMs, and proprietary platforms they've invested in for years. So when a new business need shows up, the real question is rarely a blank-slate "Buy or Build." It's more specific than that: the ERP you already have doesn't cover this new requirement, or keeping it running is getting expensive, or a CRM would technically handle the job but you're wondering whether something more custom is worth it.

For nearly two decades, the answer most technology leaders got from advisors and analysts was clear: buy. Pick a mature product, integrate it, and save engineering time for the few things a vendor doesn't already solve well. CIO recently made the case for revisiting that default, arguing that AI-assisted development has compressed build timelines from quarters to weeks.

That's why, increasingly, the decision a company actually faces isn't build versus buy. It's Build, Buy, or Extend,and getting that framing wrong gets expensive fast. Mariano Jurich, Senior AI Product Leader at Making Sense, put it simply in a recent interview with Techloy about why AI pilots so often stall before reaching production: Buy commodities, and Build what differentiates the business. For systems like ERP or CRM, he argues, buying is generally the right call. But "if a feature is a core differentiator that customers pay for, the company should own the roadmap and strategy." A $100,000 SaaS contract, in his framing, often beats a $250,000 custom build that also needs permanent engineering support behind it.

Define the problem before choosing the approach

In the early conversations we run with mid-market and PE-backed teams , this is almost always the first fork in the road. A team walks in already convinced it needs a new CRM, a platform replacement, or a custom build, while the actual problem underneath is still fuzzy.

At Making Sense, this is what Discovery is for: looking at the business outcome the company needs, how the process runs today, what technology already supports it, and where the gap is big enough to justify the investment. Only after that does it make sense to weigh build against buy against extend.

Buy when the market already solves the need well

Buying tends to be the strongest option when the capability is standardized and a mature product fits the business reasonably well. Payroll and expense management are typical examples. They're necessary to run the company, but a proprietary version of either is unlikely to create enough advantage to justify owning its evolution.

In these cases, a specialized provider maintains and improves the capability across hundreds of customers, while the company's own team stays focused on the work that actually moves the business forward. The caveat worth flagging early: "buy" doesn't automatically mean "cheaper." A subscription that looks reasonable on day one can climb into serious money as the company grows, and it still may not do everything the way the business works. That's a comparison we come back to under Build.

Extend when the existing foundation still has value

Extend makes sense when a system that already runs the business is a solid foundation, but doesn't cover everything the business is trying to do now.

Vetsource International, a veterinary e-commerce platform, is a good example. It already had a strong platform built for the U.S. market and needed to expand into the UK and Canada. Making Sense worked on top of that existing base to build a configurable architecture that could handle different regulations, currencies, tax rules, and payment methods across markets. Vetsource reused both the platform and the institutional knowledge already built around it, and estimates an 80% faster time to market for future country launches.

The condition that has to hold is that keeping the system is worth more than replacing it. Two very different situations can make that true:

• The foundation is still a genuine asset. The system does its job, and building on top of it preserves years of investment.
• Replacing it is simply too risky. In banks, regulated infrastructure, and other critical systems, migrating can be so disruptive that extending a system nobody loves is still the right call for years, because the cost of replacing it (technical risk, downtime, regulatory exposure) outweighs the benefit.

Extending stops making sense when that balance tips: when the architecture itself has become the barrier to what the business needs next, and the risk of replacing it is finally lower than the cost of working around it.

Build when owning the capability has strategic value

Build becomes the stronger case when how something works is part of what makes the company different. Owning that piece of the stack means deciding what to prioritize and when to change it, instead of waiting on someone else's product roadmap.

That ownership isn't free. Maintenance, security, and the roadmap all become the company's responsibility instead of a vendor's. But the comparison people skip is that buying carries its own running costs too: licensing, implementation, integration, and a subscription that rarely goes down over time.

This is where the math has quietly flipped for a lot of teams. An enterprise subscription can reach several hundred thousand dollars a year and still not do everything the way the business works . A custom build might cost more up front, but when it replaces a subscription in that range and fits the business exactly, the investment can pay for itself within a few years, and then keep paying off. AI-assisted development pushes that further, turning capabilities that would have justified a vendor contract two years ago into something a team can often build in weeks rather than quarters.

Evaluate each option against real business conditions

Once the initial direction is set, five questions tend to separate the stronger choice from the weaker one:

1. Which option gets to value faster?

Buy wins when a product already fits well and implementation is light. Extend has the edge when users, data, and most of the workflow already live inside a platform the company runs, and pulling all of that out into something new would be slow, costly, and risky. Build can beat both when the scope is tight and skipping vendor selection and integration actually saves time.

An available product covering 80% of the need can beat waiting six months for a perfect fit. The same logic runs the other way: if extending what already exists solves the problem fast, adding a new platform on top may just slow things down.

2. What does it cost over its full life, not just on day one?

With Buy, the real number includes implementation, integration, and the increases tied to usage or seat count that show up later. Build carries development plus ongoing maintenance and security. Extend can preserve prior investment, as long as building on what you have costs less than starting over.

Software pricing isn't holding still, either. CIO reported that a Gartner analyst tracked SaaS subscription costs from several major vendors rising 10% to 20% in a single year, with ERP, CRM, and data platforms among the categories hit hardest. The comparison worth running is total cost over the capability's expected life, not the number on the first invoice.

3. Which parts of the process are actually worth keeping?

The fit between software and process is rarely perfect. What matters is what that gap costs the business.

If a standard platform means dropping internal steps that don't create value anymore, that's an improvement, not a loss. It's a different conversation when the gap touches a way of working that does create value: even a small mismatch can force manual workarounds every time a team runs a process that matters. Before paying for customization, it's worth separating the differences that protect a real advantage from the ones that just stuck around out of habit.

4. How does it fit the technology the company already runs?

A new solution has to talk to the systems already in place, and the right answer depends heavily on the stack a company already runs. Before choosing one, someone has to map where the relevant data lives, which systems need to exchange it, and who owns those connections once something changes.

This isn't a small consideration anymore. Nintex's SaaS sprawl survey, reported by CIO, found that more than six in ten IT leaders say their organizations add new SaaS tools every month, and more than half of U.S. organizations surveyed were already running between 51 and 200 tools. The consequences showed up as duplicated data, more manual entry, and slower workflows.

That changes what integration actually means for each path: Buy wins when the product connects cleanly with what already matters most, Extend simplifies things when the data already lives inside a platform in use, and Build lets the connections be designed on purpose, at the cost of owning them.

5. How much room does the choice leave for what comes next?

A solution also has to survive changes that haven't happened yet. Higher volume, an acquisition, a new market. One practical test: if the business needs something different in two or three years, what would it cost, in time and money, to change today's decision?

A practical framework for comparing build, buy, and extend

The five factors above can be summarized in a matrix. No option wins on all five at once. This isn't a scoring system, just a way to see which tradeoffs matter most for a specific problem.

A company can reasonably accept less flexibility on a standardized piece of the stack while insisting on ownership over the one capability that actually shapes its value proposition.

The right strategy can combine more than one path

Build, buy, and extend don't have to apply to an entire platform at once. One of our own projects shows how that plays out when it's not an either/or.

Remote Legal, a court reporting company, needed to move depositions into a fully remote environment, a workflow specific enough to become the core of its value proposition. Making Sense built the platform around the needs of lawyers, witnesses, and court reporters, but that didn't mean building every layer from scratch. Video conferencing and real-time speech-to-text came from established providers already solving those problems well. What Making Sense built was the layer on top: the experience and business logic that turned those pieces into a workflow designed for this specific market.

That's the distinction worth carrying into any architecture decision. Remote Legal didn't need to own a video engine or a speech-to-text model, but to own the part that made the product different from anything a competitor could assemble out of the same off-the-shelf parts.

None of the three paths is inherently better. What decides it is how much of the company's edge actually lives inside that piece of software, and whether the team building or buying it can be honest about that before signing anything.

If your team is weighing to build, buy, or extend for an upcoming initiative, talk to our team about where to start.