For most small businesses the answer is to buy. Buy when a product does nearly everything you need once it's set up and your process is standard. Connect or configure when two tools you already pay for just need joining up. Build when the process is specific to how you make money, the task eats 10 or more hours a week, the rented product will cost more over five years than owning something that fits, or your data is trapped in a system you can't get it out of.
When should you buy off the shelf?
Buy when the process is the same in your business as in everyone else's. Accounting, payroll, rostering, email marketing and phone systems are solved problems. The products that do them are used by many businesses, which find the bugs before you do, and the vendor keeps up with rule changes so you don't have to.
The test is simple. Set the product up properly, then watch your team use it for a few weeks. If the gaps are small and cheap to live with, stop there. A product that fits nearly everything is a better deal than any build, and we'll tell you that in the first meeting.
When is connecting two tools enough?
Before anyone builds anything, try the middle option. A lot of admin pain is two systems that don't talk to each other: a form that someone retypes into the CRM, an invoice that gets keyed into the accounting system, a booking that has to be copied into a calendar.
Three places to look first:
- Built-in integrations. Most business software already connects to the common accounting, email and calendar tools. Check the settings or the app marketplace before paying for anything.
- Automation tools. Zapier and Make join tools together with "when this happens, do that" rules, without writing code.
- Configuration. Custom fields, templates, automations and permission settings in the tools you already pay for often close the gap.
If the task sits in the 5 to 10 hours a week range, this is usually where the fix is. It's cheap, it's quick, and if it doesn't work you've lost very little.
When does building make sense?
Building earns its place in four situations:
- The process is how you make money. Your quoting, your job flow, your reconciliation, your client service. If the way you do it is part of why customers choose you, a generic product will flatten it.
- The task eats 10 or more hours a week. That is a reason to calculate the likely saving, not proof the build will pay for itself. Include hosting, support and the time your team spends adopting it. We set out the arithmetic in what your admin actually costs you.
- Renting costs more over five years than owning something better. Per-seat pricing, add-ons and price rises add up. Do the sum over five years, not one.
- Your data is trapped. If your customer history lives in a product you can't export from, every year you stay makes leaving harder.
That last one is common. We are building a workshop management system for an automotive workshop to replace a rented system the workshop didn't control. It covers bookings, job cards, invoicing and SMS reminders, on the workshop's own database.
A quick scoring checklist
Give yourself one point for each statement that's true. It's a prompt for a conversation, not a formula.
| Statement | Point |
|---|---|
| The process is specific to how you make money | 1 |
| The task takes 10 or more hours a week across the team | 1 |
| Your team keeps the real process in spreadsheets beside the software you pay for | 1 |
| You've tried configuring or connecting your tools and people still retype data | 1 |
| The rented product will cost more over five years than building and running something that fits | 1 |
| You can't get a usable export of your own data | 1 |
| Your software bill is growing faster than your team | 1 |
| Someone in the business can own the process and make decisions during a build | 1 |
0 to 2: buy, or fix the workflow. 3 to 4: configure and connect first, then check again in three months. 5 or more: it's worth pricing a build. If the last statement isn't true, wait: a build without an owner on your side stalls.
What are the hidden costs on each side?
Both options cost more than the headline price. The difference is which costs you can see coming.
Renting:
- Per-seat creep. Every new hire adds a licence. Businesses are watching this: Gartner forecasts Australian organisations will spend almost A$16.4 billion on software-as-a-service in 2026, up 13.8 per cent, with organisations prioritising licence optimisation and slower seat growth.
- Price rises you don't control. Vendors raise prices, and good products do it too. Xero's Comprehensive plan in Australia went from $100 to $107 a month, a 7 per cent rise, and that's the price on Xero's site now. Across the market, software buying platform Vertice put SaaS price inflation at 16.4 per cent in June 2026, its highest monthly reading.
- Workarounds. The hours your team spends in spreadsheets around the product are a cost of the product, even though they never show up on the invoice.
- Data lock-in. Check whether you can export your records in a format another system can use, before you need to.
Building:
- Maintenance. Software needs updates, fixes and changes as your business changes. Australian agencies such as Hatchet budget 15 to 20 per cent of the build cost each year.
- Key-person risk. If one developer holds everything in their head, you're exposed. Ask who else can maintain it, and what happens if the supplier stops trading.
- Support. Someone has to answer when it breaks. Agree the support arrangement, and its price, with the build.
- Your own time. Scoping and testing need the people who do the work. Budget their hours too.
How do you reduce the risk of a build?
The biggest risk in a build is starting too big. Four habits lower it.
Start with one task. A first build should aim to save one person about three hours a week. The three-hour rule explains why small ships and big stalls.
Fix the scope and the price. Agree in writing what will be built, what it connects to, the price and the date before any code is written. That's how we work on custom software, with the price paid in milestones.
See working screens early. Ask to see the software working during the build, not only at the end. Problems are cheap to fix in week two and expensive in week ten.
Read the ownership and exit terms. Ask who owns the data, what happens if support ends, and how you get your records back. Under our terms you own your data, your configuration and everything the system produces, and you get a perpetual licence to use the software. If support ends, your licence continues. On request we export your data in a standard machine-readable format. If we stop trading, you get the source code so someone else can maintain it. Our pricing page covers the rest.
Where does AI change the maths?
AI makes some builds worth doing that weren't before. It's good at narrow, checkable tasks: pulling figures out of a statement, drafting a file note from a transcript, sorting incoming emails, matching records that are written slightly differently. Those tasks used to need a person because the inputs were messy. Now a build can do the first pass, and a person checks it.
The key word is checkable. If someone can look at the output and tell in a minute whether it's right, AI can save real time. If the task needs judgement nobody can check quickly, AI adds risk rather than removing work. A person should still review anything a client or a regulator will see.
AI also changes the buy side. Many products now ship AI features of their own. Try those first. If they do the job, you don't need a build.
Frequently asked questions
Is custom software better than off-the-shelf? Not by default. Off-the-shelf is better for standard processes because it's cheaper, already tested by other businesses and maintained for you. Custom wins when the process is specific to how you make money and the gaps cost real hours.
What's the cheapest way to fix software that doesn't talk to each other? Usually a built-in integration or an automation tool like Zapier or Make. Try that before paying for a build.
How long does a custom build take? Focused builds we've quoted have run two to six weeks. Bigger systems take longer, and the date should be written into the scope before work starts.
What happens to my data if I leave a software provider? It depends on the contract, so check before you sign. Ask whether you can export everything in a standard format, and what happens if support ends or the provider stops trading.
Can AI replace the software we rent? Rarely on its own. AI is best at narrow tasks inside a process, with a person checking the result.
Not sure which side of the line you're on? Book a free 30-minute chat. If a product you can buy will do the job, we'll tell you.