Choosing scaffolding software: what to look for

There is no shortage of software that will let a scaffolding contractor schedule a job and raise an invoice. There is much less that understands a structure as a thing with a design, a handover, an inspection clock and a history of alterations — which is the part of the work that actually carries risk.

Questions that separate the two

• –Is the structure a first-class record, or just a line on a job? If inspections attach to the job rather than the structure, the inspection clock will be wrong the first time a site has two scaffolds.
• –Can it hold the design — compliance sheet or bespoke — against the structure, and show it to whoever is inspecting?
• –Does the inspection interval run from the last inspection of that structure, with a reminder before it falls due?
• –Can an adaptation be logged on site, and does it change what the next inspection starts from?
• –Do handover certificate, tag status and loading class come from one record or three?
• –Does it track card and medical expiry per operative, with enough notice to book a course?

Questions about the vendor, not the product

• –What does it cost at the size you will be in two years — per user, per contract, or flat?
• –Can you export your records while the account is active, and in what format?
• –Who owns the data, stated plainly in the terms rather than implied in a sales call?
• –What is actually committed in writing — uptime, support response, hosting location — and what is a target?

That last one is worth pushing on. A vendor that will tell you plainly what it does not offer is a vendor whose other answers you can rely on. Our own specification page is written that way deliberately, including the rows where the honest answer is "not currently offered".

A note on 3D

A 3D builder is genuinely useful — it puts a drawing in the hands of the squad rather than a description, and it makes an unusual configuration obvious before the wagon is loaded. It is not a design package, and any vendor implying that a modelling tool removes the need for a competent designer on a bespoke structure is telling you something about the rest of their claims. A useful test: ask the vendor what a transom is for. A product built for this trade will have someone who can answer without checking.

Test it against the messy job

Scaffolding software demonstrates well on a clean job: one structure, a straightforward take-off, no variations. The job worth modelling is the opposite — several structures on one site, a design change mid-contract, three adaptations requested by other trades, a section struck early, and a variation the client disputes.

That exercise tends to reveal quickly whether a product connects the parts of the job that are actually connected: the meterage and the price, the adaptations and the variations, the structures and their inspections.

Common mistakes

• –Evaluating on a simple job rather than the most complex one you run
• –Assessing modules separately without testing whether they connect
• –Not testing capture from site, where signal and conditions are worst
• –No way to link an adaptation to the variation it should generate
• –Deciding without involving a chargehand who will use it daily
• –Comparing headline prices without checking what scales per user or per job

Worth knowing: the pilot tells you more than the demo

Vendors demonstrate; what you need is evidence from your own jobs. A fortnight running one real contract — including its site capture, its adaptations and its invoicing — produces information no demonstration can, because it exercises the parts of your operation the vendor did not design a script around.

Insist the pilot includes a chargehand actually using it on site, in ordinary conditions, rather than a manager evaluating it from an office. Site usability is the single largest determinant of whether a scaffolding system delivers anything, and it is the hardest thing to judge from a screen share.

• –Pilot on a real contract, not a demonstration dataset
• –Include site capture in poor weather and poor signal
• –Have the people who will use it daily form the judgement
• –Agree in advance what would count as a failed pilot

Where this connects: run a pilot, not a demonstration

A demonstration shows a product succeeding on data chosen to make it succeed. What a firm needs is evidence from its own jobs, and a fortnight running one real contract — its site capture, its adaptations, its invoicing — produces information no scripted demonstration can, because it exercises the parts of the operation the vendor did not design around.

Insist a chargehand uses it on site in ordinary conditions rather than a manager evaluating it from a desk. Site usability is the largest single determinant of whether a scaffolding system delivers anything, and it is the hardest thing to judge from a screen share on a good connection.

• –Pilot on a real contract rather than a demonstration dataset
• –Include site capture in poor weather and poor signal
• –Let the people who will use it daily form the judgement
• –Agree in advance what would count as a failed pilot
• –Model your most awkward job, not your most typical
• –Ask to see an overdue or incomplete record, not a tidy one