Build vs buy software: should a small business build or buy?

Every growing business reaches a version of the same fork in the road. The tools you started with no longer fit the way you actually work, and two paths present themselves: subscribe to another product, or have something built for you. Software vendors will tell you to buy. Development agencies will tell you to build. Both are answering a question about their own business model rather than yours, which is why the advice you find online tends to be confident and contradictory in equal measure.

The useful reframe is that build vs buy is not a technology decision at all. It is a decision about where your business is genuinely different from every other business in your industry, and where it is exactly the same. Payroll is not your competitive advantage. Neither is invoicing, nor sending a receipt. But the specific way you quote a complicated job, schedule your crews, or grade and price incoming stock might be. Get that judgement right and the software choice mostly follows on its own.

	Buy off-the-shelf	Build custom
Time to value	Days to weeks	Months
Upfront cost	Low, usually a subscription	High, paid before any return
Cost at scale	Rises with seats and add-ons	Flatter, but maintenance never stops
Fit to your process	Good if your process is standard	Exact, because you specify it
Who fixes it	The vendor, on their roadmap	You, on your budget
Biggest risk	Bending your business to the tool	Owning software nobody maintains
Best suited to	Commodity functions and compliance	The one workflow that defines you

What does build vs buy actually mean in practice?

The framing is more useful once you accept there are three options, not two. Buying means licensing an existing product and adapting your process to it. Building rarely means writing everything from scratch any more; it usually means commissioning a bespoke application assembled from existing components, hosted infrastructure and paid services. In between sits a third path that suits a lot of small businesses: configuring and connecting tools you already pay for, using low-code platforms and automation to create something that behaves like custom software without the cost of bespoke development.

That middle path matters because most owners who say "we need something built" actually need two systems to talk to each other and one form to stop being a spreadsheet. Working out which of the three you need is the entire exercise, and it is worth doing before you take a single vendor meeting.

When should a small business buy off-the-shelf software?

Buy whenever the need is common, well solved and not a source of differentiation. Accounting, payroll, rostering, email marketing, card payments, an e-commerce platform, file storage: thousands of businesses need the same thing, so a mature product will be cheaper, more reliable and better tested than anything you could commission. You also get updates you did not pay for, security work you do not have to think about, and support at three in the morning that is somebody else's job.

There is a specifically Australian reason to buy in some categories. Anywhere your software touches regulation, such as Single Touch Payroll, GST and BAS reporting, superannuation or award interpretation, the rules change and the vendor absorbs that cost. Building custom software in a regulated area means you have quietly taken on a permanent compliance obligation. Buying also wins when speed matters more than fit, which is most of the time in a small business, and when you are not yet sure what you need. If you are still working out whether a category of tool is right at all, start with the category question first, as we set out in does your small business need a CRM.

When does building custom software actually pay off?

Custom becomes defensible when one or more of four signals is clearly present.

• The process is your advantage. If how you do the work is a genuine reason customers choose you, forcing it into a generic tool erodes the very thing you are selling.
• Nothing fits, and you are paying for it daily. Every product has been trialled and each one requires an export to a spreadsheet to finish the job. The workaround has become the process.
• Your systems will not talk. The same data is typed into two or three places by hand. Here the answer is often integration rather than a whole new application, which is the cheapest form of "custom" there is.
• Per-seat pricing has turned punitive. At a certain headcount or transaction volume, subscription costs across several overlapping tools start to rival the cost of owning something.

The unglamorous truth is that most small businesses meet none of these, and the ones that do usually meet only the third. That is good news, because integration work is faster and far cheaper than bespoke development. The clearest early warning that you are approaching the fork at all is covered in signs your business has outgrown spreadsheets.

How do you compare the real cost of building versus buying?

Most build vs buy comparisons are lost at this step, because a subscription price is compared against a build quote. Those are not comparable numbers. Compare total cost of ownership over three years across four buckets, for both options.

1. Acquisition. Licence or subscription fees at your realistic future seat count, or the build quote plus a contingency, because scope moves.
2. Integration and migration. Cleaning and moving existing data, connecting to the systems you keep, and the staff time to test it. This is routinely underestimated in both directions.
3. Running it. Training, admin time, and for custom software, ongoing maintenance. A common planning rule of thumb is to budget annual maintenance as a meaningful share of the original build cost, because hosting, dependency updates, browser changes and small fixes do not stop when the project does.
4. The cost of doing nothing. The bucket almost everyone omits. Hours lost to manual re-entry, errors and rework, duplicated subscriptions, and decisions made on numbers that are a fortnight old.

That fourth bucket is what makes the comparison honest, and it is worth quantifying roughly rather than precisely. If two staff each lose several hours a week to manual data handling, put an hourly cost on it and annualise it. The number is usually larger than owners expect, and it is the number that tells you whether either option is worth doing. It is the same discipline behind automating business reporting, where the saving is measured in reclaimed hours rather than software features. Alpha Vault's AI solutions and intelligent automation work almost always starts here, because a costed baseline is what turns a software argument into a business decision.

Is a hybrid approach better than choosing one?

For most growing businesses, yes, and it is the answer we reach most often. Buy proven products for the commodity functions. Build, or configure, only the one workflow that genuinely defines your business. Then invest deliberately in the layer that connects them, so data flows without a human retyping it.

This gives you the economics of products where needs are common and the precision of custom where it actually earns money. It also fails gracefully. If the custom piece turns out to be wrong, you have lost one component rather than your entire operating system. The discipline the hybrid path demands is sequencing: pick one workflow, ship it, prove the saving, then move to the next. Choosing that first target is the same exercise as deciding which business tasks to automate first.

What should you answer before committing?

Five questions, answered in writing, before you sign anything.

• What specific task or decision gets better, and for whom?
• What does leaving it alone cost us per month, in hours or dollars?
• Does an existing product already do eighty per cent of this?
• Who maintains this in two years, and is that funded?
• How will we know within ninety days whether it worked?

If you cannot answer the second and fifth questions in numbers, you are not ready to build, and possibly not ready to buy either. That is not a failure. It means the next piece of work is a costed baseline, not a software project, and that piece of work is cheap. Owners who do it tend to discover either that a modest integration solves most of the pain, or that the pain is far more expensive than the fix, which makes the decision straightforward. Either outcome beats commissioning a system on the strength of a demo. If you want a vendor-neutral second opinion on whether your next system should be bought, built or simply connected, book a consultation and we will work through the numbers with you.