Build vs Buy Software: When Should a Small Business Build?

Every build vs buy argument starts the same way: an operator looks at a subscription renewal and thinks: we could just build this.

Sometimes that is correct. More often it is the most expensive sentence in the business, because the cost of building is not the build. It is everything that happens for the three years afterwards.

What does the build vs buy decision really come down to?

Money and time, in that order, with a threshold on each. Build vs buy is a budgeting question before it is a technical one.

The rough rule we use with clients is simple. If off-the-shelf software solves the problem for under about three hundred dollars a month, buy it and stop thinking. If the tooling to solve it properly is running past roughly twenty-five thousand a year, building starts to deserve a serious look.

Between those two numbers, the answer depends on whether the thing is core to how you make money. Nobody wins by building their own expense tracker. Some businesses win decisively by building the one workflow their competitors cannot copy.

The reason the low threshold is so low is that over-engineering a working product is rarely worth the time it takes. A tool that solves ninety percent of the problem today beats a perfect internal system that arrives in nine months.

Why does the last part of a build cost the most?

Because sixty percent of a build looks finished, and the remaining forty percent is where the judgment lives.

Getting to a working demo is faster than it has ever been. Modern tooling and AI assistance will take a competent operator to something that looks polished in days. That version genuinely works, for the happy path, with clean data, used by the person who built it.

Then reality arrives. Edge cases, permissions, error states, data validation, the person who pastes a spreadsheet into a text field, the customer whose name breaks the export. Every one of those is small. Together they are the majority of the effort.

That final stretch is also where domain judgment is non-negotiable. Knowing which edge cases matter, which errors must never happen silently, and what the workflow does when someone leaves the company is not a coding problem. It is an operating problem, and it does not get faster with better tools.

Teams that under-budget this do not usually abandon the build. They ship the sixty percent, work around the gaps manually, and quietly accept an ongoing tax that nobody ever puts on a spreadsheet.

What belongs in the total cost of ownership?

Everything that recurs, not just what you pay once.

The build column collects far more line items than most estimates include. Design and development time, obviously. Then hosting, monitoring, security patching, dependency upgrades, access management, documentation, and the onboarding of whoever inherits it.

Costs that get left off almost every internal build estimate:

• The maintenance burden after the original builder moves on.
• Security and compliance work that a vendor otherwise absorbs.
• Downtime, and who is on call when it happens at month end.
• Integration upkeep as the systems around it change their APIs.
• The opportunity cost of the time not spent on revenue work.

The buy column has hidden costs too: seat creep, migration effort, and the ceiling you hit when the vendor will not build the thing you need. But they are visible, priced, and predictable, which is worth more than most teams credit.

When is building genuinely the right call?

When the process is the product, or when the market has nothing that fits.

Three situations justify it. First, the workflow is your actual differentiator, and standardising it on the same tool your competitors use erases the advantage. Second, the vendor cost has scaled past the point where a small internal team is cheaper. Third, nothing on the market does the job and the workarounds have become the job.

A fourth, weaker case: data control. Sometimes regulation or client contracts genuinely require it. More often this reason is offered by teams who want to build for other reasons and need a defensible one.

Notice what is not on the list. Frustration with a vendor is not a reason. Neither is the belief that the software looks simple, which it always does from the outside, and never is once you own the edge cases.

If you do build, scope it as narrowly as you can stand. Build the one thing that must be yours, buy everything around it, and connect them. Businesses get into trouble when a justified narrow build expands into a general-purpose internal platform nobody asked for.

What does the maintenance question look like in year three?

It looks like one person who knows how it works, and a queue behind them.

Internal tooling ages differently from vendor software. There is no roadmap, no support line, and no upgrade path. It does exactly what it did on launch day while everything around it moves, and the gap widens quietly until something breaks.

Ask three questions before you commit:

1. Who maintains this when the person who built it is unavailable?
2. What happens to it if that person leaves the business entirely?
3. Is anyone budgeted to keep it current, or is it assumed to be free?

If the honest answers are "nobody," "we would be stuck," and "no," you are not choosing between building and buying. You are choosing between a subscription and a future emergency.

How do you run the decision properly?

Price both columns over three years and force the comparison onto one page.

Most teams compare a build estimate against one year of subscription and conclude building wins. Extend it to thirty-six months, add maintenance at a realistic percentage of the original effort, and include the internal hours at a rate you would actually pay someone, and the picture usually inverts.

Then apply two tie-breakers. Is this capability something a customer would ever notice or pay for? And if we get this wrong, how hard is it to reverse?

Reversibility is underrated. Leaving a vendor is annoying. Abandoning an internal system that four processes now depend on is a project. Prefer the reversible option when the numbers are close.

A practical sequence:

1. Write the requirement in one paragraph, without naming a solution.
2. Find the cheapest tool that covers eighty percent of it.
3. Run that for one quarter and log every workaround.
4. Only then price a build against the logged gaps.
5. Revisit annually as vendor pricing and your volume both change.

What should a small business do by default?

Buy, until the numbers or the strategy say otherwise.

For most small teams the constraint is attention, not licensing spend. Every hour spent maintaining an internal tool is an hour not spent on the work that generates revenue, and that trade is almost always bad below a certain scale.

Use the thresholds as guardrails rather than rules. Cheap and non-core means buy without a meeting. Expensive and core means model it properly with real numbers. Everything in between means run a quarter on something off the shelf and let the evidence decide.

You can browse what already exists across the Integrate Your Tools and Workflow Automation Software categories before assuming nothing fits, and check current vendor pricing directly, since the numbers move.

The version of build vs buy that goes wrong is not usually the one where a team builds something ambitious. It is the one where a team builds something ordinary, finishes sixty percent of it, and spends the next two years paying for the rest in workarounds nobody counted.

Common questions about internal builds?

These are the questions worth answering out loud before anyone writes code.

Does AI change the maths?

It changes the first sixty percent, not the last forty. Getting to something that demonstrably works is dramatically faster than it was, which makes small internal tools far more viable than they used to be. Maintenance, edge cases, and operational ownership have not become cheaper at all.

What is a reasonable maintenance budget?

Plan for a meaningful share of the original build effort every year, indefinitely. Dependencies age, integrations break, requirements shift, and somebody has to own that. If nobody is funded to do it, the system will degrade quietly until it fails at the worst moment.

Should you build to avoid vendor lock-in?

Rarely. You are trading vendor lock-in for person lock-in, which is usually worse in a small business because there is no support contract behind it. If lock-in is the concern, prioritise tools with clean data export over building your own.

What if no vendor does exactly what you need?

Buy the closest off-the-shelf software and connect the gap with automation before you build anything from scratch. The workaround you build in a week teaches you what the requirement actually is, and half the time the gap turns out not to matter.

How do you know the decision was right?

Revisit it annually with real numbers: what you paid, what it cost in internal hours, and whether the capability produced anything a customer noticed. Decisions in this category are not permanent, and treating them as reversible keeps the cost of being wrong small.