LoRaWAN, NB-IoT, Cat-M1: a 2026 connectivity decision tree
Picking your connectivity is picking your unit economics, and you only get to do it cheaply once. Here is the decision tree I would hand a founder shipping their first ten thousand devices in 2026, with the Polish coverage reality that most guides get wrong.
tl;dr. Picking your connectivity is picking your unit economics, and you only get to do it cheaply once. The honest 2026 answer depends heavily on where you deploy: LTE-M, also called Cat-M1, has become the comfortable default across much of Western Europe, but in Poland and parts of CEE, NB-IoT is still the technology with real nationwide coverage and LTE-M is only now maturing. LoRaWAN keeps winning a specific set of cases. Here is the decision tree, and why the right answer in Warsaw is not the same as the right answer in Munich.
Picking your connectivity is picking your unit economics. The radio you choose determines your power budget, your data costs, your hardware bill of materials, and which fields you can deploy into, for the entire life of the product. Get it right and it disappears into the background. Get it wrong and you are re-certifying hardware in the field eighteen months later, which is the most expensive sentence in IoT.
So here is the framework, the contenders, and the regional catch that most connectivity guides written from a Western European or US desk get wrong for this part of the world.
The four axes that decide
Four properties of your deployment determine the answer, and you should know all four before you read a single spec sheet.
Power budget is the first. Is the device mains-powered, like most smart meters and EV chargers, or does it have to run for years on a battery? Battery-first deployments push you toward the lowest-power options and rule out the hungrier radios.
Payload and frequency is the second. Are you sending a few bytes a few times a day, or kilobytes every few seconds? A parking sensor and a smart meter reporting near-real-time consumption have completely different needs, and the gap between them is the gap between two different technology families.
Deployment environment is the third. Indoors, in a basement, underground, behind concrete? Deep-indoor penetration is where the low-power wide-area technologies earn their reputation, and where ordinary 4G struggles.
Coverage geography is the fourth, and the one this post exists to flag. Which country, which operators, urban or rural? This is where the brochure and the reality diverge, because LPWA coverage is intensely operator-specific and varies enormously by market.
The contenders
LoRaWAN is the unlicensed-spectrum option. You can run your own network, or use a public one, you pay no per-SIM data fees, and the power consumption is extraordinarily low. It is built for tiny payloads sent infrequently. It does not do firmware-over-the-air comfortably, it does not do anything resembling real-time, and running your own gateways is a real operational commitment. But for the right shape of problem it is unbeatable on cost and battery life.
NB-IoT is the licensed-spectrum option optimized for deep coverage and very low power, designed for fixed, low-data, deep-indoor devices. It is the natural home for utility metering: a meter in a basement that sends small readings and never moves. It is not designed for mobility or for anything latency-sensitive, but it was never meant to be.
LTE-M, also called Cat-M1, is the licensed-spectrum option that supports higher data rates than NB-IoT, lower latency, mobility, and even voice. It is the more capable cellular LPWA option, and in markets where it has nationwide coverage it has become the comfortable default for devices that need more than NB-IoT offers but less than full 4G. The phrase to hold onto is "in markets where it has nationwide coverage," because that is exactly the catch.
The Polish catch
Here is where I correct a claim you will read in most connectivity guides: that Cat-M1 is now the obvious default for metered devices in Europe. That is increasingly true in Western Europe. It is not yet true in Poland.
In Poland, NB-IoT is the technology with established nationwide coverage. T-Mobile operates the country's nationwide commercial NB-IoT network in the 800 MHz band, and NB-IoT is the workhorse for utility metering, environmental sensors, and the rest of the fixed deep-indoor category here. LTE-M, by contrast, is still maturing in Poland. It is being rolled out and adoption is rising, but coverage is closer to "validated in places" than "guaranteed nationwide," and you cannot assume it the way you can in Germany, the Netherlands, or Belgium, where operators report near-total LTE-M population coverage.
The practical consequence for a founder shipping metered devices in Poland in 2026 is that NB-IoT is the safer coverage bet for fixed, low-data devices today, with LTE-M worth evaluating per deployment rather than assumed as the baseline. If your devices need mobility or higher throughput and you are Poland-only, you have to check LTE-M coverage on your actual deployment footprint before committing, and you may end up specifying dual-mode modules to hedge. If you are deploying across Europe, the calculus shifts, because the Western European markets are further along on LTE-M and a multi-network strategy can lean on it there.
This is the kind of detail that does not show up in a global spec comparison and absolutely shows up in your field failure reports. The radio that is the obvious default one border away may be the wrong call in your actual market.
The hidden costs
The technology choice is only half the unit economics. The other half hides in the operational layer, and it scales with your fleet.
SIM and connectivity management is the first hidden cost. At ten thousand devices you need a platform to manage SIMs, monitor connectivity, and control data plans, and the per-SIM economics that looked trivial in a pilot become a real line item at scale. Non-steered multi-network IoT SIMs, which can hop to whichever local network is strongest rather than being locked to one, are worth understanding here, because single-operator coverage gaps are a common and avoidable source of field failures.
Certification is the second. Cellular modules need carrier and regulatory certification, and that is time and money you budget for once and forget at your peril. Module choice and certification status can gate your launch timeline more than your software ever will.
Data plan economics at scale is the third. The difference between a plan that bills per active SIM and one that charges for inactive inventory matters enormously when a meaningful fraction of your fleet is sitting in a warehouse or a not-yet-commissioned installation. Pay-as-you-go and no-fee-for-inactive structures change the math at scale.
The cheat sheet
For the most common founder situations, here is where I would start, with the loud caveat that you must validate coverage on your actual deployment footprint before you commit a hardware design.
If you are shipping fixed, battery-or-mains, low-data metered devices in Poland or CEE, start with NB-IoT and confirm the operator's coverage on your sites. If you are shipping similar devices across Western Europe, LTE-M is a reasonable default and NB-IoT a fallback, with multi-network SIMs to smooth the gaps. If your devices are mobile or need more throughput, LTE-M where it has coverage, and a hard look at whether you can avoid being single-market. If your payloads are tiny, your devices are battery-first for years, and you can own infrastructure or use a public network, LoRaWAN is likely your cheapest path, especially in agriculture, environmental sensing, and dense private-site deployments.
And one piece of advice that outranks all of the above, borrowed from every engineer who has shipped a real fleet: test in your actual basements, with your actual antenna, on the actual operators you will pay, before you commit. Brochure coverage and field coverage are different things, and the gap between them is where your support tickets come from.
If you are choosing a connectivity strategy for an IoT product and want a second opinion grounded in running a real device fleet rather than a spec sheet, that is core to the IoT work I do with founders on the side. Details on the consulting page.