Perspective

SMEs are not small enterprises: what the big MSP tools keep getting wrong

I have spent my career on both sides of a line most people only see one side of. By day I have spent years in senior leadership at some of the world's largest technology and enterprise storage organisations, where downtime is measured in money per minute and an auditor can ask you to prove anything. In the evenings and weekends, I run a small MSP, where I am the one carrying the phone. Sitting in both chairs has made one thing obvious: the tools most of us are handed were designed for a business that looks nothing like ours.

The big platforms are built for the biggest buyer in the room

Watch how the large MSP platforms actually make decisions and it all makes sense. Their best customers are the fifty-technician shops and the roll-ups, so that is who the product serves. You see it in the pricing, which meters per technician and turns a growing team into a growing bill. You see it in the configuration surface, hundreds of policies and toggles that assume someone whose whole job is administering the tool. You see it in the add-on menu, where the feature you thought you were buying turns out to live behind a second line item. And you see it in the sales motion, built around demos, onboarding calls and annual commitments.

None of that is stupid. It is a rational response to where their revenue comes from. The problem is that a two-person MSP inherits a platform tuned for a company two orders of magnitude larger, and pays for the privilege in money, time and complexity it does not have.

An SME is not a small enterprise

The tempting assumption, and the one the big tools quietly make, is that a small business is just an enterprise with the numbers turned down. It is not. The physics are different.

• There is no tooling admin. Nobody's job is to configure the platform. The person setting up alerting is the same person answering the ticket, invoicing the client and driving to site. Every hour of setup is an hour not spent on the work.
• There is no procurement buffer. The person choosing the tool is the person paying for it out of margin they can feel. A surprise add-on is not a line in a spreadsheet, it is money out of the founder's pocket this month.
• Downtime is personal. When a client's server falls over, there is no follow-the-sun team. It is you, at 2am, with the client's business on your shoulders. The tool needs to help you fix it, not give you a dashboard to admire it in.
• Every hat sits on one head. RMM, PSA, security, backups, Microsoft 365, remote access, reporting. An enterprise has a team per box. An SME has a person for all of them, so the tool that stitches them together is worth more than any single feature.

Give that person an enterprise platform and you have not empowered them, you have handed them a second job. What they need is not fewer capabilities. It is the same capabilities without the assumption that someone else will operate them.

What enterprise actually taught me, and what it did not

Here is the part people get wrong when they hear "built by someone from the enterprise world". They assume it means enterprise bloat, more process, more configuration, more meetings. It means the opposite.

What genuinely transfers from running technology at serious scale is the discipline. When downtime is not an option and an auditor can ask you to prove your controls, you learn to build things that do not fall over quietly, that fail loudly and safely, that keep one customer's data provably separate from the next. You learn that reliability is a feature you design in, not a thing you hope for. That standard is worth bringing to a small MSP.

What does not transfer is the weight. The committees, the change-advisory theatre, the twelve-week rollout for a config change. The trick is to keep the standard and throw away the ceremony, and you can only do that if you have actually lived on both sides and know which is which.

And then there is the vibe-coding wave

There is a lot of noise right now about how anyone can build software with AI, and to be fair, a lot of it is true. You can vibe-code a slick dashboard and a clever chat assistant in a weekend. The AI layer, the part everyone is excited about, is genuinely the easy bit now.

But a full MSP platform is not a dashboard. The hard part was never the AI or the pretty screens. It is the plumbing nobody demos: an agent that actually runs on every Windows, Mac and Linux machine, survives reboots and updates, patches, and lets you take control when a user is stuck. Deep, careful integrations into Microsoft 365, Defender and your backup vendors. Multi-tenant security that holds up when it matters. The reliability to still be right at 2am when something is genuinely on fire. That is months and years of unglamorous work, and no amount of AI writes it for you, because most of it is judgement about what actually matters, learned by doing the job.

So I am relaxed about the wave. Point tools that solve one problem with AI will keep appearing, and some will be good. But the thing you can hand your whole business to is not a weekend build, and it never was. If anything, the flood of shallow tools makes depth more valuable, not less.

What I actually want from a tool

When I sit in the MSP chair, the list is short. One price I can plan a business around, with no per-technician tax and no surprise renewal letter. Every feature included, because I do not have time to work out which tier hides the thing I need. An AI that does the boring triage so my evenings are my own. And underneath it all, the quiet confidence that it was built to a standard, by people who have actually had to fix the thing at 2am.

I could not find that tool, so I built it. That is really the whole story behind Helios. Not a startup guessing at what MSPs want from a whiteboard, but the platform I wanted to pay for, built by someone who runs on it every day and holds it to the standards the enterprise world taught me were not optional.