When you set out to build an IoT solution on Azure, you hit a fork in the road almost immediately, and which way you go shapes everything after it. On one side is Azure IoT Central — a managed, largely-assembled IoT application platform where a lot of the hard parts come pre-built. On the other is rolling your own: taking the individual building blocks — IoT Hub, Stream Analytics, storage, whatever visualisation you like — and assembling them into exactly the solution you want. I've now gone down both roads on real projects, and I want to save you the mistake I nearly made: choosing based on which one sounds more impressive.

The honest framing is a classic one dressed in IoT clothing: build versus buy. And like every build-versus-buy decision, the right answer depends far more on your situation than on the technology.

What each one actually is

Let me translate, because the marketing blurs the line on purpose.

IoT Central is the "buy" option. It's a SaaS application platform: you bring your devices, and a great deal of the surrounding machinery — device management, dashboards, rules, user management, the plumbing that connects sensors to something you can look at — comes ready-made. You configure rather than construct. You trade control for speed and simplicity.

Rolling your own is the "build" option. You take IoT Hub (the managed front door that your devices connect to and that handles the messaging at scale), and you wire it up yourself to stream processing, to storage, to analytics, to whatever dashboard you choose. You get to make every decision, which means you have to make every decision. You trade speed and simplicity for control.

Neither is the "real engineer's choice" and neither is cheating. They're answers to different questions.

When I'd reach for IoT Central

I'd choose the managed path when the honest priority is getting to something working, fast, without a team to maintain bespoke infrastructure. Specifically:

  • When the use case is fairly standard. If what you're building looks like a reasonably conventional IoT scenario — monitor these devices, show these readings, alert on these conditions — IoT Central has already solved most of it. Reinventing that from parts is effort spent rebuilding what you could have had for free.
  • When you don't have people to run bespoke infrastructure. This is the big one, and it echoes something I keep learning: the cost of a system isn't just building it, it's operating it. If you don't have the team to babysit a hand-assembled platform, the managed option isn't a compromise — it's the responsible choice.
  • When speed to a working proof matters more than perfect fit. For validating an idea, getting real devices sending real data into something visible in days rather than weeks is worth an enormous amount.

When I'd roll my own

I'd take the build path when the situation genuinely exceeds what a managed application can flex to:

  • When the requirements are unusual. The managed platform is opinionated by design, and those opinions are a gift right up until your needs don't fit them. When you need processing, routing, or integration that the SaaS box doesn't bend to, assembling your own stops being indulgent and starts being necessary.
  • When you need deep control over cost or data flow at scale. At real volume, or with specific data-residency or integration requirements, the fine-grained control of hand-assembled components can matter enough to justify the extra work of building and running them.
  • When it has to slot into a larger, custom data platform. If the IoT data is one input into a bigger bespoke system — which, in my smart-building world, it usually is — building with the individual pieces lets it integrate cleanly, where a walled-garden application can become an island.

The trap: choosing on enthusiasm

Here's the mistake I nearly made, and the reason I'm writing this. As an engineer, rolling your own is more fun. You get to make all the decisions, use all the interesting pieces, build something that's exactly yours. There's a real pull toward the build option that has nothing to do with whether it's the right call — it's just more satisfying to construct than to configure.

And that pull is dangerous, because it dresses itself up as rigour. "We need the control" and "the managed option won't be flexible enough" are the things you tell yourself when what you actually mean is "I'd enjoy building it more." I've caught myself mid-justification, and the tell is always the same: I'm arguing for the harder path before I've honestly checked whether the easier one would have done the job.

The question isn't "which one could I build?" It's "which one should the people who inherit this actually have to run?" Enthusiasm answers the first question. Only honesty answers the second.

The hidden cost nobody prices in

Before you talk yourself into rolling your own, price the thing that never makes it onto the comparison slide: the ongoing cost of operating what you build. It's easy to compare the two options on capability — the feature checklist, what each can technically do — and that comparison flatters the build option, because of course the thing you assemble by hand can be made to do anything. What it hides is that every capability you hand-build is also a capability you hand-maintain, forever.

The managed platform's real price isn't its subscription. It's the operational work you're not doing: the patching, the scaling, the 2am "why did the pipeline stop" that Microsoft quietly absorbs on your behalf. Roll your own and all of that comes back to you — and it doesn't appear in the build estimate. It appears six months later, as the reason your team has no time for anything new. I've watched a "cheaper" self-built solution turn out dramatically more expensive once someone honestly counted the human hours being poured into keeping it breathing.

The hybrid path most people miss

There's also a third option the either/or framing hides, and it's often the smartest: start managed, and graduate. Use IoT Central to get real devices sending real data fast, validate that the use case is actually worth building for, and — this is the underrated part — learn what your requirements really are by running something, rather than guessing on a whiteboard. Then, if and when you hit a concrete wall the managed platform can't get past, migrate the parts that need it onto custom infrastructure, with the enormous advantage of now knowing exactly what you're building and why.

That sequencing turns the build-versus-buy fork into build-after-buy, and it defuses the biggest risk of rolling your own: committing to a bespoke platform for requirements you only imagined, before a single real device proved what you actually needed. The managed option isn't just the fast path to a solution — it's the cheapest possible way to find out what your real requirements are before you spend on meeting them.

My rule of thumb

So here's where I've landed. Start by assuming IoT Central will do, and make rolling your own earn its place by pointing to a specific requirement the managed platform genuinely can't meet. Not a vague "we might need flexibility" — a concrete thing it can't do. If you can name that thing, build. If you can't, and you're reaching for the parts anyway, be honest that you might be choosing the fun path over the right one.

Most IoT projects don't need the bespoke platform, and the ones that do will tell you clearly, through a requirement that won't fit. For everything else, the managed shortcut isn't the lazy option — it's the one that respects the fact that someone, eventually, has to keep the thing running after the fun of building it is over.