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 Stage 6 load-shedding 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 one-line test: a good industrial IoT provider should be able to start with the equipment you already own, keep working when the power and the network don't, and hand you data you control. If a pitch fails any of those three, the cost and risk are higher than the quote suggests.
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, NB-IoT and Sigfox 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
| Criterion | What "good" looks like | Red flag |
|---|---|---|
| Hardware + software | Builds both in-house; one accountable party | Reselling a chain of third-party vendors |
| Works with your kit | Reads existing PLCs, instruments, legacy machines over standard protocols | "We'd replace your sensors / it needs our hardware" |
| Load shedding | Edge buffering — keeps recording, forwards on return | Cloud-only; data gaps during outages |
| Remote sites | LoRaWAN / NB-IoT / Sigfox + solar/battery options | Wi-Fi or 4G only |
| Support & data | Local team; SA-region or on-prem; you own and can export data | Offshore-only support; opaque, locked data |
| Compliance fit | Audit-ready reports for DWS / SANS 241 / MHSA | Generic dashboard, no regulatory output |
| Start small | Paid pilot on real equipment, ZAR pricing | All-or-nothing, site-wide-only rollout |
| Integration | Open APIs, export to ERP/MES | Closed silo, no integration path |
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, NB-IoT, 4G and Sigfox; 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
What should I look for in an industrial IoT provider in South Africa?
Score providers on seven things: whether they build both the hardware and software (one accountable party), whether the platform works with the equipment you already own (protocol breadth, no rip-and-replace), whether it's engineered for load shedding (edge buffering) and remote sites (LoRaWAN/NB-IoT/4G/Sigfox), whether support and data are local and exportable, whether it produces audit-ready compliance reports for your regime (DWS, SANS 241, MHSA), whether you can start with a small paid pilot, and whether it integrates with your ERP/MES.
Should the provider build its own hardware and software?
It's a strong advantage. A provider that builds both is one accountable party — when a reading looks wrong there's no finger-pointing between separate device, connectivity and cloud vendors — and it can adapt the platform to a sensor or protocol you need rather than waiting on a foreign OEM. Resellers can do good work, but you inherit every seam in their chain of third parties.
How do I know it will work with my existing equipment?
Ask the provider to name your specific makes, models and protocols and tell you what they'd connect to directly versus what they'd need to add. A genuinely vendor- and PLC-agnostic platform reads existing instruments and controllers over Modbus, OPC-UA, MQTT and direct I/O — and can even read an old line with no PLC. "We'd replace your sensors" is a budget warning, not a feature.
Why does load shedding matter when choosing a platform?
Because if monitoring stops when the grid does, you lose data exactly when failures are most likely. Real edge computing buffers readings locally during an outage and forwards them when power and connectivity return, so the record stays continuous. Ask every provider directly: "What happens to my data during a four-hour outage?" — the answer separates real edge computing from cloud-only marketing.
Is a local South African provider better than an international one?
For industrial monitoring, local matters more than it does for office software. A local team can reach your site, speak to your operators, respond in your timezone when a 2am alert fires, and is accountable under South African terms — and local providers tend to design for load shedding, remote sites and DWS/MHSA compliance because their customers live with those realities. Wherever you buy, insist on SA-region or on-premise data hosting and an open export path.
How should a first project be scoped — and priced?
Start small. The lowest-risk path is a paid pilot on one real problem — a few critical assets, one pump station, one line — with a success measure you agree up front, before any site-wide rollout. Pricing should be in ZAR and sized to start where the pain is. A provider who insists on an all-or-nothing commitment is asking you to carry their risk.
Who owns the data, and can I get it out later?
You should. Confirm in writing that you own your data, that it's hosted in an SA region or on-premise, and that you can export all of it over an open REST or OPC-UA API if you ever leave. Open integration with ERP/MES is part of the same test. "Our cloud, our format, ask us for an export" is lock-in dressed up as a feature.