The construction software checklist,
written to be used against us too.

This is deliberately not a weighted scoring matrix. Scoring matrices produce a winner with a decimal point on it and hide the fact that one unanswered question about data ownership matters more than nine ticks in a feature column. Work through the sections in order instead, write down the actual answers, and pay attention to which questions the vendor answers precisely and which ones they answer around.

Two rules make the rest of it work. Shortlist two or three products, not seven, because the depth of evaluation is what produces information and you cannot do this properly seven times. And run the same questions against every product, in the same order, including any product you are already leaning towards. The purpose of a checklist is to stop your preference doing the evaluating for you.

The category-by-category detail behind these questions sits in the buyer’s guides linked at the bottom of this page, and the wider decision framework is in the guide to choosing construction software. This page is the working document.

Most bad software purchases are decided before the first demo, by starting with products rather than with the problem. Answer these about your own business first, on paper, and take the answers into every call.

• Name the three tasks that hurt. Not the wish list. The three specific activities that cost you time or money every week. If a product does not clearly improve at least two of them, it does not matter how good the rest of it is.
• Count the re-typing. How many times a day does someone in your business enter a number that already exists somewhere else. That count is the single best predictor of whether you need a connected system or a better point tool.
• Write down who has to use it. Office administrator, estimator, site supervisor, subcontractors, clients, your accountant. Software that suits the office and defeats the supervisor fails, because the site record is where the value is.
• Decide what the accounting seam looks like. Are you keeping your ledger and adding a construction layer on top, or replacing both. That decision narrows the field faster than any feature comparison, and it is covered in the construction accounting guide.
• Establish your real budget, including your own hours. The subscription is usually the smaller number. Implementation, data preparation, training and the productivity dip in month one are the rest of it.
• Pick the job you will test with. One real job, preferably one that went sideways, with its variations, its awkward invoices and its difficult client. That job is your benchmark across every product you look at.

Ask these during the trial, not at renewal, and insist on demonstrating the answer rather than reading the policy. The ability to leave is what keeps a vendor honest for the whole time you stay.

• Can I export everything, myself, today. Not on request, not as a support ticket, not for a fee. Run the export during the trial and open what comes out.
• Does the export keep the relationships. A pile of flat CSVs where you cannot tell which invoice belongs to which order on which job is technically an export and practically a shredder. Check that the links survive.
• Do documents and photos come too. Site photos, signed variations, certificates and plans are the records that matter years later. Ask specifically whether they are included and in what structure.
• Who owns the data, in the contract. Read the clause. Ownership, licence and the vendor’s right to use your data, including whether it may be used to train anything, should be explicit rather than implied.
• What happens on cancellation. How long is the account readable, how long before deletion, and can you get an export after you stop paying. Get the window in writing.
• Where is it hosted and who can see it. Data location matters for Australian businesses, and internal access controls matter more than most buyers ask.
• What happens if you are acquired. Not an accusation, a normal question. Ask what the notice period and export window would be if the product were sold or discontinued.

Integration is the most over-claimed word in software. The presence of a logo on a website establishes almost nothing. Test the specific behaviour you need.

• Push a real record through during the trial. Approve a supplier bill and go and look at it in your accounting package. Check the job coding, the tax treatment, the description and the supplier match.
• Establish which direction it flows. One-way, two-way, or two-way for some record types only. Ask specifically about contacts, bills, invoices, payments and the job or tracking dimension.
• Test what happens on a conflict. Change the record on the accounting side and see whether the construction system detects it, overwrites it, or never notices. Silent overwriting is worse than no sync at all.
• Ask what happens when the connection drops. Do records queue and retry, or fail quietly. Ask to be shown where failures surface.
• Check the Australian specifics. GST treatment, BAS-relevant reporting, and whether the job dimension arrives as something your accountant can actually report on. The detail is in the Xero-specific guide.
• Ask about everything else you use. Bank feeds, payroll, takeoff software, storage. If an integration you need does not exist, ask whether there is an API and who would build it.

The gap between good software and a good outcome is implementation. These questions get asked far too late by most buyers.

• Ask for the implementation plan in writing. Named stages, who does what, and an honest estimate of the hours your own team will need to contribute.
• Establish what data migrates and what does not. Cost codes, rates, contacts, suppliers, open jobs, historical jobs. Ask specifically about jobs already mid-flight, because a builder never gets to start on a clean slate.
• Ask what a partial go-live looks like. Most builders should start with one module on one job. A vendor who only knows how to switch everything at once has not implemented for a business your size.
• Find out who you deal with after the sale. By name and role. Ask whether the person selling to you is involved after handover.
• Establish the support model and hours. Australian hours or offshore, chat or phone, and the actual response time rather than the marketing one. Ask what happens at four on a Friday when claims are going out.
• Ask how you get trained, and how the next hire does. Onboarding for the founding team is the easy part. What happens for the administrator who starts in eighteen months decides whether the system survives.
• Get the total annual cost in writing. Subscription, per-user charges, modules, implementation, integration fees, storage, support tiers, and what it looks like after any introductory period ends.
• Ask how often it changes. Release cadence, whether changes arrive without notice, and how you find out. A product that improves constantly is good. A product that moves your team’s workflow without telling them is not.

When the demos are done and the notes are in front of you, three questions decide it more reliably than any total.

• Which product did the awkward parts of my job best. Not the demo script. The variation approved by text, the invoice with no order number, the trade who quoted differently to how you budgeted. Everything can do the clean case.
• Which vendor answered the uncomfortable questions straight. Data export, what they refuse to automate, what they do not build, and what is planned rather than shipped. Precision under an awkward question is the best available proxy for how a vendor behaves when something goes wrong.
• Which one will my site supervisor actually use. The office will use whatever it is told to use. The field will not. A system the field abandons produces no record, and a system with no record produces no benefit no matter how good the office screens are.

Then call references you chose rather than references you were given, ask them what they wish they had known, and ask what took longer than expected. Almost every builder answers that second question the same way, which is useful in itself.