Build vs buy software: the questions that settle it, and the costs each side hides

Should we build or buy software?

The question tends to arrive when a tool stops fitting. Staff keep a spreadsheet open beside the product you pay for, the same order gets typed into two systems, or a renewal quote comes in well above last year’s. Both answers carry costs the first quote leaves out, so the choice is worth making on purpose rather than by default.

The clearest test comes from a July 2010 essay by Martin Fowler on what he calls the utility vs strategic dichotomy. It hinges on whether the way you do a piece of work is a reason customers pick you:

• Utility work: how you do it doesn’t set you apart. Payroll is his example. Here he advises buying the package and changing your own process to match the software, and he calls paying heavily to customize a bought package just as wasteful.
• Strategic work: how you do it is part of what makes you different. Running the same software as your competitors would wear that difference away, so this is where a build earns its place.
• The share: he suggests only a few projects are strategic, nearer 95 to 5 than 80 to 20, and warns that people often count too much of their work as strategic.

The risks differ as well. For utility work the danger is a failure, such as a missed payroll, so the aim is enough care to prevent one while spending as little as possible otherwise. For strategic work the danger is moving slower than a competitor, so speed counts for more than the price of the software. The line also moves over time: what sets a business apart today can become standard practice later.

The UK government’s Service Manual gives its own teams a similar method (October 2024). It asks them to map the parts of a service to learn what they need to build and what they can buy or get for free, to keep the freedom to change their minds later, to keep full control of the data they store, and to keep the total cost of ownership down, including the chance of being locked into long contracts for specific tools and providers.

When should you build custom software?

A build makes sense when the work is specific to you and fitting it into a product keeps costing more. These are the signs to look for:

• The work is how you win: your quoting, scheduling or service process is part of why customers choose you, and a product would have you run it the way everyone else does.
• The real process lives beside the product: staff keep a spreadsheet, a shared inbox or a whiteboard next to the tool you pay for, because the tool can’t hold the steps they actually follow.
• Your systems don’t talk to each other: the same details are typed into two or three places, and most of the errors come from the retyping.
• You pay for a lot to use a little: a suite charges every seat for modules your team never opens, while the one step you need is missing.
• No product does it: you have searched and run trials, and every option needs a workaround at the step that matters most.

One sign on its own rarely settles it. Two or three together, on work your customers notice, usually do.

When is buying software the better call?

If Fowler is right that only a few projects are strategic, most of the software a business runs should be bought. Buying is the better call when:

• The job is the same everywhere: payroll, accounting, email, file storage and video calls work much the same way in every business, and the products for them are mature.
• Outside rules set the shape: some work follows rules that other people change. The IRS’s Publication 15-T for 2026, for example, sets that year’s federal income tax withholding tables, updated for changes in the tax law. A product whose maker keeps up with changes like these saves you tracking each one in code of your own.
• A product fits with a few changes on your side: if adjusting your process closes the gaps, adjust the process, as Fowler advises.
• You need it working now: a product you can switch on this week wins when the need is urgent.
• Nobody would own a build: custom software needs someone inside the business to decide what changes and to test it. Without that person, even a good build drifts.

For a CRM in particular, custom CRM vs off-the-shelf works through the same choice.

What are the hidden costs of buying software?

The price per user per month is the figure everyone compares. These are the costs that come after it:

• Seats that grow with you: per-user pricing means the bill rises with headcount, including people who only need to look at one screen.
• Increases at renewal: Vertice, which manages software spend for companies, reported SaaS price inflation of 16.4% in June 2026 and 12.7% in August, with preliminary September data at 14.3%, measured on the spend it handles (October 2026). It adds that vendors may be pairing list-price rises with less access to features at the same tier.
• The plan you actually need: features such as single sign-on, audit logs and extra environments can sit on a higher plan than the one first quoted. Retool’s pricing page, read in November 2026, is one example: audit logs start on its Business plan, and single sign-on is listed on Enterprise.
• Connecting it to everything else: connectors, integration tools and the hours to set them up can be priced apart from the product.
• Workarounds: the hours staff spend on the spreadsheet beside the product, retyping and checking, are a cost even though no invoice shows them.
• Leaving: getting your records out in a form another system can read, and running two systems side by side while you move.

What are the hidden costs of building software?

A build has its own list, and a quote that covers only the build leaves most of it out:

• Upkeep, every year: BD Emerson’s October 2026 cost guide puts maintenance and support at 15 to 25% of the build cost a year, covering defects, patches, dependency upgrades, small improvements and infrastructure.
• Hosting and outside services: the same guide lists cloud hosting, and third-party licences for monitoring, sign-in and messaging, among the cost lines most proposals leave out of the build price.
• Security updates: the libraries a system is built on get security fixes, and someone has to apply them and check that nothing broke.
• The knowledge: the people who understand the code, and the notes that let someone new pick it up. If one person holds all of it, that’s a risk in itself.
• Your own team’s time: someone in the business decides what the software should do, answers questions while it’s built, and tests it before staff rely on it.

At BD Emerson’s 15 to 25% a year, four years of upkeep after a launch add 60 to 100% of the build cost again. The custom software cost page gives the market’s build and upkeep ranges by size of business, with their sources.

Does building or buying cost less over five years?

Neither, as a rule. It depends on your numbers, so put both sides on the same basis before you compare them:

1. Count the users and the years: the people who will use the software, and how long you expect to keep it. Forty users over five years is 2,400 user-months, and every price per user per month is multiplied by that number.
2. Add the product’s other lines: the plan you’d really need, connectors, setup and training, and an increase at each renewal. A price that rises 10% at each of four renewals ends more than 46% above where it started.
3. Add the build’s other lines: the build itself, a yearly upkeep share, hosting and outside services, and your team’s time.
4. Price leaving on both sides: what it takes to move off the product, and, for a build, what the contract says happens if you leave.
5. Compare the totals, then the fit: when the totals come out close, choose the side that fits how your team works.

Buying usually wins the first year. Which side wins over five depends on the seat count, the renewals and how much of the product your team really uses.

How do custom and off-the-shelf software compare?

Side by side, the two differ less in features than in who controls what:

Can you buy the core and build the rest?

Often, and it’s usually the first thing to try. The options run from the least building to the most:

• Set up what you already have: many products have custom fields, workflows and permissions that nobody has switched on. Configure before you buy more.
• Connect what you have: an integration tool, or the products’ own APIs, can pass records between systems so nobody retypes them.
• Add a low-code layer: a builder can put screens over data you already hold. The no-code vs low-code vs custom code guide compares the three ways of making them.
• Build one piece: keep the product for the standard work, and build only the part that sets you apart, connected to it through its API.

Building one piece leaves the vendor to keep up the standard work, and puts your own spending where Fowler says it pays: on what makes you different.

What doesn’t settle the decision?

Some things feel decisive and aren’t:

• The demo: a demo shows the product doing what it does well, on clean data. Ask to run one of your own awkward cases through it instead.
• The feature count: a long list matters less than whether the three steps your team does most are quick to do.
• The first-year price: what you pay at each renewal matters more, so ask for the renewal terms in writing before you sign.
• What a competitor uses: their process isn’t yours, and if the work is strategic, Fowler’s point is that matching them is the problem.
• “Done at launch”: a build isn’t finished when it goes live, since it needs upkeep for as long as you use it. A product isn’t finished at sign-up either: someone has to set it up and keep it set up.

What should you check before you sign either way?

Whichever way you lean, run the same checks on both options:

1. Write down the five tasks that matter most, in your team’s words, and test each option against them.
2. Run a real case through it: a messy order, an unusual customer, the exception your team handles every week.
3. Ask how your data comes out: in which format, how often and at what cost, both while you stay and when you leave.
4. Price five years, not one: seats, renewals and plan changes on one side; the build, upkeep and hosting on the other.
5. Ask what happens when it breaks: who answers, how quickly, and under which terms.
6. Name the person inside your business who will be responsible for it, whichever way you go.

Checks 1 and 2 show fit. Checks 3 to 5 show cost and risk. Check 6 decides whether either option still works a year from now.

We build custom software, so read this guide knowing which side of the decision we sit on. When a product already does the job, we say so on the call, and we don’t sell an off-the-shelf product or a software licence. Our custom software work makes a system for one business, with its code kept in a repository of its own. After launch, the system stays on a monthly plan, which the proposal prices alongside the build.

AlvyOne, the operations system we built and run with Alvy, works the buy-the-core way. Alvy kept the dispatch system its team already used. The order intake we built reads the order emails, works out which client sent each one and creates the order in that dispatch system through its API, holding anything unclear for a dispatcher. The AlvyOne case study has the detail. Alvy is owned by our co-founder Noah Alvarez, and DSI is an Alvy company.

If you’re weighing the two, bring your answers to the six checks to a 15-minute call.