When to Build Software Instead of Buying It

Most businesses should buy. Off the shelf software is cheaper, faster to adopt, maintained by somebody else and improved without you asking. Anyone who tells you otherwise as a general rule is selling development.

But there is a category of company where buying stops working, and the signs are consistent enough to recognise before you have spent two years working around a tool that does not fit.

The signs you have outgrown buying

• The workarounds have names. Everybody knows to put the job number in the notes field because there is nowhere else for it. When a workaround has become vocabulary, it is now part of your process.

• A spreadsheet sits beside the system and is more accurate than it. This is the clearest signal. The sheet exists because the software cannot represent something your business genuinely does.

• You are paying for five tools and using one fifth of each. Stitched together platforms, each solving a slice, with the seams handled by people.

• Per seat pricing punishes growth. When adding a person to the team means a meaningful new monthly cost, the software has become a tax on hiring.

• Your process is genuinely unusual. Not unusual in the sense that you like it that way. Unusual in the sense that it is why clients choose you.

One of these on its own means nothing. Three together means the fit has gone.

The question that actually decides it

Is this process the thing you are paid for, or is it overhead?

Payroll is overhead. Accounting is overhead. Email is overhead. Nobody chooses you because of how you run those, and building them yourself is a straightforward mistake.

But every business has one or two processes that are the reason clients pick it. The way you estimate. The way you schedule crews. The way you manage a file from enquiry to completion. If a bought tool forces that process into a shape somebody else designed, you are slowly becoming the same as everyone using that tool.

Build the thing that differentiates you. Buy everything else. That single rule resolves most of these decisions without a spreadsheet.

What building actually costs

Be honest about the whole number, because the build is the visible part and rarely the largest.

There is the initial build, which is usually shorter than people expect for a well scoped internal tool. There is hosting and infrastructure, which is small. And there is the part that gets forgotten: somebody has to maintain it. Processes change, dependencies update, browsers move on. A system with nobody responsible for it degrades quietly and is abandoned within two years.

If you cannot answer who owns this in eighteen months, do not build it. That is the real gate, not the budget.

Scope is what kills these projects

Failed internal software almost always failed for the same reason. It tried to do everything on day one.

The version that works replaces one process, completely, for one team, and runs in production within weeks. It is unglamorous and narrow, and it earns the right to grow. The version that fails is specified for six months, launches with forty features, and none of them quite match how the work is actually done because the specification was written by people describing what they think they do.

Ship the smallest useful version, watch people use it, then extend. That sequence is worth more than any amount of upfront design.

The middle option people forget

Build against buy is a false choice. The most common right answer is neither.

Keep the systems you have and build the connections between them. Most of the pain attributed to bad software is actually the seams: information that has to be re typed, handoffs that wait for a person, a report that has to be assembled by hand.

Connecting what you already run costs a fraction of replacing it, and it frequently removes the reason you wanted to replace it. Try that before commissioning anything, because if it works you have saved a great deal of money and if it does not you have learned exactly what the real requirement is.

What you should insist on if you do build

You own the code and the data. Ask early, while the answer is cheap.

It is documented well enough for somebody else to take over. A system only its builder understands has a short life.

It connects to what you already run. An island produces the same seam problem you were trying to solve.

Somebody can change it without a development project. Configuration for the things that change often, code for the things that do not.

The honest summary

Buy overhead. Connect what you have. Build only the process that is the reason clients choose you, and only after you have named who will own it in two years.

What AI changed about this decision

Two things have shifted, and they push in opposite directions.

Building is meaningfully cheaper than it was, which moves the line on when a custom system makes sense. A tool that once needed months of development is now a matter of weeks, so processes that could never justify a build now can.

But the more important shift is that connecting what you already own has become far more capable. The seams that stayed manual were the ones needing a read of the situation, and AI handles those now. A great deal of the pain that used to justify replacing a system can be resolved by putting AI between the systems you already run.

Which is why the middle option is usually right. Try connecting before commissioning. If it works you have saved a great deal of money, and if it does not you now know exactly what the real requirement is.

Buy time before you buy software

One last check before committing to either path.

Run the process manually for a month, deliberately, with somebody recording every step and every exception. It feels like a waste and it is the cheapest specification you will ever produce.

Most businesses discover two things. The process is not what they described in the meeting, and a third of the requirements they were about to pay for solve problems that no longer exist.

AI Optimize connects existing systems first, and builds only where the process is genuinely yours. That work sits under Custom Software and Workflow Automation.