Buy or build: how to actually decide

Ask a software vendor whether to buy or build and they will say buy. Ask a development agency and they will say build. Both answers are predictions about their own revenue, so here is a framework you can run yourself.

Work through the questions in order. The first one that gives a clear answer is usually the answer.

One: is your process genuinely unusual?

Not different, unusual. Most businesses believe their process is unique and most are wrong: invoicing is invoicing, and payroll is payroll. Buy those. They are solved, cheaply, by products with more testing behind them than you could ever fund.

But some businesses do have one process that is genuinely theirs, and it is usually the thing customers actually pay them for. A studio that combines training plans with nutrition and attendance in a way its competitors do not. A practice with a review workflow that is the reason its work is trusted. That process is where custom software earns its cost, because it is precisely the process no product will support.

Two: how many tools would it have to talk to?

This is the question people skip, and it is the one that most often decides the outcome. A bought product is cheap to license and can be expensive to connect. If your operation involves five systems that all need the same customer record, you will pay for integration whichever route you choose.

Count the systems that need to know about a single transaction from start to finish. At one or two, buying is almost always right. At five or more, look carefully, because the integration work can exceed the difference in licence cost, and a custom core sometimes means fewer joints in total.

Three: what does per-user pricing do to you at scale?

Per-seat pricing is honest and it has a shape you need to understand: your software bill grows in proportion to your headcount, forever, whether or not each new person creates proportional value.

Project the cost at the size you intend to be in three years, not the size you are. Then compare the three-year total against a build. Two things usually emerge. Small teams are almost always better off buying, because a build's fixed cost is spread over too few people. Teams heading past twenty or thirty users, especially where many are occasional or field users who each need a seat, find the arithmetic changes sharply.

One caution: do not compare a build's price against a licence and stop there. A build has running costs, and it needs someone to maintain it. Compare total cost of ownership on both sides or the comparison is meaningless.

Four: how bad is it if you have to change later?

Every choice here is reversible at a price. What matters is the price. Before committing either way, ask what leaving looks like:

• Can you get your data out, in a format something else can read, without paying for the privilege?
• If you built it, is the code documented and owned by you, or is it effectively hostage to one supplier?
• How much of your process would have to be relearned rather than just remapped?

A bought product with a clean export is a low-risk bet even if it only half fits. A bought product that holds your data in a proprietary format is a high-risk bet even if it fits perfectly today. The same test applies to a build: if the supplier will not hand over documented source code, you have bought the worst of both options.

The answer is usually not either

Framed as buy or build, this looks like one decision. In practice, the sensible answer for most small businesses is a mix: buy the solved commodities, build the one process that is genuinely yours, and connect them so the same information is entered once.

That mix is unglamorous and it is usually correct. It also explains why 'we already have software' and 'we need custom software' are so often both true of the same business at the same time.