Is scaffolding software worth it for a small firm?

Most buying guides in this market are written on the assumption that the answer is yes. For a firm with two gangs, a working owner and a bookkeeper who comes in on Thursdays, it frequently is not — and a system bought too early is worse than no system, because it adds administration to a business that was coping.

The threshold is concurrency, not headcount

Vans and employees are the wrong measure. What determines whether a business has outgrown a whiteboard and a spreadsheet is how many things are in flight simultaneously: structures standing, jobs part-priced, variations unagreed, cards approaching expiry, inspections due this week.

A firm with three gangs all working one long contract has very little concurrency. A firm with two gangs across nine short domestic jobs has a great deal. The second will feel the strain considerably earlier, at half the size.

The signs that are actually reliable

• –Somebody asks which structures are standing and the answer needs a phone call
• –Variations are being remembered at final account rather than recorded when they happen
• –The owner is the only person who knows what is where
• –Inspection coverage cannot be stated, only inspections shown
• –A second copy of the job spreadsheet has appeared
• –Work is being turned down because nobody can see whether there is capacity

None of those are about size. All of them are about information existing in one person's head or one file, and they arrive at very different headcounts depending on how the work is shaped.

What a small firm should not buy

The common mistake is buying the same product a fifty-van operation uses, at a scaled price, and using perhaps a tenth of it. The cost is not really the licence — it is that a system built for a transport office with dedicated administrators assumes somebody has time to keep it current, and in a small firm that somebody is the owner, in the evening.

Better to solve the single worst problem properly. For most small scaffolding firms that is variation capture, because it converts directly into money and the evidence has to be created on site as the work happens, which is exactly what a spreadsheet cannot do.

In practice: the firm that waited, and the one that did not

Two firms of a similar size. One buys a full platform, configures it over six weeks, and abandons it within the year because keeping it accurate is an unpaid evening job nobody owns. The other starts recording adaptations and variations on a phone, properly, and does nothing else for a year.

The second firm recovered enough in agreed variations to make the decision obvious when it did expand what it used. The first still talks about software as something that did not work for a business its size, which is not quite what happened.

Common mistakes

• –Judging the threshold by headcount rather than by how much is in flight
• –Buying a system sized for a much larger operation and using a tenth of it
• –No named person with actual time to keep the data current
• –Trying to move everything at once rather than the worst problem first
• –Comparing a licence fee against zero rather than against the evenings it replaces
• –Assuming the owner will maintain it, which is how most small implementations fail

Where this connects: who will keep it current

The question that decides most small-firm implementations is not which product but who maintains the data. In a business with no administrator that person is the owner, in the evening, unpaid — and systems maintained that way degrade within months, at which point the firm concludes software does not work for a business its size.

Which is not what happened. What happened is that nobody costed the maintenance. Being honest about it up front changes the decision usefully: either somebody's time is allocated, or the scope is narrowed to something that maintains itself as a by-product of work people already do — which is why capture on site tends to survive where central data entry does not.

• –Name who will keep the data current, and how much time it takes
• –Prefer scope that maintains itself as a by-product of site work
• –Be wary of anything needing regular central data entry in a firm with no administrator
• –Start with the single worst problem rather than a platform
• –Judge the threshold by concurrency, not headcount
• –Be willing to conclude it is not time yet