Choosing construction software,
and what to actually compare.
Every product demos well. A buyer's checklist written to be useful even if you buy from somebody else, including the five questions vendors answer badly.
Published ·6 min read·Written by Unibuild
Feature lists do not separate these products, because in a demo they all work. What separates them is the pricing model, whether site will actually use it, how long until it is genuinely running, what happens to your data if you leave, and whether the vendor will tell you what their product does not do. Compare those five and the field narrows quickly.
Why every demo goes well
A demonstration is a rehearsed path through prepared data by somebody who uses the product every day. It is not dishonest and it is not useless, but it tells you very little, because the parts that fail in real life are the parts a demo is structured to avoid: the awkward job, the operative who will not use it, the month three when the novelty has gone.
So the useful question in a demo is not whether the software can do a thing. It nearly always can. It is what happens on the day it is inconvenient.
One practical technique that costs nothing: bring the job you are least sure about rather than a clean one. Ask them to model the messy subcontract, the variation nobody instructed properly, the package that went wrong. A vendor who can show you their product handling your worst job is telling you something a demonstration of their best case cannot.
The five things that actually differ
- The pricing model, not the price. Per user, tiered bands, per active project, or flat for the organisation. The model decides how the bill behaves as you grow and, more importantly, whether you will end up rationing access. The detail is in what construction software actually costs.
- Whether site will use it. The single biggest determinant of whether any of this works, and almost nothing to do with the office half of the product. Ask specifically: does an operative need an app store download, an account, a password. Every one of those is a legitimate reason not to do it today, and the failure mode is documented in why field rollouts stall in week three.
- Time to actually running. Not time to an account being created. Ask how long until hours are coming off site through it and applications are being produced from it, and what the customer has to do in that period. Every implementation costs you your own people's attention, and a vendor who says none is required is describing a rollout that will fail.
- What happens if you leave. The question nobody asks in a demo. Can you export your jobs, documents, photographs and history, in what format, how quickly, and at what cost. A vendor comfortable answering that is telling you something about how they expect to keep you.
- What it does not do. Covered on its own below, because it is the most revealing question available to a buyer.
Every vendor can tell you what their product does. The ones worth shortlisting can tell you, without prompting, what it does not.
Five questions vendors answer badly
Ask these in every demo and write the answers down. The pattern of answers separates products more reliably than the features do.
- What will we still be doing in a spreadsheet after this? Every honest answer to this is a real answer. "Nothing" is not one.
- Which of your customers stopped using it, and why? Vendors have churn. One who claims otherwise is either very new or not answering.
- What does it cost in year three? Including the uplift mechanism at renewal.
- What happens when the person who championed this leaves? Adoption usually survives on one internal advocate, and the vendor should have a view on what happens when that person moves on.
- Can I speak to a customer like us who is not on your case studies page? The reference nobody prepared is worth more than the one who was.
Scope: one system or several
There is a genuine argument on both sides and the honest answer depends on your business.
Several specialist tools can each be better at their own job than one platform is at any of them, and if one part of your business is genuinely unusual, a specialist product for that part may be the right call. The cost is the rekeying between them and the fact that no single place holds the position.
One system trades some specialist depth for the position being in one place and the data being entered once. That trade is usually right for a contracting business in the twenty to three hundred range, where the pain is assembling a picture rather than any single function being weak, and usually wrong for a firm with one very unusual requirement and otherwise simple needs.
The test worth applying: write down the three questions you most often cannot answer quickly. If they all need information from different tools, integration is your problem and one system is the answer. If they all sit inside one function that your current tool does badly, buy a better version of that tool.
Making the decision
Three practical points that shorten most procurements.
Decide who this is for before you look. A product chosen by the office for the office and then handed to site is the commonest way this money is wasted. If site is the group whose behaviour has to change, site has to be in the decision.
Score against your own list, not the vendor's. Write your five criteria before the first demo and score every product against them. Vendors are skilled at moving a conversation onto the ground where they are strongest, and a written list is the only defence.
Be honest about whether you need it yet. Compare the cost against what the current arrangement actually costs you, in hours assembling positions, applications paid short, retention never chased and plant hired twice. If that number is smaller than the licence, the answer is no, and any vendor telling you otherwise is selling.
Our answers to the five, so the page is not a checklist with a gap where the vendor should be. Pricing is a flat monthly fee sized to the modules you use and never per person, so there is no reason to ration logins. On site adoption: clock-in is by pointing a phone camera at a poster on the site board, with no download, no password and no account to set up, which removes the three barriers named above; it does not remove the need to run the rollout properly, and nothing does. Implementation is about two weeks for most firms with migration included, in phases, with a sandbox. Data export and what you get back is a fair question to put to us in a demo. And what it does not do: it is not an accounting system, it does not file your tax, and the directors page names the one report it does not yet produce.
Where to start, on Monday
Before you book a single demo, write two lists. The three questions about your business you most often cannot answer quickly, and the five criteria you will score products against. Half an hour, and it changes every conversation that follows.
Then, when you do book demos, bring your worst job rather than your cleanest. What you learn from watching somebody handle it is worth more than the rest of the meeting.
The follow-up questions.
The money side is in what construction software actually costs.
What should I look for in construction management software?+
What questions should I ask in a software demo?+
Is one platform better than several specialist tools?+
How do I stop a software demo being misleading?+
Who should be involved in choosing the software?+
More from Insights.
RAMS that hold upWhat an inspector is actually looking for in a risk assessment and method statement, and the difference between a document that exists and one that is doing its job.Read it →
Retention, and the money that goes missing after practical completionWhere cash quietly disappears between the last valuation and the release of the second half of retention, and the four dates that decide whether you ever see it.Read it →
Why field rollouts stall in week threeMost site software is not rejected. It is quietly outlived by the paper route nobody switched off. What the firms that got it to stick did differently.Read it →