Eighteen questions that shape your connected product
The right IoT architecture depends on what your product needs most. Rate seventeen concerns, name the device OS, then see which kind of system they point toward and where your priorities pull against each other.
Eighteen questions, about five seconds each. Pick the device OS, then rate each concern from 1, it hardly matters to us, to 5, it decides the design. Answer for the product you expect to ship over the next two years.
Nothing leaves your browser. No email box at the end, no score sent to me, no follow-up sequence. Your answers persist between visits, and the link at the bottom carries them, so you can compare notes with someone else on the team.
0 of 18 answered
Be intentional about the foundation: what you build, what you borrow, and how it all fits together.
Owning everything and renting everything go wrong the same way, when something other than your own judgment makes the choice.
Where your priorities point
Answer all 18 and the summary appears here. Reading it on paper works too: print the page and take it to the next architecture review.
Each bar starts at 50%. A high rating on something the approach does well raises it, and a high rating on something it works against lowers it. Low ratings do the reverse.
Your priorities point toward a hyperscaler IoT service
You value scale, contractual uptime, and fleet tooling more than owning the stack. Build on the core primitives, MQTT, X.509 device certificates, and plain JSON or CBOR, and keep your data in portable stores. The higher-level services are the ones that get retired: AWS ended IoT Analytics in 2025 and IoT Events in 2026, and Azure IoT Central retires in 2029. Budget for the integration work as well. The platform supplies building blocks, and your team still assembles the product from them.
Your priorities point toward a managed device cloud
You want devices connected, updated, and diagnosable without running servers. These services give a small team a working device SDK, software update, and provisioning on day one. Ask each vendor how you would leave: whether the device credentials and the protocol are yours to keep, and what the price looks like at ten times today's fleet.
Your priorities point toward a stack you own
You value control, long field life, and working through outages more than rented fleet tooling. At the scale most industrial products run, owning it is less work than it sounds: a small server and a tested backup carry a lot. Borrow everything you can, open protocols and open-source servers, so you own the decisions without writing the plumbing. Plan early for device provisioning and update campaigns, which take real work to do well.
Two approaches came out close, which usually means a hybrid fits. A common one is a managed device cloud for the microcontroller link with an owned server for history and rules, or an owned edge that forwards data to AWS or Azure. Decide which part of the system you need to own, and rent the rest.
What you rated highest
Tensions to resolve
You rated these pairs high together. Each is solvable, and each is easier to decide now than after the first thousand units ship.
- Control and a mainstream cloud. Keep the device side on an open protocol and your own certificates, and treat AWS or Azure as a backend you could replace.
- Long field life and a mainstream cloud. A ten-year product outlasts many cloud product lines. Use only the core services, and write down the exit path before you need it.
- Large scale and full control. Owning a 100,000-device system is practical when it is split into independent cells of a few thousand devices each. That takes an operations plan from the start.
- High availability on infrastructure you own. Four nines on your own servers is a staffing decision. Check whether devices that keep working offline make a few hours of cloud downtime acceptable.
- Control without operations work. Look for a system that installs as one service on one small machine, or a partner who runs your instance while you keep the code and the data.
- A metered link and live interaction. Stream at full rate only while someone is watching, and report by exception the rest of the time.
- Large scale and a low cost per device. Per-message and per-device fees multiply with the fleet. Price the system at your three-year fleet size, not today's.
- A simple programming model and a mainstream cloud. AWS and Azure supply building blocks rather than a programming model. Budget for the layer that ties device data, history, and the interface together for your developers.
- Offline operation and cloud uptime. If the device keeps working through an outage, cloud uptime matters less than it seems. Check whether both need to be high.
Thoughts, questions?
Is something missing, tell me about it. If your answers pulled in two directions at once, that is a good conversation to have early. The first one is free and there is nothing to prepare.