Every growing business hits the same fork. You have outgrown the spreadsheet, the off-the-shelf tool no longer fits the way you actually work, and someone in a meeting asks the question that starts a thousand arguments: should we buy a ready-made product or build our own? The choice between custom software vs off the shelf SaaS is rarely about technology. It is about where your business is genuinely different, and where it is the same as everyone else.
In our work with Australian small businesses, we have found the build vs buy decision goes wrong in one of two directions. Some owners build a bespoke version of something they could have bought for a fixed monthly fee, then spend years maintaining it. Others stitch together a dozen subscriptions to approximate the one workflow that is supposed to be their edge, and wonder why it feels generic. Both mistakes come from skipping the first question.
Start with strategy, not software
Michael Porter made the point decades ago in Harvard Business Review: operational effectiveness is not strategy. Competitive advantage comes from performing different activities than rivals, or performing similar activities in different ways. That single idea is the cleanest test we know for build vs buy software.
Buy the commodity. Build the differentiator. Integrate them.
Most of what your business does is undifferentiated. Email, accounting, payroll, payments, calendars, file storage: doing these in a unique way wins you nothing, because your customers do not choose you for your general ledger. Software as a service is already the most common paid cloud service among Australian businesses that use the cloud, and buying it for these functions is the right call. A specialist vendor will out-invest you on features, security, and reliability for any capability that thousands of other companies also need.
Then there is the part of your business that is actually yours. The specific way you quote a job, route a lead, schedule a crew, price a custom order, or move a customer from enquiry to delivery. If that workflow is your edge, generic software will always fit it like a suit bought off the rack: close enough to wear, never quite right. That is where a custom build earns its keep, because you are encoding the thing competitors cannot copy from a feature list.
What off the shelf software does well
Off the shelf software is a genuinely good deal for commodity capability. You get a product that is already built, already tested, and improved continuously by a team whose whole business is that one tool. Time-to-value is measured in days. The vendor carries the maintenance, the security patching, and the uptime. According to the Australian Bureau of Statistics, software was the most common paid cloud service among Australian businesses using the cloud at 85% (2015-16 reference period), and cloud use rose with size, from 25% of micro-businesses to 60% of those with 200 or more staff. Buying the commodity is already mainstream practice, and for table stakes rather than competitive advantage it is hard to beat.
The trade-off is fit. SaaS is built for the average of its market, so you adapt your process to the product rather than the other way around. For a commodity function that is fine, because you have no special way of doing payroll worth protecting. The friction starts when a tool meant for everyone is asked to carry the workflow that makes you different. You end up with workarounds, manual exports, and a spreadsheet quietly holding the whole thing together. We see this pattern constantly: a capable, well-priced tool doing eighty per cent of the job, and the most valuable twenty per cent, the part that is actually your business, living in side processes that nobody owns and nobody can scale.
What bespoke software does well
Bespoke software fits your process exactly, because it is built around how your business actually runs rather than the vendor's assumptions. It connects cleanly to your other systems, the data stays under your control, and it can do the specific thing no product on the market does. Done well, custom software for small business is not a cost centre. It is the operational version of your strategy, the part competitors cannot subscribe to.
The honest trade-off is responsibility. A custom build is an asset you own and therefore an asset you maintain. It needs hosting, monitoring, updates, and an owner. We are direct with clients about this: do not build the thing you could buy, because every line of bespoke code is something to look after. Build the thing that is genuinely yours, and the maintenance is a fair price for an advantage no subscription can give you.
This is also where the economics have shifted. Building bespoke software used to be slow and expensive enough that buying nearly always won on speed alone. AI-assisted development has changed that maths. In a controlled GitHub study, developers using an AI pair-programming assistant completed a task 55.8% faster than the control group. Lean, AI-enabled agencies can now deliver custom builds in a fraction of the old timeline. To be clear, this is about fit and capability, not cheapness: good custom work is still a premium investment, but the bar for when building makes sense has come down. This shift is part of a broader change we cover in the future of custom solutions.
Software total cost of ownership, not the sticker price
The most common mistake on both sides of this decision is comparing the wrong numbers. A SaaS subscription quote and a custom build quote are sticker prices. Neither is the real cost.
Total cost of ownership is the financial estimate of the direct and indirect costs of a product over its life. The principle, as the definition puts it plainly, is that ownership costs are significantly greater than the cost of acquiring something. The lowest upfront price is not the lowest total cost.
For SaaS, the sticker price is the per-seat monthly fee. The real cost adds per-user pricing that climbs as you grow, tier jumps to reach one feature you need, integration and data-export costs, the staff time spent on manual workarounds, and the price of switching later. For a custom build, the sticker price is the project quote. The real cost adds hosting, monitoring, maintenance, and future changes. A fair build vs buy comparison runs both over three to five years, including the workflow fit. A subscription that looks cheap monthly can cost more in lost efficiency than a build that fits properly.
Vendor lock-in, switching costs, and data ownership
Vendor lock-in is the factor most often missing from the spreadsheet. Every tool you adopt makes the next decision harder, because your data, your processes, and your team's habits accumulate inside it. The question is not whether you will have switching costs, but how large and how foreseeable they are.
Ask three things of any option. Where does your data live, and can you get it out in a usable format? How hard is it to move to a different system in two years? Who controls the integration points that connect this tool to the rest of your stack? Buying SaaS often means accepting the vendor's answers. Building means you set them, which is part of what you are paying for.
Data ownership carries legal weight here, not just operational. Under the Australian Privacy Principles, your business is accountable for how personal information is collected, used, secured, and made accessible, regardless of whether the system holding it is custom-built or off the shelf. A tool that makes data hard to export or unclear to govern is a lock-in risk and a compliance risk at once. Where customer data is concerned, knowing exactly where it sits and who controls it belongs in the decision from the start.
Do not forget the maintenance and the AI surface
Maintenance burden cuts both ways, and AI features sharpen the point. If you build an AI-enabled tool, you own its ongoing behaviour. If you buy a SaaS product with AI baked in, you inherit its risks without controlling them. Either way there is a real surface to manage, and that is increasingly true as more tools add agentic AI that acts on your behalf.
The documented risks are specific. The OWASP Top 10 for Large Language Model Applications lists issues such as prompt injection, sensitive information disclosure, and model theft. Managing them is ongoing work, not a one-off setup. Frameworks exist precisely because this is now standard responsibility: the NIST AI Risk Management Framework is a voluntary standard for building trustworthiness into AI systems across their design and use. A true total-cost view budgets for this governance whether you build or buy, and measuring AI ROI covers how to value these systems honestly.
A decision checklist for build vs buy
When a client is weighing build vs buy, we work through a short list of questions. The pattern in the answers usually makes the call obvious.
- Is this capability your differentiator or a commodity? If a customer would never notice how you do it, buy it. If it is part of why they choose you, building deserves serious thought.
- Does an off-the-shelf tool fit your real workflow, or would you reshape your business to fit the tool? Adapting to a product is fine for commodities and costly for your core process.
- What is the three-to-five-year total cost of ownership of each option? Compare lifetime cost and fit, not the monthly fee against the project quote.
- How severe is the lock-in? Check where data lives, how exportable it is, and what switching in two years would actually take.
- Who carries the maintenance and the security surface, and can you? Be honest about whether you have the capacity to own a build, including its AI risks.
- How fast do you need value, and how stable is the requirement? Urgent and standard favours buying. Stable and strategic favours building.
The usual answer is hybrid
For most small businesses the honest answer is not build or buy. It is both. Buy the commodities, build the one or two workflows that are genuinely your advantage, and integrate them so data flows cleanly between the two. A hybrid only delivers if the bought tools and the built workflow share data cleanly, so getting integrations right matters more than any single product choice. The connective tissue is worth as much care as either piece on its own.
This is the approach we take at Enki. We do not start by recommending a build or a subscription, because the right answer depends on where your advantage actually sits. We start with what makes your business different, treat the rest as commodity to be bought well, and build only the part that earns it. Our own lead-management system is exactly this pattern: a bespoke build for the workflow that was the client's edge, which saved more than 1,500 hours a month and now generates reports automatically. Sometimes the right answer is our own templated product. Sometimes it is a custom build. Usually it is a considered mix of both, chosen for fit rather than ideology.
If you are weighing this decision right now, the most useful next step is rarely picking a vendor or a developer. It is getting clear on which parts of your business are commodity and which are genuinely yours. The rest follows from that, and we are happy to help you draw that line.