How to choose construction software without regretting it

Most construction software purchases that go wrong did not buy bad software. They bought reasonable software after an evaluation that could not possibly have found the problem.

Two habits cause this, and they compound.

The evaluation is done by people who will never use the thing. A director, an IT person, sometimes an accountant. Not the storekeeper standing at the gate at eight in the evening with a lorry waiting, the driver impatient and a phone in one hand.

And it is done against a feature list. A feature list is a list of nouns. Your office does not run on nouns. It runs on a small number of transactions that repeat all day, each with an awkward variant that nobody has written down.

Pick three transactions and follow them#

Before you look at anything, choose the three transactions that carry your money and your risk. For most builders they sit close to these:

• A material receipt. A lorry at the gate, a challan, a short delivery, and a storekeeper who must decide whether to accept it.
• A bill approval. A vendor invoice arriving, being checked against what was ordered and what actually came, and being passed by whoever is allowed to pass it.
• A payment. Money leaving against a specific bill, with whatever deduction and whatever signature your practice requires.

Now take each one end to end, and take it with your material. Your challan, with your supplier's handwriting on it and the quantity overwritten once. Your approval chain, including the partner who is usually travelling. Your worst case — the partial delivery, the rate revised in a WhatsApp message, the payment that had to move before the material did.

Three transactions followed properly will tell you more than forty features demonstrated. The method for doing that without being managed through it is in the demo is not the product.

The six axes that actually decide it#

Everything else is decoration.

Does it work where the work happens? A record is only true if it is made at the moment and place of the event. If the site writes on paper and somebody types it in the office at night, you have not bought a record; you have bought a second copy of one, arriving late. Sites have bad signal, so ask hard about what happens with the network off, and treat the answer sceptically — evaluating offline claims sets out what to test.

Can the people who must use it read it? Not the head office. The storekeeper, the guard, the junior engineer, the supervisor whose English is his fourth language. If the screen they need is dense, English-only and built for a desk, it will be used by proxy or not at all. What good looks like is in software your staff can read.

Can it prove what happened? Six months later, when a supplier disputes a quantity, you need to know who recorded what, when, and what it said before it was edited. Ask to see it on a record you created yourself, as in ask to see the audit trail.

Does it fit the approvals you already have? Every organisation has a real approval structure, and it is rarely the one on the chart. Somebody signs below a limit, somebody else above it, and a partner overrides both when a lorry is waiting. Software that insists on its own chain will be worked around within a month, and the workaround becomes the process.

Can you get your data out? Not a report. Every record, the attachments, the links between them. Test it during evaluation, not on the day you leave — getting your data back out.

What happens on the day the vendor stops answering? Vendors are acquired, change direction, or simply lose interest in a customer of your size. Ask who else runs this at your scale, and what happens to your data and your logins if support ends.

A gap you can live with, and a gap you cannot#

Every system will be missing something. The useful distinction is not big versus small; it is whether the gap makes the record unreliable.

A gap you can live with is one where the work is inconvenient but the record stays true. A field you must fill twice. A report you assemble in a spreadsheet once a month. An approval that needs an email alongside it. These cost time, and time is recoverable.

A gap that makes the record unreliable is one where the system quietly stores something that is not what happened. A receipt that cannot represent a short delivery, so the storekeeper enters the full quantity and mentions the shortage on the phone. A bill that cannot hold a disputed line, so the disagreement happens in a meeting and only the outcome is stored. An edit that overwrites the previous value with no trace.

The first kind you negotiate about. The second kind you walk away from, because every month it runs, the archive fills with confident, wrong numbers, and you will not know which ones.

Do not decide on the demo#

The demo tells you whether the product can do the work. It cannot tell you whether your organisation will do the work in it. Only a trial does that, and only if it is designed to be capable of failing — a pilot that tells you something covers how to set the pass criteria before you start, rather than after you have already spent the money.

Price belongs in the same category. The licence is the visible part of a number with several other parts, and the other parts are larger and arrive later. Ask for the whole shape of it in writing, as in what a price list does not tell you.

The single test#

After the pilot, walk to the site office and the accounts desk and look for a parallel register.

A notebook at the gate. A spreadsheet somebody maintains "for our own hisaab". A WhatsApp group where the real numbers travel. A printed sheet on a clipboard that the supervisor still fills.

If anyone is still keeping one, the tool has not been adopted. It has been added. The old system is still the system of record and the new one is a reporting layer that somebody feeds, which means you are now paying for the work twice and will eventually stop paying for one of them.

Nobody keeps a parallel register out of nostalgia. They keep it because the software cannot hold something they need, or cannot be reached at the moment they need it. Ask what that thing is. The answer is the honest review of the product, and it is free.

The short version#

Evaluate with the people who will use it, using three real transactions and your own worst documents. Judge on where it works, who can read it, what it can prove, whose approvals it fits, and what you leave with.

Distinguish a gap that costs time from a gap that makes the record untrue. And after the trial, go and look for the notebook.