This checklist is relevant for companies planning or developing IoT/IIoT solutions, products and services.
It was carefully crafted for companies that are considering their development to be based upon an existing IoT platform. If you’re still choosing between developing “from scratch” and going atop of a platform, we suggest checking our IoT Platforms vs Open Source: choosing the right way to develop an IoT product long-read first.
Consider a glimpse if you represent one of the following company types:
- System Integrators building IoT / IIoT solutions
- Consulting firms advising on IoT architecture
- Enterprises selecting a long-term IoT foundation
- Telcos and MSPs building IoT services
Use this as a yes/no/maybe checklist. If too many boxes stay unchecked, walk away from a particular platform.
1. First Sanity Check: Is This Really an IoT Platform?
Before diving deep, validate that the vendor is not just:
- a dashboard builder + MQTT broker
- a device vendor rebranding device management as a “platform”
- a single-vertical solution pretending to be generic
Minimum baseline (non-negotiable):
- Multi-protocol connectivity, especially for IIoT cases (not only MQTT/HTTP)
- Bi-directional device control, not just “data ingestion”
- Structured hierarchical multi-layer data modeling (not just “device twins”)
- Advanced event-driven processing (rules, actions, alerts, correlations, and root cause analysis)
- Native visualization (web dashboards, printable reports)
- External system integration via APIs
- Real strong and flexible security model (not only TLS + passwords)
If any of these are missing, whatever software you’re considering is not an enterprise IoT platform.
2. Does the Platform Enable Cross-System IoT Scenarios?
Ask yourself:
- Can it combine data from different vendors and device types?
- Can multiple subsystems influence each other logically?
- Is there a “brain in the center”, not point-to-point chaos?
Red flags:
- Heavy reliance on custom integrations for every new use case
- No reusable abstraction across domains (e.g. HVAC, access control, energy, IT, OT)
A real IoT platform creates synergy, not just visibility.
3. Build vs Buy: Make the Decision Consciously
Consider building only if:
- You support very few device types
- You have a large, long-term core engineering team
- You accept permanent “your own platform” maintenance costs
- You are willing to maintain protocols, security, scaling forever
Prefer buying if:
- You deal with many customers, industries, and devices
- Time-to-market matters
- You want predictable project margins
- You plan to scale gradually
- You don’t want your business to become “platform maintenance”
Most SIs and even OEMs/ISVs dramatically underestimate the long-term cost of “owning your own platform”.
Yet again, check our IoT Platforms vs Open Source article for more details on this strategic choice.
4. Vendor Business Maturity Checklist
Company and market reality:
- Platform is the vendor’s core business
- 7–10+ years of real production deployments
- Dozens (not 2–3) real customer references
- References across multiple industries
- None or very little implementations delivered directly by vendor engineers
Warning sign: “Big names” + very few projects = heavy customization, poor scalability.
A platform vendor must be a platform vendor – not a system integrator, not a custom software developer, and not a “we’ll do whatever for your money” kind of company.
5. Roadmap and Strategic Alignment
The checklist is rather obvious here:
- Vendor openly shares roadmap
- Regular large platform releases (not cosmetic updates)
- Active work on the fundamentals:
- Low coding and AI-assisted development tools
- Instruments for high-performance testing and debugging
- New protocols
- Edge computing
- Advanced analytics tools
- Brand-new UI components
- Security and compliance
- Platform evolves without breaking existing solutions
If the roadmap is secret, you’re betting blind.
6. Deployment Flexibility
Your customers are not or might not stay all cloud-native.
- On-premise deployment supported
- Private cloud deployment supported
- Public clouds supported and natively integrated
- Hybrid architectures supported
- Cloud-provider agnostic (no deep lock-in)
- Edge deployment supported
Mandatory for industrial, telco, and MSP projects.
7. Connectivity and Protocol Coverage
With time, you might need to connect industrial devices to a “classic” IoT system, and vice versa.
Even if you’re planning/developing just one solution now, you may start new solutions and products in the future.
Don’t lock yourself to the “MQTT/REST only” kind of a platform, seek for:
- Broad industrial protocol support
- IT and OT protocols covered
- SDK / driver framework available
- Low/no/vibe-code protocol adaptor building capabilities
- Custom protocol implementation possible by SI, not only vendor
- Gateway and edge connectivity supported
If every unsupported device requires vendor services, margins die fast.
8. Device and Data Modeling (Hidden Killer Feature)
Ask explicitly:
- Is there a platform-wide formal data model?
- Can you visually design:
- Custom business object hierarchy (that’s not just “flat” device / digital twin structure!)
- Parameters, properties and settings
- Operations and their logic
- New event and notification types
- Dynamic object-to-object bindings
- Is modeling reusable across projects?
- Can new device types be added without coding?
If modeling is weak, every project becomes custom development.
Hint: try to actually build your product’s/solution’s business asset hierarchy using the platform’s demo. For example, for an IIoT project a typical structure would be something like Enterprise => Factory => Workshop => Line => Unit. Make sure you’re modeling your own entities though, not just sticking to the platform’s ones.
9. Data Storage and Processing Flexibility
A good platform:
- Supports multiple data storage approaches
- Has SQL available (or equivalent accessible skillset)
- Supports stream processing
- Operates event-driven logic
- Offers advanced time series data analysis (yeah, IoT is still all around plain old “time+value” pairs)
Rule of thumb: Your team should not need rare or exotic skills to use the platform. You should need citizen developers, not hardcore IT people.
10. Visualization and UX Capabilities
Beyond basic dashboards:
- Layered maps with tracks and geozones
- Floor / facility plans and 3D BIM models with dynamic data inside
- Topologies (network graphs, service dependencies, material flows, etc.)
- Industrial SCADA-grade HMIs
- Advanced charts and diagrams (number of chart settings should be comparable or exceeding Microsoft Excel / Google Sheets – otherwise you are stuck with platform’s “hardcoded” ones)
- Tables, tables, tables (sortable, filterable, pivot, based on “big data sets”, spreadsheet-style with formulas – you’ll need that and much more)
- Tons of “simple” components (buttons, lists, menus, breadcrumbs, trees – all these differentiates a fine-tailored UI designed from a “dashboarding engine”)
- Custom UI components (worst-case requirements scenario leads to JS/TS/React/etc. – expensive and not low code anymore, but at least you’re not in a dead end)
- White-labeling support
The platform must not dictate UI/UX limitations to you and your customers.
11. Integration Readiness
Check support for:
- ERP / CRM integration – how is it done? Is it low/no-code? Are there limitations?
- Enterprise portals – can you integrate platform-based UIs to your portal? Vice versa?
- Real-time operational systems – if your platform instance is running on a Linux PLC, can it access and change the registers/properties managed by the real-time core? If not, you’ll likely need a separate edge platform – which increases platform count twice leading to architectural hell.
- Well-documented APIs – the proper implementation ensures that anything doable via the platform’s administrative UIs and visual design/development tools can be automated via the API.
- High-throughput data exchange – make sure that a local (edge/on-premise/private cloud) platform server can handle several hundred thousand events/samples per second.
IoT data is useless if isolated.
12. Security and Multi-Tenancy
The below are options for a solution, but must-have for a product:
- True multi-tenancy
- Role-based access control
- Custom app-specific roles for your product
- Geographic and organizational segmentation
- Secure tenant isolation
Security must be architectural, not bolted on.
13. Development, Diagnostics, and DevOps
The application enablement is quite a demanding process, so here are the relevant checkboxes:
- Platform acts as a real development environment
- Full audit logging and tracing
- Deep diagnostics (queues, caches, threads, pools)
- Git integration
- CI/CD-friendly
- Multi-environment workflow (dev / test / prod)
Fast delivery depends on tooling quality.
14. Scalability and Performance Reality Check
Make sure you won’t get stuck at 10K users and 100K devices:
- Horizontal clustering supported
- Independent scaling of:
- Ingestion
- Storage
- Processing
- UI/UX
- Edge-to-cloud scalability
- Proven performance benchmarks
Watch for platforms that scale only “on slides”.
15. Edge, Cloud, and On-Prem Code Compatibility
Extremely important, so let’s get deeper to make sure you won’t need a “cloud platform” and an “edge platform”:
- Same codebase across edge and central platform
- Same development tools
- No “rewrite for edge” requirement
- No acquisition-driven Frankenstein architecture
Code portability saves months per project.
16. Partner Program Quality
Ask this question:
“How long will it take us, not you, to replace solution X?”
Good signs:
- Strong partner enablement
- Training for all roles
- Labs and real examples
- SI self-sufficiency encouraged
Bad sign:
- The vendor is always required to “finish” projects.
17. Documentation and Learning Curve
Software docs are migrating “into” the products, making them-explaining. However, a platform is a kind of software that operates rather abstract entities, so old-school documentation is still a must:
- Reference app designs
- Clear architecture explanations
- Formal and precise descriptions of structured entities
- Examples, not marketing texts
Documentation quality directly affects delivery speed.
18. AI AI AI (It’s the 2026 Edition Indeed)
In the vibe-coding era, platforms’ role is ensuring a secure, constrained, predictable and scalable playground for all categories of AI agents, from ones helping to develop your app to others that know how to provide supervisory control for a solar farm network. Hence check the following:
- The platform includes a well-designed MCP server so that you can use any agents of your choice
- Platform vendors offers “off-the-shelf” agents that assist in development and deployment processes
Make sure you won’t be cut off the trend.
19. Pricing and Long-Term Predictability
This is simple:
- Transparent pricing model
- Stable licensing rules
- Clear scaling costs
- Predictable annual adjustments
- OEM-friendly terms if relevant
Unclear pricing = commercial risk.
20. Risk Mitigation
Final uncomfortable question:
- What happens if the vendor disappears?
- Is source code escrow possible?
- Is migration realistically possible?
Enterprise customers will ask this. Be ready.
Final Takeaway
- Building an IoT solution ≠ building an own IoT platform + solution
- Platform choice defines profitability, scalability, and reputation
- Strong platforms multiply SI/OEM/ISV capabilities
- Weak platforms silently destroy margins
If a vendor fails multiple sections above — walk away early.