Key takeaways
- A digital instrument that stores its own readings is only useful as evidence if each reading can be traced to a person, a place, a time and an instrument that was checked.
- Accuracy quoted on the packaging is a manufacturer’s claim, and the builder needs a record that the instrument was checked on the job before anyone relied on it.
- Storage, sharing and export decide whether a record survives the project, the staff turnover and the software company’s next change of plan.
- Cloud apps that hold site photos, addresses and client details need the same basic security and privacy discipline as any other business record.
- A feature list tells you what a tool can do, but the evidence test tells you whether its output will still be believed when a dispute arrives years later.
Measuring tools have changed quietly. A laser level, a digital distance meter or a moisture meter can now store its readings, push them to a phone and attach them to a job. Those features are real, and they save time. The question that matters to a licensed builder is a different one from the question the marketing answers. It is not what the tool can do. It is whether the record it produces will still be believed when someone disputes the work years later.
This article judges these instruments as evidence rather than by their features. It sets out the questions to ask about a reading, the checks that give a record its weight, and the storage and security habits that stop a good record being lost or challenged. It does not compare brands and it does not recommend a product. The same test applies whatever is on the job.
The stake is practical. A reading that cannot be traced is a number nobody can rely on, and a dispute about floor levels, slab thickness or the position of a wall is decided by what can be shown. A builder with a clean record and a documented check is in a far better position than one with a folder of unexplained figures exported from an app.
A reading is only as good as its trail
Every reading has a trail: who took it, with which instrument, at what location, at what time and under what method. A digital tool captures some of that automatically, usually the time and the value, and often misses the rest. The instrument does not know which slab it was pointed at, or whether the person holding it had set it up on the correct reference point. A record that shows only a number and a timestamp is missing the part that makes it defensible.
The practical test is to ask whether a stranger could look at the record and understand what was measured, from where and by whom. If the answer depends on the builder remembering the job, the record is not doing its job. Notes on the job file, a photograph of the set-up and the name of the person who took the reading turn a number into something that can be explained later.
Reference frames matter too. A height reading is only meaningful if the benchmark it was taken from is recorded, and an app that displays a relative level without the datum behind it has lost the most important part of the figure. The same applies to a distance. The point the tape or the laser was measured from needs to be written down, not assumed, because the difference between two faces of a wall is often the whole question.
Calibration and the check that gives a record its weight
Instruments drift. A laser unit dropped off a tailgate, a moisture meter left in a damp cab, or a level knocked out of adjustment will all keep producing readings with complete confidence. The number looks the same whether or not the instrument is still right. The protection is a check: a periodic comparison against a known reference, and a check at the start of the job against a point whose position is known.
The manufacturer’s stated accuracy is a claim about the instrument when it is new and used correctly. It is not evidence about the instrument on your ute today. Keep a simple check record for each instrument, showing the date, the reference used, the result and who did the check. The Australian Building Codes Board’s Evidence of suitability handbook is about how building products and methods are shown to meet the National Construction Code, not about site measurements. Its underlying idea still applies: a claim is only as good as the evidence that can be traced back to its source.
Build the check into the routine rather than treating it as an event. A quick comparison at the start of each job, made in the same place against the same reference, takes little time and produces a record far stronger than an annual certificate kept in a drawer. An annual service is useful, but it does not tell you what happened to the instrument in the ute last week.
Where a reading will be used to decide whether work is acceptable, the method and the tolerance should be agreed with whoever relies on the result before the work starts. A tolerance written into the contract or the plans is far easier to test than one that is argued about after the concrete is down.
Where the data lives and who can reach it
Cloud apps hold a great deal of information a builder would not want made public: site photographs showing the inside of a client’s home, addresses, floor plans, access codes, and the names and contact details of owners and trades. The security basics are not glamorous. Use a separate, strong password for the business account, turn on multi-factor sign-in where the service offers it, keep the phone and the app updated, and make sure anyone who leaves the business loses access the same day. The Australian Signals Directorate’s small business hub sets out the basics in plain language.
Privacy is the second obligation. Some small businesses are covered by the Privacy Act, and the Office of the Australian Information Commissioner’s guidance for small business explains when. Even where the law does not bind a particular business, the client expects their address and their home to be handled with care. Decide what is stored, who can see it and how long it is kept before the first job is loaded, rather than after the first complaint.
Think about who else can see the data. A subcontractor given access to the app may be able to see every job and every client. Where the app allows it, give access by job rather than by account, and remove it when the trade has finished. An owner who asks for copies of the records should receive the relevant readings, not the whole project database.
Monitoring the worker as well as the work
Some instruments and apps record more than the measurement. They log which device was used, when, and sometimes where, and some show how long a task took. That data is about the worker as much as it is about the job. Safe Work Australia’s guidance on digital technologies is a useful reference for thinking about how workplace data is used as part of work health and safety. Tell the crew what the tool records, use the data for what it was collected for, and keep it out of performance discussions unless the arrangement has been agreed in advance.
The same caution applies to location features. A tool that records where a device was at the time of a reading is useful when the location is part of the evidence. It becomes intrusive when it runs continuously, and a builder who wants the benefit without the surveillance should switch off whatever the job does not need.
Storage, export and the test of time
The record needs to outlive the app. A builder who has years of readings in a platform that changes its pricing, its file format or its ownership has a problem on the day the records are needed. Before a tool is relied on, check that the readings can be exported in an ordinary format, that the export carries the trail of who, when, where and which instrument, and that the job file holds a copy. Backups are part of the same discipline, and a copy kept on the job file and in the business’s own storage is cheap insurance.
When a job closes, decide what happens to its records before the app’s storage fills up or the subscription lapses. Defect periods and the time allowed for claims run for a long while after handover, and the records need to be kept for that whole period. Archive the closed job in an ordinary format that does not depend on the app being paid for, and check that the archive opens on another machine.
Name files and folders so they make sense to someone who was never on the job. A file called final levels, with no date and no job reference, is hard to rely on however good the reading inside it may be. A simple habit of job number, date, instrument and the name of the person who took the reading makes a record findable years later.
Worked example: floor levels recorded on a south-west Sydney job
A builder in south-west Sydney recorded the floor levels for a new house with a digital level before the slab was poured. The readings were stored in an app, the crew took them on a set grid, and the builder printed a summary for the job file. A year after handover the owners complained that one room sloped towards the rear wall, and their building consultant asked for the levels to be checked against the approved plans.
The app showed the readings, but it did not show a check of the instrument on the day. The builder could not say which reference point the readings had been taken from, and he had no record that the level had been checked against a known point before the pour. The consultant’s own survey became the evidence, and the dispute turned on that rather than on the builder’s readings. The records were not wrong on their face. They were simply unable to carry the weight the builder had assumed they would.
The fix was procedural rather than technical. Each instrument now has a check record, the reference point is written on the level sheet for every job, and the summary includes the method as well as the numbers. The app is still used. What changed is that the record can be explained by someone who was not on the site, which is the test that matters when a complaint arrives.
The owners were not unreasonable to ask. A sloping floor is a visible problem, and the builder’s first instinct was to defend the readings. The more useful response was to accept the survey as the starting point, and to work out with the engineer whether the slope fell within the tolerance the plans allowed, and what, if anything, needed to be done about it.
Testing a tool before you rely on its output
Before a tool goes onto the job, run the same questions as the worked example. Take a reading of a known reference, record it the way the crew will, and check that the export carries the trail. Confirm who can edit the record and whether an edit leaves a mark. Decide how often the instrument will be checked and write that down. A tool that passes these questions is useful. A tool that produces only attractive dashboards is a convenience, and it will not help in a dispute.
Give the test to someone who did not set the tool up. A check that only the person who chose the instrument can follow will miss the steps that are taken for granted. Ask a second person to take a reading following only the written method, and see whether they get the same result and can explain how they got it.
Test a tool before it goes on the job
- 1Check a known referenceTake a reading of a point with a known position and record it the way the crew will.
- 2Trace the recordConfirm the reading shows who took it, which instrument was used, where and when.
- 3Test the exportExport the readings in an ordinary format and check that the trail survives the export.
- 4Lock down accessConfirm who can edit a record, and whether an edit leaves a visible mark.
- 5Set the check scheduleWrite down how often each instrument is checked, and who does the check.
Judging the tool by what the record proves
A feature list tells you what a tool can do, and the evidence test tells you whether its output will be believed. The two often point in different directions. A product that connects to everything and produces a neat dashboard may leave the builder with records that cannot be checked, while a plainer instrument with a check record and a clean export may serve the job better for years.
There is a cost side as well. A tool with a monthly fee, a subscription for each user and an export that is slow to produce is a running cost that has to be justified by the evidence it supports. For a small builder the sensible question is not which tool has the most features, but which one the business will still use, and still be able to read, after the subscription has been renewed many times.
Judging a tool by its evidence, not its features
| What the marketing emphasises | What the record must show |
|---|---|
| A connection to an app on the phone | Who took the reading, which instrument, where and when, and that it cannot be edited quietly |
| Automatic cloud sync | Where the data is stored, who can reach it, and whether it can be exported in full |
| Accuracy quoted on the box | Evidence that the instrument was checked against a known reference on the job |
| Charts and dashboards | The method used, and readings that can be explained by someone who was not there |
Lead in. The mistake that costs the most is treating a clean-looking app record as proof, when nobody can show that the instrument was checked and the reading traced back to a known point.
For a companion piece on how site photographs and written notes support the same kind of evidence, read the article on site photo record keeping.
The broader question of how records fit into a project’s systems is covered in the article on construction project management software, which looks at the same storage and access questions from the project side.
The PointCPD guide to NSW builder CPD sets out how the professional side of keeping records fits into the wider renewal picture for licensed builders.
Questions builders ask
Are readings from a digital measuring tool acceptable evidence on a building site?
They can be, provided each reading can be traced to a person, a place, a time and an instrument that was checked. A number with a timestamp and nothing else is weak evidence, however neatly it is presented. The strength comes from the trail around the reading.
Does the accuracy printed on the instrument mean I can rely on it?
Not on its own. A stated accuracy describes the instrument when it is new and used as the manufacturer intends. Instruments drift after knocks and damp, so a check on the job against a known reference is what gives the reading its weight.
How often should an instrument be checked?
Often enough to catch the knocks and drops that happen on a site, at an interval you have written down and can explain. The right interval depends on how hard the instrument is used, and it is better to set it in advance than to check only when someone asks.
Do I need to tell the crew what the app records about them?
Yes. If a tool logs which device was used, when and sometimes where, the crew should know what is recorded and why. Use the data for the purpose it was collected for, and keep it out of performance discussions unless that has been agreed in advance.
Is it safe to store client photos and addresses in a cloud app?
It can be, with the basic security steps in place: a strong, separate password, multi-factor sign-in where it is offered, updated devices, and access removed promptly when a person leaves. Decide what is stored, who can see it and how long it is kept before the first job is loaded.
What happens if the app company changes its terms or closes?
Export the records regularly in an ordinary format, with the trail intact, and keep a copy on the job file and in the business’s own storage. A record that can only be read inside a platform you no longer control is not really your record.
Sources
- Digital technologies and AI · Safe Work Australia
- Continuing professional development for builders and swimming pool builders · NSW Government
- General building work licensing · NSW Government
Published 24 September 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.
