The price you see in month one is the worst number to decide on, and it is usually the only number people look at. A platform that quotes a low monthly fee can cost more over three years than one that quotes higher, because the sticker price covers a fraction of what you actually pay to run an IoT product. The fees that do not appear on the first invoice are the ones that move the total.
If you are choosing a platform, the question to answer is not which one is cheapest today. It is which one costs least to own across three years, and which pricing model lets you predict that number well enough to put it in a budget. Those are two different questions, and both matter.
Why month one misleads
A monthly platform fee is a single line. Your real spend is many lines, and most of them grow on their own schedule. You add devices. Each device sends more data than you planned. A customer asks for an integration, and an engineer spends three weeks building it. Someone has to be on call when ingestion stalls at 2am. A prospect asks for your security documentation before they sign, and now you are paying for an audit.
None of that shows up when you compare monthly fees in a spreadsheet. So the platform that looked cheapest in the demo becomes the expensive one by year two, and you find out after you have already built on it. The fix is to model the categories that show up over three years before you sign, not after.
The cost categories that show up across three years
Across a three-year horizon, the spend tends to land in a handful of buckets. Naming them up front is the only way to compare two platforms honestly.
- Platform fees. The base subscription or the consumption charges. This is the number everyone quotes and the one people overweight.
- Per-device and per-data scaling. Most pricing scales with devices, message volume, or stored data. The slope of that scaling matters more than the starting point, because you are signing up for the curve, not the first dot on it.
- Integration and build work. Connecting hardware, wiring up external systems, building custom logic. Some of this is one-time, some recurs every time a customer needs something new. It is engineering salary, not a vendor line, which is exactly why it gets left out of comparisons.
- Operations and on-call. If you self-host any part of the stack, you pay to keep it running: patching, scaling, monitoring, and a human awake when it breaks. A managed platform folds most of this into the fee. A self-hosted setup hands it back to you.
- Support. Whether you get help when something breaks, and what that help costs. The price of a slow answer during an outage is real even if it never appears on an invoice.
- Compliance evidence. If you sell to mid-market or enterprise buyers, they will ask for certifications and documentation. Producing that evidence yourself costs audit fees and engineering time. Inheriting it from a platform that is already certified costs nothing extra.
A fair comparison puts numbers, or at least ranges, against every one of these for each option. Comparing only the first bucket is how teams end up surprised.
Build vs buy vs resell
The same three-year frame clarifies a decision that usually gets made on instinct.
Build means you own the platform layer outright, on raw cloud infrastructure or open components. Your platform fees are low and your control is total. Your build and operations costs are the highest of the three, and they never stop, because every feature and every patch is yours forever. Build wins when the platform itself is your product and the differentiation is worth owning.
Buy means you take a managed platform and connect your devices and logic on top. Platform fees are higher and visible. Build and operations costs drop sharply, because you are not maintaining the layer underneath. Buy wins when your product is what runs on the platform, not the platform itself, which describes most teams.
Resell adds a third option that changes the math. With a white-label platform, the cost stops being only a cost. You put your brand on it, sell it to your own customers, and the platform fee becomes the input to a recurring revenue line. For a system integrator, this turns the pricing question from “how much does this cost us” into “what margin does this carry,” which is a far better question to be asking.
Predictable pricing versus consumption pricing
Two pricing models dominate, and they behave very differently when you try to budget.
Consumption pricing charges for what you use: messages, operations, storage, often metered to the million. It is honest and it scales down when you are small. The problem is that it scales up without asking. A firmware change that doubles reporting frequency doubles a line you forecast at the old rate. A successful customer rollout that triples device count triples spend in the same quarter you are celebrating the win. The bill follows usage, and usage is the thing you control least once real customers are involved.
Predictable pricing fixes the input. You know the platform cost for a given tier regardless of how chatty the devices get inside that tier. You lose the pure pay-as-you-go efficiency at very low volume. You gain a number you can put in a three-year model and defend to whoever signs off on it.
Predictability matters because budgets are commitments, not estimates. A finance team can work with a fixed line and a known step when you cross a tier. They cannot work with a line that moves every month for reasons the device fleet decides. If you are an integrator quoting a fixed price to your own customer, an unpredictable underlying cost is a margin you cannot promise. Predictable input cost is what lets you sell a predictable price on top.
What to model before you sign
Before committing, build a three-year model with these inputs, using ranges where you cannot get exact figures.
- Device and data growth. Project the curve, not the starting count. Run a low case and a high case, because the high case is where consumption pricing bites.
- The full cost stack. Every bucket above, for each option, including the engineering salaries that build and operations work actually cost.
- The pricing model’s behavior at your year-three volume, not your month-one volume. Ask the vendor to quote the tier you expect to be in, not the one you start in.
- Compliance requirements from your buyers, and what it costs to meet them yourself versus inherit them.
- For integrators, the resell margin: platform cost in, customer price out, across the same horizon.
The platform that wins this model is rarely the one with the lowest first invoice. It is the one whose total stays close to what you predicted, because a cost you can predict is a cost you can build a business on.
Where TagoIO fits
TagoIO is a managed IoT application platform for system integrators and mid-market teams. It ships the application layer, dashboards, device management, storage, alerts, and APIs, on top of connectivity, so the build and operations buckets stay small instead of becoming a second engineering org. It is ISO 27001 certified and GDPR-aligned, so the compliance evidence your buyers ask for comes from us rather than from an audit you fund.
The pricing is predictable, which is the point of this article. You get a number you can model across three years and defend in a budget, instead of a meter that reprices itself every time your devices get busier. And through TagoRUN, the white-label option, an integrator turns that platform cost into the input for a recurring revenue line, selling a branded product on top with a margin you can actually promise because the cost underneath holds still.
