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.
This article runs the decision the way we run it with clients: a strategy test first, then five criteria with a verdict on each, then a short exercise you can perform on one of your own workflows this week.
What the build vs buy decision actually is
Build vs buy is the choice between subscribing to ready-made software as a service and commissioning custom software built around your own workflow. Buying gets you a product shared with thousands of other companies, live in days. Building gets you an asset shaped to one company: yours. Either way you are almost certainly getting a web app, software your team opens in a browser rather than installs, so the difference is who it was built for rather than how you reach it.
Our framework fits in a sentence: buy the commodity, build the differentiator, integrate them. The rest of this article is the evidence for that sentence.
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.
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. 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. Done well, custom software for small business is the operational version of your strategy, the part competitors cannot subscribe to.
Verdict: the strategy test decides which conversation you are having. A commodity capability should almost never be built. A genuine differentiator should almost never be squeezed into a generic tool.
Five criteria, five verdicts
The strategy test sorts most capabilities immediately. For the cases left in the middle, we score both options against five criteria.
Time to value
Off the shelf software is a genuinely good deal on speed. The product 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, and the vendor carries the uptime. Buying is also mainstream practice rather than a novelty: 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.
A custom build cannot match that. Even a tightly scoped project needs discovery, design, and testing before value arrives. AI-assisted development has compressed the timeline, but built still means weeks where bought means days.
Verdict: buying wins on speed, always. If the need is urgent and the requirement is standard, buy, and save the remaining criteria for the workflows that matter over years.
Workflow 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. We see the same 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.
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, and it can do the specific thing no product on the market does.
Verdict: for commodities the fit gap is cosmetic, and buying wins. For the workflow that is your edge, fit is the whole argument, and building wins.
Total cost of ownership
Here sits the most expensive misconception in the decision: the belief that the monthly fee is the cost of SaaS and the quote is the cost of a build. Both are sticker prices, and comparing them is comparing two wrong numbers. Total cost of ownership is the financial estimate of the direct and indirect costs of a product over its life, and the principle, as the definition puts it plainly, is that ownership costs are significantly greater than the cost of acquiring something.
Run the arithmetic on a plausible example. Eight staff on a $79 per user per month plan costs $7,584 a year, roughly $38,000 over five years, before any tier jump to reach one missing feature, per-user price rises as you hire, integration fees, or the staff hours spent on manual workarounds. A custom build reverses the shape: the quote lands upfront, then hosting, monitoring, maintenance, and future changes continue at a lower rate. Neither shape is automatically cheaper. The mistake is comparing a month against a project instead of five years against five years.
The build side of the equation has also moved. In a controlled GitHub study, developers using an AI pair-programming assistant completed a task 55.8% faster than the control group, and lean, AI-enabled agencies can now deliver custom builds in a fraction of the old timeline. This is about fit and capability rather than cheapness: good custom work is still a premium investment, but the bar for when building makes sense has come down, a shift we cover in the future of custom solutions.
Verdict: neither side wins by default. Compare both options over three to five years, including workaround hours and exit costs, and distrust any comparison built on sticker prices.
Lock-in 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.
One more belief needs correcting here: buying software does not outsource your privacy obligations. 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.
Verdict: building wins on control and portability. If you buy, get the vendor's answers on export, APIs, and data location in writing before you sign, not after.
Maintenance and the AI surface
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. Buying moves that work to the vendor, which for commodity software is precisely what you want.
AI features sharpen the point on both sides. 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, which matters more as 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, and managing them is ongoing work rather than one-off setup. The NIST AI Risk Management Framework exists precisely because this is now standard operational responsibility. 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.
Verdict: buying wins if you cannot resource an owned asset, and there is no shame in that answer. Build only what you can maintain, and budget the AI governance either way.
The scorecard
| Criterion | Buying wins when | Building wins when |
|---|---|---|
| Strategic fit | The capability is a commodity | The workflow is your edge |
| Time to value | The need is urgent and standard | The requirement is stable and long-term |
| Workflow fit | Adapting your process costs nothing | Adapting would blunt your differentiator |
| Five-year cost | Seats are few and needs are standard | Per-seat fees and workarounds compound |
| Lock-in and data | Export and API answers check out | Control and portability are non-negotiable |
| Maintenance | You cannot own an asset yet | You can resource what you own |
Run the decision on one workflow this week
Theory settles nothing until it meets your actual workflow. This exercise takes a few hours spread across a week, and it produces a decision you can defend.
- 1.Pick the workflow with the most workarounds, usually the one held together by a spreadsheet everyone is afraid to touch.
- 2.Shadow the person who runs it and write down each step as it actually happens, naming the tool used at every step. Record the real process, not the official one.
- 3.Count the manual handoffs: every export, rekey, and copy-paste between systems. Each one is a cost and an error source the current tools are not absorbing.
- 4.Pull twelve months of software invoices from your accounting system and total what the tools touching this workflow already cost per year.
- 5.Ask each vendor three questions in writing: can we export all our data in a standard format, is there an API our other systems can use, and what does pricing look like at double the seats. Slow or vague answers are also answers.
- 6.Score the workflow against the five criteria above. A commodity with clean vendor answers is a buy. A differentiator failing on fit and five-year cost is a build candidate worth scoping properly.
The expected result is clarity about one workflow, and a repeatable method for the rest. In our experience the numbers from steps three and four surprise owners more than any sales pitch, because the cost of staying put is usually larger than anyone had written down.
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.