Build vs buy: when custom software is actually the cheaper option

Short answer: buying is cheaper when the process is standard and you would use most of the product. Building is cheaper when the process is your advantage, when per-seat pricing grows faster than the value, or when the product needs so much configuration that you end up maintaining the configuration. The sticker prices rarely settle it, because only one of the two has been fully costed.

The build-versus-buy conversation usually gets settled in about four minutes, by comparing a subscription price against a development quote. Nine hundred a month against sixty thousand up front is not a close-run thing, so the meeting moves on.

That comparison is not wrong so much as incomplete on both sides. The subscription is a real number, arriving monthly, easy to approve. The build quote is a real number too, but it is the only number in the room that has been fully costed — which makes it look expensive next to one that has not been costed at all.

What does the subscription price leave out?

Implementation and configuration, integration with your existing systems, per-seat growth as you hire, the cost of bending your process to fit, the workarounds for what it cannot do, and getting your data out again if you leave.

A product is priced for the average of its market. Your business is not the average of its market, or you would be competing purely on price. The gap between the two gets closed somewhere, and the closing is rarely free.

Configuration and implementation. Anything serious in this category has a partner network, and the partner network exists because the product needs weeks of setup by someone who knows it. That fee is frequently a multiple of the first year’s licence.
Integration. The product holds one version of the truth and your existing systems hold another. Making them agree is a build project, just one you are now doing against someone else’s API and their release schedule.
Per-seat growth. Priced per user, the cost grows with headcount rather than with usage. A tool that is obviously cheap at eight people is a standing line item worth arguing about at forty.
The bending. The most expensive and least visible cost. Where the product does not match the process, the process changes to match the product — and if the process was part of why customers choose you, you have just paid a subscription to be slightly more ordinary.
The workaround tax. The export into a spreadsheet, the second system for the one case it cannot handle, the field everyone has agreed to use for a purpose it was not named for. These do not appear on any invoice. They show up as hours.
Exit. Getting your data out in a usable shape, whenever that day comes. Worth asking about before you go in, because the answer is much easier to get while you are still a prospect.

What does the build quote leave out?

Year two — dependencies, broken integrations, changed requirements. Hosting. The bus factor if one person understands it. And your own team’s time making decisions, which is real cost and almost never in the estimate.

Being fair in the other direction, because a development quote is usually presented as a total when it is really an opening balance.

Year two. Software is not a capital asset that sits still. Dependencies need updating, integrations break when the other end changes, and requirements move. Budget for the ongoing cost of ownership, not just delivery.
Hosting and running costs. Smaller than people fear for most internal tools, but not zero, and worth having modelled rather than assumed.
The bus factor. If one person understands the system and that person leaves, you own a liability rather than an asset. Documentation, a walkthrough and code in your own repositories are what convert one into the other. Insist on all three.
Your own time. A build needs decisions from someone who knows the process, and that person is usually busy because they are the one who knows the process. This is real cost and it is almost never in the estimate.

How do you actually decide?

Three questions. Is this process your advantage or just plumbing? How much of the product would you genuinely use? And what happens when you need to change it next year?

Once both columns are honest, the decision usually turns on three things rather than on the arithmetic.

1. Is this process your advantage, or just plumbing?

Payroll is plumbing. So is accounting, email, and almost all of HR. Nobody has ever won a customer with a better general ledger, and building one would be an expensive way to end up with a worse version of something you could have bought on Tuesday.

But most businesses have one process that is genuinely theirs — how they quote, how they schedule, how they decide what to make next. That is the part customers actually notice. Forcing it into a product built for the average of your industry is how a company becomes an average one.

2. How much of the product would you actually use?

If the honest answer is most of it, buy it. That is the product doing its job, and the vendor is amortising development across every other customer so you do not have to.

If the answer is around a tenth, and the tenth you need sits awkwardly next to nine tenths you have to navigate around, look harder. You are paying for the nine tenths in licence fees and paying for them again in the time it takes to work past them.

3. What breaks if you have to change it next year?

With a product, the answer is that you submit a feature request and wait, or you build the workaround. With something you own, the answer is that you change it — and this is the difference that compounds. It matters most where regulation moves, where you are still finding the shape of the business, or where a competitor can copy you the moment you slow down.

Is it really one or the other?

No. Build-versus-buy is a decision per workflow, not per company. The version that works is unglamorous: buy the commodity, build the differentiator, and put a proper integration between them.

Which way each workflow tends to fall
Workflow	Usually	Because
Accounting, payroll, email	Buy	Nobody wins a customer with a better general ledger
CRM	Buy	Well-served market, and you will use most of it
How you quote or price	Build	The rules are yours and rarely fit a product
Scheduling under your constraints	Build	Generic tools cannot model industry-specific rules
Customer-facing portal	Either	Depends whether your data already lives somewhere usable
Reporting across several systems	Build	Nothing off the shelf knows which system wins a conflict

The framing is a trap: it is presented as a choice for the whole system when it is really a choice per workflow. The version that tends to work is unglamorous — buy the commodity, build the differentiator, and put a proper integration between them.

So the accounting system is bought. The CRM is probably bought. The thing that decides which job goes to which crew on which day, given six constraints that only exist in your industry, is built, because that is the part where being generic costs you money.

This also spreads the risk sensibly. You are not betting the operation on one large build, and you are not surrendering the part of the process that makes you worth hiring.

What should you do before deciding?

Write the workflow down as it actually runs, exceptions included. Then get the buy option costed as thoroughly as the build one — implementation, integration, price at double your headcount, and how you would extract your data if you left.

Two things, and both are cheap relative to getting this wrong.

First, write down the workflow as it actually runs — including the exceptions, because the exceptions are where products break and where the real cost is hiding. If nobody can write it down, that is the finding: you are not ready to buy or build until someone can.

Second, get the buy option costed as thoroughly as the build one. Ask the vendor for implementation cost, integration cost, the price at double your current headcount, and how you would extract your data if you left. Compare that against a build quote and the gap is frequently much smaller than the sticker prices suggested — sometimes it points the other way.

And if the honest conclusion is buy, buy. We tell people this regularly, including people who arrived asking us to build something.