Build vs buy software: a decision framework and five-year cost worksheet

The real question: is this how you compete?

Most build-versus-buy debates start with cost. The better first question is whether the software supports work every company does the same way, or work that makes yours different.

Martin Fowler draws this line between utility and strategic software: “To my mind it’s all about whether the underlying business function is a differentiator or not.” For utility functions such as payroll, email, accounting or a standard sales pipeline, his advice is blunt: “for a utility function you buy the package and adjust your business process to match the software.” For strategic functions, the software is the advantage: “you don’t want the same software as your competitors because that would cripple your ability to differentiate.”

Most real decisions sit between those poles, which is why the useful answer is often a mix.

Seven criteria that decide it

Score each criterion for your situation. If most point one way, the decision is made. If they split, look at the third option below before you choose.

The option between: buy the platform, build the edges

For business systems such as CRM and ERP, the strongest answer is often a proven platform with custom work where your process is genuinely different: a module, an integration, an internal app on top of the platform’s data, or an AI assistant that works across systems.

• You get the vendor’s security, updates and ecosystem for the commodity parts.
• You spend engineering money only where it creates an advantage.
• The custom parts stay small enough to own, document and replace.

The risk is customisation creep: so many changes that every platform upgrade becomes a project. Fowler calls buying a package for a utility function and then spending “huge amounts of money customizing this” “just as wasteful” as building it. Keep custom code outside the platform where you can (in services that talk to it through its API), and write down why each customisation exists.

It is also how we approach the question in CRM, ERP and systems integration work: compare fit, flexibility and total cost of ownership for both routes. More often than not, the answer is a proven platform with a few custom modules where the process really differs.

A five-year cost worksheet

First-year comparisons favour buying, because subscriptions start small and builds front-load their cost. Compare five years instead, and include the costs that don’t appear on the price page. The UK government’s Service Standard sets a good test for either route: “understand total cost of ownership of the technology and preserve the ability to make different choices in future.”

Maintenance is the line most build estimates understate. Keeping existing systems running tends to take a larger share of a technology budget than building new ones: the US federal government, one of the few organisations that publishes the split, reports spending “about 80 percent on operations and maintenance of existing IT” (GAO, 2025). Your ratio will differ, but plan for maintenance from the first day.

A worked example (illustrative)

A sales team of 50 choosing between a leading CRM and a custom-built one. The licence price is Salesforce’s list price for its Pro Suite edition ($100 per user per month, billed annually), checked on 26 October 2026; every other figure is an assumption to replace with your own. Engineering and implementation time is priced at $75 an hour, or $3,000 per person-week, the middle rate in our MVP cost guide.

Licences: 50 users × $100 × 12 months × 5 years

$300,000

Implementation and configuration: 8 person-weeks

$24,000

Integrations (accounting, website forms): 4 person-weeks

$12,000

Data migration: 3 person-weeks

$9,000

Five-year total

$345,000

Discovery, design and build: 40 person-weeks

$120,000

Integrations: 4 person-weeks

$12,000

Data migration: 3 person-weeks

$9,000

Hosting and third-party services: $400 a month × 60 months

$24,000

Maintenance and improvements: 8 person-weeks a year × 5 years

$120,000

Five-year total

$285,000

In this example building comes out about $60,000 cheaper over five years. Change one assumption and it flips: at $150 an hour, building costs about $546,000 against $390,000 for buying; with 20 users instead of 50, buying falls to about $165,000. Licence costs follow the number of users, while a build’s cost barely moves with it, so the larger the team, the more building tends to pay. That sensitivity is the point: price rarely settles the question on its own. What tips it is everything else in the criteria table. A team whose sales process is standard should buy and spend the difference on adoption; a team whose process is the product should build, or buy the platform and build the edges.

When building wins

• The workflow is how you compete, and a product would force you to work like everyone else.
• Off-the-shelf tools cover 60% of the need and spreadsheets cover the rest, badly.
• Per-seat or per-usage pricing grows faster than the value as you scale.
• You need full control over data location, processing or audit trails.
• You plan to sell the capability, or put it in front of your own customers.

When buying wins

• The process is standard, and adapting to the product costs less than building around you.
• You need it working in weeks, not months.
• Nobody internally can own a codebase, and you don’t want an ongoing engineering relationship.
• The vendor’s ecosystem (integrations, apps, trained administrators) is worth more than a perfect fit.

Build vs buy in the age of AI

Two things have changed the calculation, in opposite directions.

Buying now often includes AI. Major business platforms bundle assistants and agents, usually priced per seat or per use. Salesforce, for example, lists Agentforce for Sales from $125 per user per month, which for 50 users is $75,000 a year at list price. Before paying, test them on your own records and processes: an assistant that only sees the platform’s data can’t answer questions that span your other systems.

Building is faster, but owning is not cheaper. AI coding tools shorten the first build. They don’t remove testing, security, maintenance or the need for someone who understands the system, which is where most of the five-year cost sits.

The pragmatic pattern is the hybrid again: keep the system of record you bought, and build the AI layer that works across it and your other tools, on your terms. Our guide to AI agent costs covers what that layer takes.

Before you decide: a checklist

1. Write down the process the software must support, including the exceptions.
2. Mark which steps are standard and which are genuinely yours.
3. Trial the two strongest products on your real data, with the people who will use them.
4. List every integration and who will build and maintain it.
5. Fill in the five-year worksheet for both routes, with maintenance included.
6. Decide who owns the result, either way.

If you are replacing an ageing system rather than starting fresh, read our guide to legacy modernisation strategies as well: repurchasing is one of seven options.

Sources

Every source below was read on 26 October 2026. Prices and product details change; check the current page before relying on a figure.

1. Martin Fowler: Utility Vs Strategic Dichotomy
2. Salesforce: Sales Cloud pricing
3. Microsoft: Dynamics 365 Sales pricing
4. US Government Accountability Office: Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems (GAO-25-107795)
5. GOV.UK: Service Standard, point 11: Choose the right tools and technology
6. GOV.UK: Choosing technology: an introduction