Auditing your builder tool stack: how to cull software that does not pay

Most builders do not choose a software stack. They accumulate one. A quoting tool bought because a tender was getting away from you. A site diary app a subbie talked you into. A cloud storage plan that started free and now bills monthly. A scheduling product from a trial you forgot to cancel. Each purchase made sense on the day it was made, which is exactly why the stack is so hard to see clearly later.

The cost is not just the subscriptions. It is the time spent moving between tools that do the same job, the version of the truth that lives in the wrong system, and the small monthly debits that never appear in a job costing because nobody allocates them to a job. On a residential job, those debits sit in overheads and quietly raise the rate you need to charge.

This article is about the audit, not the adoption. Choosing software is a separate exercise with its own traps. Reviewing what you already pay for is a maintenance task, and like most maintenance tasks it only happens if it is scheduled and has a method.

Why a tool stack needs an audit at all

A subscription is not a capital purchase. When you buy a nail gun, it sits in the ute and you know exactly what you own. When you buy software, the obligation renews itself, the price changes without a conversation, and the tool keeps working whether or not anyone uses it. There is no moment where the tool forces you to decide whether it still earns its place.

That asymmetry is the whole problem. A tool that is used daily justifies itself loudly. A tool that is used occasionally, or by one person, or not at all since a staff member left, makes no noise. It simply renews. Over a couple of years a builder can be carrying several subscriptions in that category and not be able to name them from memory.

The audit exists to create the decision point the subscription model removes. It forces a periodic answer to two questions: what job does this tool do, and what would happen if we stopped paying for it? If you cannot answer the second question with something concrete, the tool is a candidate.

Start with the annualised number, not the monthly price

The number that matters is what the tool costs across a full year, at the seat count you actually run, with the modules you actually use. Monthly pricing hides scale. A per-user product that looks modest at one seat becomes a different decision at five, and a storage tier that seemed generous becomes a cost once drawings, photos and certificates fill it.

Build the number from the invoices, not from the pricing page. Invoices capture the seats you are genuinely paying for, the add-ons that were switched on during onboarding and never reviewed, and the price increases that arrived by email and were filed without being read. A builder who has never done this will usually find at least one line item they cannot explain.

Group the annualised figures by the job each tool does rather than by vendor. That grouping is what exposes overlap later, and it also shows you where the stack is top-heavy. If most of the annual spend sits in tools that support quoting, that tells you something about where your pain has been and whether the spend matched it.

Map each tool to a job, not to a feature list

Vendors sell features. Builders buy jobs. The useful question is not whether a tool can produce a programme, but whether it is the thing you open when you need to sequence the trades on a job. If the answer is that you open it occasionally and then rebuild the programme in a spreadsheet, the tool is not doing the job it was bought for.

Write down, for each tool, the specific task it supports and the person who owns that task. Quoting and estimating. Programming and trade sequencing. Variations and contract administration. Site records and photo evidence. Compliance documentation. Payment claims and progress certificates. Client communication. Document storage and version control.

This mapping does two things. It shows you tools that support no identifiable job, which are the easiest cuts. It also shows you jobs supported by three tools, which is where the real waste usually sits. The second category is more expensive than the first because it also creates a data problem: when two systems both hold the current variation register, one of them is wrong.

Overlap is where the money and the risk both live

Overlap is rarely deliberate. It usually starts when a new tool is adopted for one job and quietly takes over part of another. A site management product with a photo function arrives alongside the cloud storage you were already using for photos. A quoting tool adds a basic scheduling view, and now there are two places a programme can live.

The cost of overlap is not just the duplicate subscription. It is the reconciliation time, the argument about which version is current, and the exposure when a document that should have been in the job file is sitting in a tool nobody else opens. In a dispute, the question is not which system is better. It is which record is authoritative.

Resolve overlap by deciding, per job type, which single tool is the system of record. Everything else either feeds it or is not needed. If a tool cannot be the system of record for anything, it needs a different justification, such as being the only practical way to do a task that no other tool covers. If it cannot clear that bar either, it is a cut.

Records, retention and the exit you have not planned

The tax office is clear that businesses need to keep records that support what they report, and that these records need to be kept for the period the law requires. Software is often where those records live, which means cancelling a subscription is a records decision before it is a cost decision. If the tool holds the evidence behind your BAS, your job costing or your payment claims, the exit has to preserve it.

That means the export is not optional and it is not something to do after the cancellation. Do it first, open the exported files on a machine that does not have the tool, and confirm you can read and search them. An export that only opens in the product you are leaving is not an export.

Check what format the export produces and whether it preserves the links between records. A folder of loose PDFs is harder to defend than a set of records that still shows which invoice belongs to which job. If the tool cannot produce a usable export, that is a strong argument for keeping it until a job cycle has closed out, or for moving the records into a system you control before you cancel.

Privacy and cyber obligations do not end when the subscription does

Builder software holds personal information: client names, addresses, contact details, sometimes financial information and documents about their property. The Office of the Australian Information Commissioner publishes guidance for small business on privacy obligations, and those obligations attach to the information, not to the tool. Cancelling a subscription does not cancel your responsibilities for what was held in it.

Before you close a tool, deal with access. Remove logins for staff who have left, subbies who no longer work with you, and any account you set up for a trial or a temporary hire. Check whether the vendor retains your data after cancellation, for how long, and whether you can request deletion. Read the clause rather than assuming.

The Australian Signals Directorate publishes small business cyber security guidance, and the account hygiene it recommends applies directly to a shrinking stack. Every tool you keep is an account that can be compromised, and every tool you retire is one fewer. When you cut a tool, cut the account properly: change any shared passwords that were used elsewhere, and confirm the vendor has actually closed the account rather than just stopped billing.

A worked example: the western Sydney builder with nine subscriptions

A builder in western Sydney runs a small residential operation, a handful of jobs at a time, with an office administrator and a site supervisor. Over three years the business accumulated nine subscriptions: an estimating package, a site management app, a cloud storage plan, a scheduling tool, an accounting package, an electronic signature service, a photo storage add-on, a document template library, and a compliance reference service.

Nothing was obviously wrong. Every tool had been bought for a reason. The audit started with the invoices, and the annualised total was higher than the builder expected, largely because the estimating package was billed per user and the cloud storage had been upgraded twice without anyone noticing.

The job mapping exposed the real issue. Scheduling was being done in the scheduling tool by the supervisor and in the site management app by the administrator, and the two never matched. Photos were going into the site app and the cloud storage, depending on who took them. The electronic signature service was used by one person for one client, and the document template library had not been opened since the templates were copied into the estimating package.

The decisions were straightforward once the mapping was done. The scheduling tool was cancelled and the site management app became the single programme, because it already held the rest of the job record. Photo storage was consolidated into the site app, and the cloud storage plan was reduced to the tier the business actually needed for drawings and certificates. The electronic signature service was cancelled in favour of the signing function already inside the accounting package. The template library was cancelled. The compliance reference service was kept, because it was the only tool covering that job and the builder used it on every job.

The point of the example is not the specific tools. It is that the audit found the waste in overlap and in seats, not in obviously bad purchases. Each subscription had been reasonable on the day it was bought. What had changed was the stack around it.

What to do with the savings, and what not to do

The instinct after a cull is to spend the savings on a new tool. Resist that for a full job cycle. The audit has just told you which jobs your stack covers well and which it covers badly. A replacement should be bought against that finding, not against the enthusiasm of a demo.

If a job is genuinely uncovered, treat the purchase as an adoption decision with its own homework: what data it will hold, how it exports, what it costs at your seat count, and how it will interact with the system of record. The related article on getting your team to use the software you paid for works through that side of the problem, and the piece on estimating software switching costs covers what a migration actually takes out of a business.

If a task is genuinely uncovered and no tool is justified, the honest answer is often a documented manual process. A simple register kept in the accounting package, or a folder structure with a naming convention, can cover a job that does not warrant a subscription. The test is whether the process produces a record you could hand to a certifier or an accountant without apology.

Set a review rhythm so the stack does not rebuild itself

The stack will grow again. New jobs create new problems, and suppliers will keep calling. The defence is a scheduled review, not willpower. Put a date in the calendar for the same time each year, ideally before renewals cluster, and run the same method: inventory, annualised cost, job mapping, overlap, retention, export.

Keep the inventory current between reviews. When a tool is added, record what job it does, who owns it, what it costs at the current seat count, and what the export looks like. When a person leaves, remove their access on the day they go. That single habit prevents the most common form of waste, which is paying for seats nobody uses.

Treat the audit as part of running the business rather than a project. It is the same discipline as checking a quote before it goes out or reconciling a payment claim before it is lodged. Keeping your knowledge current is part of the same picture, and the guide to how NSW builder CPD works explains the requirements that apply to licence holders. If you want to build the business side of your practice alongside the technical side, the PointCPD course catalogue lists what is available, and the PointCPD home page is the starting point for NSW builder CPD.

Questions builders ask

• Business
• Software
• Technology

Published 11 July 2026. General information for builders, not legal, financial or engineering advice for a specific job. Check current requirements with the relevant regulator or standard before relying on them.