How to choose an industrial IoT provider in South Africa: a buyer's guide

Why this choice is harder than it looks

Every industrial IoT provider shows you the same thing: a clean dashboard with gauges trending green. The demo always works. What the demo doesn't tell you is whether the platform will read your twenty-year-old compressor, keep recording through a load-shedding or load-reduction block, survive a remote pump station on a marginal signal, or hand your data back when you ask. Those are the things that decide whether a project delivers value or quietly stalls after the pilot — and they're exactly what a screenshot hides. The good news is that the questions that surface them are concrete, and you can score providers against them.

The seven criteria that actually matter

1. Do they build the hardware and the software, or resell someone else's?

This is the first fork, and it decides a lot downstream. A provider that builds both its hardware and its software is one accountable party: when a sensor reading looks wrong, there's no finger-pointing between a device vendor, a connectivity vendor and a cloud vendor. It also means the platform can be adapted to a sensor or protocol you need, rather than waiting on a foreign OEM's roadmap. Resellers and integrators can still do good work, but you're buying a chain of third parties — and you inherit every seam in that chain. Ask plainly: what in this stack do you build, and what do you buy?

2. Will it work with the equipment you already own?

The single biggest hidden cost in industrial IoT is rip-and-replace — being told that to get visibility you must swap out working instruments, controllers or meters. A platform that is genuinely vendor- and PLC-agnostic reads what you already have over standard protocols (Modbus, OPC-UA, MQTT and direct I/O), and can even read an old line that has no PLC at all. Ask how many protocols and device types they support, and ask them to name the ones on your site specifically. "We'd need to install our sensors everywhere" is a budget warning, not a feature.

3. Is it engineered for South African conditions?

This is where international platforms quietly fall down and where local context is decisive. Two things matter most here:

• Load shedding. If monitoring stops when the grid does, you lose data exactly when something is most likely to go wrong. Real edge computing buffers readings locally and forwards them when power and connectivity return — so the record is continuous even though the lights weren't. Ask what happens to data during a four-hour outage.
• Remote and off-grid sites. Pump stations, reservoirs, boreholes, tailings dams and mine infrastructure are often far from reliable power or fibre. A provider that only does Wi-Fi or 4G will struggle there; one that also does LoRaWAN and 4G with solar/battery power has the right toolkit for the country's geography.

4. Is the support — and the data — local?

When a critical alert misfires at 2am, a support desk in another timezone is a real operational risk. A provider with a local team can get to your site, speak to your operators, and is accountable under South African terms. Equally important: where does your data live, and who owns it? Insist on SA-region cloud or on-premise hosting, clear data ownership, and the ability to export everything over an open API. "Our cloud, our format, ask us for an export" is lock-in dressed up as a feature.

5. Does it fit your compliance regime?

In water and mining especially, monitoring is often there to satisfy a regulator, and the reporting has to match the regime exactly. A provider who already understands your compliance context will save you months. For water, that means DWS water-use licences, SANS 241 drinking-water limits, and municipal trade-effluent bylaws. For mining, it means MHSA obligations like collision prevention (8.10.1, EMESRT Level 9) and person location (16.7), and GISTM for tailings. Ask whether the platform produces audit-ready reports in the format your regulator actually wants — not just a dashboard you'd have to transcribe.

6. Can you start small and prove value?

Beware the provider who only sells the big-bang, site-wide rollout. The lowest-risk path is a small, paid pilot on one real problem — a few critical assets, one pump station, one line — that proves the data is trustworthy and the alerts are useful before you scale. A provider confident in their platform will welcome that; one who insists on an all-or-nothing commitment is asking you to carry their risk. Pricing should be in ZAR and sized to start where the pain is.

7. Will it connect to the rest of your business?

Monitoring that lives in its own silo is worth a fraction of monitoring that feeds the systems you already run. Check for open REST and OPC-UA APIs and the ability to export to ERP/MES so the data becomes part of maintenance planning, production reporting and finance — not a separate screen someone has to remember to look at.

A scorecard you can use

Three things the first quotation never covers

The seven criteria above decide whether a platform can do the job. The three below decide whether you will still be happy with it in year two, and none of them appear on a feature comparison. They come straight out of what buyers write publicly about platforms they already own — quotes here are reproduced verbatim from a 2026 research base of public product reviews and engineering discussion, anonymised.

8. How will you be billed as the deployment grows — and shrinks?

Licence models are where a good first-year price turns into a bad third-year one. The pattern that generates the most anger is per-seat pricing with a one-way ratchet, as one reviewer put it: “they will allow you to add users and upcharge you, but when you’re ready to remove users they will tell you that you’re out of luck. Extremely predatory billing practices.” Another described the same shape on features: “cost for everything. Any help you need comes at a cost.”

Ask three questions before you sign. What is the unit of charge — users, devices, tags, sites, data volume? What happens to the bill when that unit goes down, not just up? And which capabilities sit behind a higher tier, specifically — because “I have to buy the business plan in order to use a calendar day view” is the kind of discovery that arrives after the budget is fixed. A licence priced on something you control, and that can move in both directions, is worth paying more for than one priced per seat.

9. How do they ship changes to your production instance?

An industrial platform is not a consumer app, and a release cadence that suits a SaaS start-up can be actively hostile on a plant. The complaint is specific and common: “they are constantly updating things (every Friday) and they apparently don’t sandbox these very well because every Friday something new breaks. It is super frustrating.” Another reviewer’s version: “the system is normally crashed, hasn’t properly worked in over two weeks.”

What you are checking for is ordinary change-management discipline: release notes in advance, a staging or sandbox environment you can test against, agreed maintenance windows rather than surprise Friday deployments, and a stated rollback path when a release does break something. Ask what their last three releases changed and how you would have been told. A vendor who cannot answer that is telling you their production instance is their test environment.

10. How is measurement accuracy verified in the field, not on the datasheet?

Every sensor has a specification. What matters is whether the installed sensor still meets it on your site, and how you would know. The failure mode is not subtle when it happens: “temperature sensors are not correct. At least 10 degrees off.” A reading that is wrong is worse than no reading, because decisions get made on it — and in a cold chain or a compliance record, it is the number you will be asked to defend.

Ask for the stated accuracy and the procedure: how a sensor is verified against a reference at commissioning, at what interval it is re-checked, what the drift behaviour is, and what happens when a device fails a check. The same question applies with more force to anything using inference or AI. Buyers describe exactly the problem: “sometimes the system AI detects things as a phone when it’s not” and “sometimes it gives false readings.” Automated detection is useful when its false-positive rate is stated, tunable and auditable, and corrosive when it is none of those — because a team that learns to ignore alerts has lost the value of the system while still paying for it. Our guide to water quality sensors works through what calibration and drift actually look like on instruments in the field.

How to actually run the evaluation

• Write down the one problem you most want solved first — the asset, line or site that's costing you. Evaluate every provider against that, not against a generic feature list.
• Make them name your equipment. Send a list of the makes, models and protocols on your site and ask, specifically, what they'd connect to directly and what they'd need to add.
• Ask the load-shedding question directly: "What happens to my data during a four-hour outage?" The answer separates real edge computing from cloud-only marketing.
• Insist on a small paid pilot on your real equipment before any site-wide commitment, with a clear success measure you both agree on up front.
• Check the exit, not just the entry: confirm in writing that you own the data and can export it over an open API if you ever leave.

Where addanode fits

We built addaNet around exactly these criteria, because they're the ones our own customers in water, mining and manufacturing care about. addanode builds both the hardware and the software in-house, so the platform reads the sensors, instruments and PLCs you already own (500+ protocols) instead of forcing a rip-and-replace; it uses real edge computing so monitoring keeps recording through load shedding; it connects remote sites over LoRaWAN and 4G; it's supported by a local team with your data in an SA region or on-premise; and it produces audit-ready reporting for DWS and MHSA regimes. We'd rather start with one real problem on your existing equipment than sell you a rip-and-replace. If that's the kind of provider you're looking for, the criteria above are the right ones to hold us to as well. For the wider picture, see our practical guide to Industrial IoT in South Africa.

Frequently asked questions

Primary sources

• South African Government — National Water Act 36 of 1998
• DMRE — MHSA: Guideline for a mandatory code of practice for trackless mobile machines (GN 6329, GG 52883, Jun 2025)
• DMRE — MHSA regulation 16.7 Missing Person Locator System (GN 6052, GG 52388, 28 Mar 2025)
• Global Tailings Review (ICMM/UNEP/PRI) — Global Industry Standard on Tailings Management (2020)
• Eskom — Load shedding schedule interpretation (stages 1–8, 2-hour/4-hour blocks, +30 min switching)
• EMESRT — Vehicle interaction improvement programme (control-level model)