Buy, build, or leave it alone

Buy anything that is not your advantage

Accounting, email, payroll, storage, ticketing. These are solved problems with mature products, and paying for them is dramatically cheaper than owning them. No customer has ever chosen a supplier because of their expense tool.

The test is whether the process is a source of advantage. If doing it differently from everyone else is part of why customers pick you, that is a candidate for building. If it is simply something the business has to do, buy it and move on.

This sounds obvious and gets violated constantly, usually because a product does ninety percent of what is needed and the missing ten percent feels intolerable. It is almost always cheaper to adapt to the ten percent than to own the ninety.

The workaround is the signal

The clearest sign a build is justified is a workaround that has become permanent. A spreadsheet shadowing the real system. A person whose actual job is moving data between two tools. A report rebuilt by hand every month.

Those workarounds have a running cost nobody puts on a budget line, which is why they persist. The spreadsheet does not appear in any software spend review, so its cost is invisible while the subscription that would replace it is not.

Add up the hours honestly and the comparison often reverses. A permanent workaround consuming a day a week is a substantial annual cost, and it is a cost that grows with the business.

Check what you already own before deciding

Before pricing a build, audit the software you already pay for. Licensed modules that were never configured are one of the most common findings in an assessment, and they are the cheapest possible thing to act on.

A dormant feature rarely covers the whole need, and it is worth being honest about that rather than overselling it. But the comparison is not against a perfect solution, it is against a build with a budget and a maintenance burden.

Something that covers seventy percent and takes two days to configure usually wins decisively. It also narrows whatever build is still required, which makes that build cheaper and more likely to land.

Price the replacement honestly

When the option on the table is replacing an existing system, the quoted figure covers licensing and implementation and almost never covers migration, retraining, or the history you lose.

Years of records are not just data. They are pricing precedent and customer context, and in businesses that quote work based on what similar jobs cost, losing that is a direct hit to margin.

Ask specifically what does not come across, and schedule the transition away from your peak period. Both questions change the arithmetic more than the licence price does.

Leaving it alone is a real option

Some inefficiency is cheaper than the software required to remove it. A task taking twenty minutes a month does not need a system, however annoying it is when it comes round.

The number that matters is total annual handling time, not how irritating the task feels. A twenty-minute job done weekly costs far more than a two-day job done once a year, even though the second one generates more complaints.

A good assessment tells you what not to build. That list is usually longer than the build list, and it saves more money than anything on it.

When the decision is genuinely close

Sometimes buying and building are within range of each other. In that case, prefer the option that is easier to reverse. A subscription you can cancel is a smaller commitment than a codebase you now own.

Consider also who maintains it. A build means you are responsible for it forever, which is fine if you have the capacity and a real problem if the person who understands it leaves.

And start narrow either way. One workflow, one team, in production tells you more about the right answer than another month of comparison.