Choosing a POS for a hardware or DIY shop

Hardware is the trade that quietly defeats more POS systems than any other, and almost nobody writes about it. The software gets built for shops that sell discrete branded objects with barcodes on them. A hardware shop sells rope by the metre, sand by the kilo, and screws by the one, out of a bin, to a man who wants eleven of them.

If you have tried to make a general purpose till handle that, you already know where it breaks. If you are about to buy one, here is the list.

Rope, chain, cable, hose

The defining problem of the trade. You buy a 100 metre reel and sell it in lengths that nobody can predict: 2.5 metres, 40 centimetres, 12 metres.

What you need is for the product to be measured in metres, priced per metre, and for the system to accept 2.5 as a quantity without complaint while still knowing that you now have 97.5 metres left on the reel. That sounds obvious. A surprising number of systems cannot do it, and the workarounds shops end up using are all bad:

• Pre-cut lengths as separate products. Rope 1m, rope 2m, rope 5m. Now you have twelve products for one reel, your stock figures are fiction, and the customer who wants 3.5 metres gets told no.
• A generic “miscellaneous” product at a typed-in price. Fast at the counter, and it destroys your reporting. At the end of the year your best selling line is “misc”, which tells you nothing about anything.
• Rounding up to the whole metre. Overcharges the customer or eats your margin, and either way the stock count drifts.

Test it in two minutes: create a product measured in metres, sell 2.5 of it, and check that stock went down by exactly 2.5. Then check whether the system will let you sell 2.5 of something measured in pieces. It should refuse. A system that treats every quantity as a plain number will let a cashier sell half a hammer, and once it has, that product’s stock figure is wrong forever.

Sand, cement, compost, nails by weight

Same problem, different unit. Some of it is bagged and countable, some is loose and weighed, and plenty of shops sell both forms of the same material.

Model those as two products with two units, not one product you keep converting in your head. A 25 kg bag of cement is pcs. Loose cement is kg. They come from the same pallet, and the moment you try to make one product represent both, every count disagrees with the system.

If you sell fixings by weight, which is common, the same applies: screws in a bin priced per kilo is a kg product, and the customer who wants a specific count gets weighed rather than counted.

The single screw problem

This one has no clean software answer and it is worth knowing that up front, so you do not go looking for a feature that does not exist.

A customer wants eleven of a screw that you buy in boxes of 200. Options, none perfect:

Sell by the piece and buy in boxes. Create the screw as a pcs product with 200 in stock when a box is opened. Correct, and it means someone records “box opened” as a stock movement. This is the honest option and it is what I would do for the fifty fixings that actually matter.

Sell by weight. Eleven screws is 40 grams. Fast, no counting, and the stock figure stays roughly honest. Good for bins of mixed small fixings where nobody is going to track individual counts anyway.

A priced-by-hand loose item. Fine for the genuine long tail, as long as it is a handful of items and not your whole fixings wall. Keep one product called something like “loose fixings” so at least the money is categorised.

The mistake is trying to do the first option for all 800 fixings. Pick the fifty that turn over and track those properly; weigh or bulk the rest.

No barcodes on half the shop

Branded power tools have barcodes. A galvanised bracket in a bin does not, and nor does the reel of rope.

So the counter needs to work two ways at once, and this is worth testing with a realistic basket rather than a demo one. Scan a drill, then add three metres of rope, then eleven screws, then a bracket with no code. If any of those four takes more than a few seconds, that friction is your Saturday morning.

What helps in practice:

Your own barcodes on the bins. You can print your own labels for the no-barcode lines and stick them on the shelf edge or the bin, not the product. The cashier scans the shelf label. This is cheap and it is the single biggest speed win available to a hardware shop. There is a separate walkthrough of doing this.

Short codes you can type. For the top fifty loose lines, a memorable code beats searching by name. Cashiers learn them within a week.

Search that matches how staff talk. They will type “brack” or “M8”, not the full catalogue description. Test that.

Trade customers who do not pay today

Many hardware shops run accounts for local builders, and this is the requirement most likely to be missing from a small business POS.

Be precise about what you need, because these are three different features and vendors blur them:

• A customer record with purchase history. Nearly every POS has this.
• A store credit balance, where the customer has money on account that gets spent down. Common enough.
• Actual trade credit, where they take 400 of timber today and you invoice them at month end, with a credit limit and a statement. This is a genuinely different thing, closer to accounts receivable than to retail, and many small POS systems simply do not do it.

If half your turnover is builders on 30 day terms, that third one is not a nice-to-have and you should ask about it in the first conversation rather than the fifth. Some shops solve it by keeping trade on their accounting software and using the POS for counter sales only, which is a perfectly reasonable split.

Cost that moves, because timber does

Material prices move, sometimes sharply, and a shelf price set against an old cost is a quiet loss.

You want a system that recalculates a product’s cost every time you receive stock, as a weighted average across deliveries, rather than storing whatever you typed when you created it. Otherwise the margin the reports show you is historical fiction, and in a trade with these margins that matters. This is the mechanism behind setting a shelf price that pays, and it only works if the cost figure is current.

The test basket

If you are trialling something, ring up this basket. It takes four minutes and it will tell you more than any sales call.

1. A power tool, by scanning it.
2. 2.5 metres of cable.
3. 750 grams of loose sand.
4. Eleven screws.
5. A bracket with no barcode, found by typing.
6. Then try to sell 1.5 power tools. It must say no.

Watch the stock figures afterwards. If the cable did not go down by 2.5, or the system agreed to one and a half drills, you have your answer.

Where StoreWave sits

The units system is the reason StoreWave suits this trade, and it was built for exactly this problem. Every product carries a unit from a fixed catalogue: m and cm for cable, rope and timber, kg and g for sand, cement and loose fixings, L and ml for paint and fluids, and pcs, box and pack for the countable things.

The important half is that the server enforces it. Divisible units accept fractions and store them to three decimals, so 2.5 metres is 2.5 metres in the ledger. Countable units refuse a fraction outright, at the point of entry, which is what stops half a drill entering your stock figures. Metres round to two decimals and centimetres to one, because that is the precision those units are actually measured to.

Product cost is a weighted moving average recalculated on every goods receipt, so when timber goes up your reported margin moves with it rather than lagging behind. Barcodes are per product and you can print your own for the bins; USB scanners need no setup, and the device camera reads codes when there is no scanner.

The gap to know about is trade credit. StoreWave has customer records, purchase history, loyalty points and a store credit balance backed by a proper ledger, but it does not do builders’ accounts with credit limits, monthly statements and 30 day terms. If that is a large part of your business, plan on keeping it in your accounting software.