Insights · 13 min read
A practical guide to building a multi-tenant IoT SaaS product: device onboarding, data isolation, subscription billing, and what it costs to reach paying customers.
By GGP Editorial
Most IoT founders build the same thing in the same order. They get one device to phone home, wire it to a dashboard, show the demo, and then hit the same wall. The dashboard is single-tenant, the billing lives in a spreadsheet, and there is no way to hand a customer their own slice of the product without calling an engineer.
That is the difference between a device project and an IoT SaaS product. A device project reads data. An IoT SaaS product sells access to that data, per customer, on a recurring subscription. The software is not the dashboard. It is the business.
I write this from the vendor side. GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa, and Singapore. We build the cloud side of IoT products, and we keep watching teams under-build the parts that let them actually charge money. This guide is about those parts: multi-tenancy, subscription billing, and the customer-facing product that sits on top of the device layer. If you need the device layer itself first, start with our guide to building an IoT device management platform.
An IoT SaaS platform is the software you sell, not the software you run internally. It is the customer-facing product layered on top of your device infrastructure. Its job is to let each customer see their devices, their data, and their bill without ever seeing anyone else's.
The distinction changes what you build. The device management layer registers devices, collects telemetry, and pushes firmware updates. That is an operations layer, and it is covered in detail in our guide on building an IoT device management platform. The SaaS platform adds the business layer on top: tenant isolation, user accounts, roles and permissions, a customer-facing dashboard, alerts and reports, and subscription billing. Teams that confuse the two build a strong internal tool and then discover they cannot sell it.
There is a simple test. Can you hand a stranger a login, point them at their own devices, and let them add users, set alert thresholds, and download a report without a human involved? If the answer is no, you have a device project, not a SaaS product.
The device layer is what makes the product possible. The SaaS layer is what makes it sellable. These are the pieces buyers expect, and they are the ones founders most often leave out of the first scope.
A multi-tenant dashboard. Each customer logs in and sees only their own devices and data, with their own branding if the deal needs it. The dashboard usually starts with a fleet view, a device detail view with live and historical readings, and an alerts page.
Self-serve device onboarding. Your customer should be able to add a device without emailing you. That means a registration flow that ties a new device to the right tenant, often by scanning a QR code or entering a serial, with clear status when the device comes online.
Roles and permissions. An owner who can manage billing, an operator who can change device settings, a viewer who can only read. Single-tenant dashboards have one login; SaaS products have an access model.
Alerts and notifications. Thresholds the customer sets themselves, delivered by email, SMS, or push. This is usually where the product proves its worth, because an alert that wakes someone up at 2am is the moment the subscription renews itself.
Reports and data export. A customer who cannot get their data out will eventually churn. CSV export is the minimum; scheduled reports are better.
Usage metering. If you bill per device or per message, the platform has to count it. Retrofitting metering into a product that was not built for it is painful.
Multi-tenancy is the part that separates an IoT SaaS platform from an IoT tool. Every record has to carry a tenant identifier, and every query has to filter on it, or data bleeds between customers. For IoT that is worse than a normal SaaS bug, because the data is often operational and physical. One customer seeing another customer's pump status or location data is a trust-destroying event, not a support ticket.
You have two ways to isolate tenants, and the choice shapes the cost. Shared database, shared schema, with a tenant_id column on every table is the cheaper and more common starting point. It is fast to build and fine for most fleets. Dedicated database per tenant is more isolated but more expensive to operate, and it rarely makes sense below large enterprise deals. We cover the tradeoffs in more depth in our guide to multi-tenant SaaS architecture.
Whatever you choose, decide before you write the data model. Adding tenant isolation after you have live customer data means a migration across every table, and a mistake there leaks data. That is not a risk worth taking to save a week of planning.
Billing is where the business model lives, and IoT founders usually underestimate it. The common models are per device, per month; tiered by fleet size; or usage-based on messages or data volume. Each one forces different engineering.
Per-device billing needs a metering layer that counts active devices per tenant and reconciles when a device goes offline or gets retired. Tiered billing needs a way to move a tenant between plans and prorate the difference. Usage-based billing needs a reliable message or data counter, and a way to show the customer their running usage so they are not surprised at the end of the month.
Then there is the payment side. You integrate a payment provider for cards, and you decide how to handle failed payments, refunds, and dunning. A customer whose card expires and whose devices stop reporting because you cut them off is a churn event you created yourself. Most teams are better off starting with an existing subscription billing engine than building invoicing, tax, and payment logic from scratch. We cover the reasoning in our guide to building a subscription SaaS platform.
The key point: billing is a product decision, not a bolt-on. The billing model you pick determines your data model, your metering, and your retention flow.
A production IoT SaaS platform has three layers. The device layer, the application layer, and the billing layer.
The device layer handles connectivity. Devices speak MQTT almost by default, through a managed broker such as AWS IoT Core or Azure IoT Hub, or a self-hosted one such as EMQX when volume or data residency demands it. The device layer also handles identity, telemetry storage, and over-the-air updates. This is the layer our device management guide covers end to end.
The application layer is the SaaS product. It holds the tenant registry, the user and role model, the customer-facing API and dashboard, the alerting engine, and the time-series store your dashboards and reports read from. The application layer is where most of the custom work lives, because this is where your product differs from everyone else's.
The billing layer holds subscriptions, entitlements, metering, and payments. It is often a third-party service with your own glue around it. Keep it separate from the application layer so a billing change does not take down device data, and vice versa.
The data model deserves the most planning time. Decide early how you group devices, by tenant, by site, by fleet. Decide how you version firmware and store configuration. These are the decisions that become expensive to change after a hundred thousand devices are live. Our notes on software architecture go into what actually holds up over time.
Cost follows how much of the product you build versus adopt, and how big the fleet is. Here is a realistic split, using ranges rather than quotes.
| Scope | What it includes | Typical range |
|---|---|---|
| Pilot SaaS product | Managed broker, device registry, single-tenant dashboard, basic per-tenant isolation, simple subscription billing, CSV export | $50,000 to $90,000 |
| Production SaaS product | Multi-tenant dashboard, roles and permissions, self-serve onboarding, alerts, reports, metering, payment integration, mobile app | $90,000 to $250,000 |
| Large-scale platform | Millions of devices, self-hosted broker, usage-based billing at scale, edge compute, geo-redundancy, custom analytics | $250,000 to $600,000+ |
The device management layer alone runs roughly $30,000 to $180,000 depending on scale, which our device management guide breaks down. The SaaS layer, the multi-tenancy, billing, and customer-facing product, is what pushes a full product into the higher ranges above.
Three things move the number. Fleet size is the first, because ten thousand devices is a modest backend and a million is a distributed systems problem. The second is how much of the SaaS layer you build custom versus adopt, since a custom billing and entitlement system is easily its own project. The third is where the team sits, which changes cost a lot; we break down the numbers in our guide to software development cost in China.
For a first release, a pilot in the $50,000 to $90,000 range gets you a working multi-tenant product with basic billing, enough to sign your first paying customers. You build the deeper analytics, metering, and scale features once revenue proves the model.
For the device layer, start on a managed service. AWS IoT Core or Azure IoT Hub give you authentication, message routing, and a device shadow out of the box, and they remove a lot of operational risk from your plate. Move to a self-hosted broker when message volume is huge, data residency demands it, or you need control the managed services do not offer.
For the SaaS layer, build it custom. This is your product, and off-the-shelf tools will not match the dashboard, the alerting, and the workflow your customers expect. The exception is billing, where a subscription engine saves you months and a lot of compliance headaches.
The trap is assuming self-hosting saves money. We have seen teams move off managed services expecting a cost cut and end up paying more once they account for the engineers running the broker. Self-hosting is a control decision, not a cost-saving decision.
Building the dashboard before the tenancy. The customer dashboard demos well, so teams build it first against a single login. Then they discover the data model has no tenant concept and every query has to change. Decide tenancy first.
Ignoring billing until launch. Billing feels like the last thing, so it gets deferred. But the billing model determines the data model and the metering, and changing it after customers are live means a migration. Pick per-device, tiered, or usage-based before you write the schema.
Treating onboarding as a manual step. If a customer has to email you to add a device, you have a bottleneck that does not scale. Self-serve onboarding is the difference between a product and a service you run by hand.
Skipping data export. A customer who cannot get their data out is a customer shopping for a replacement. Build CSV export on day one and scheduled reports soon after.
Underestimating the run cost. An IoT SaaS product has ongoing costs: cloud infrastructure, broker fees, support, and the firmware and feature releases themselves. Budget for operating the product, not just building it. Our guide to scaling a SaaS platform covers what breaks as you grow.
An IoT platform is the operational layer that registers devices, collects data, and pushes updates. An IoT SaaS platform is the customer-facing product on top: multi-tenant dashboards, user accounts, alerts, reports, and subscription billing. The SaaS platform is what you sell; the platform is what makes it work.
A pilot multi-tenant product with basic billing runs roughly $50,000 to $90,000. A full production product with roles, self-serve onboarding, alerts, reports, metering, and a mobile app runs $90,000 to $250,000. Large-scale systems for millions of devices run $250,000 and up. These are ranges, not quotes.
A pilot product runs three to five months. A production product runs six to ten months. Large-scale systems can run a year or more, with the multi-tenancy, billing, and fleet-scale work taking the longest. We cover timelines in more depth in our guide to how long custom software development takes.
Start on a managed service. It is faster and safer to reach a working product, and it removes authentication and scaling from your plate. Move to self-hosted when volume, data residency, or control demands it. Self-hosting is a control decision, not a cost saving.
No. The platform is cloud software. As long as your devices speak a standard protocol and you can document their data format, a development partner with IoT backend experience can build against your device spec.
Start with the fleet size, the billing model, and the customer-facing features, then scope the device layer and the SaaS layer separately. Our guide to estimating a custom software project walks through the process.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa, and Singapore. We build custom software, mobile apps, SaaS platforms, FinTech and payment systems, ERP and CRM, and IoT and AI products on a stack that includes Java, Spring Boot, Go, Python, React, Vue, and Node. If you are still deciding what your IoT product should include, our guide on what to build first and our breakdown of IoT platform development are good next reads.
If you are planning an IoT SaaS platform, talk to us about your project. Send us the device type, the protocol and data format, the fleet size you are planning for, and the billing model you have in mind. We will help you work through tenancy, billing, onboarding, and a realistic scope and timeline.
Tell us what you are building and where you are today. We typically reply within 24 hours.
