In this Sherweb Perspectives piece, guest contributor Kelvin Tegelaar shares why it’s so important to keep scalability in mind when building out MSP tools and processes.
I’ve been a CTO and MSP owner for a long time. We’ve grown fast, and growth has a way of exposing problems you don’t see early on. One of the biggest ones is scale, and I mean that in the most boring, unromantic way possible.
People outside the MSP world talk about scalability as if it’s a feature. Something you’ll add later; a checkbox you tick when you introduce multitenancy. That’s not how it works in practice for those of us looking to scale MSP operations. At some point, volume changes the rules entirely and pretending it doesn’t just makes everything harder.
Let’s use PowerShell as an example: one function call is nothing. Doing the same thing hundreds (or millions) of times is where pain starts.
When small things stop being small
I like building things, and I still do it myself, even when I probably shouldn’t. This piece of PowerShell worked fine locally. It worked fine on a single tenant. No surprises there.
Then you run it across a couple of hundred tenants and suddenly it’s a different problem.
Rate limits that never mattered now do. Tokens expire at slightly different times. Some tenants are just weird for reasons nobody remembers anymore. Errors you never saw before start showing up randomly.
None of these are unique. It’s just volume, and volume turns small assumptions into expensive mistakes.
This is where MSPs live. We don’t deal with clean, uniform environments. We deal with accumulated history, half-finished migrations, customers who did things five years ago and forgot about them. If something doesn’t handle that reality, it doesn’t matter how well it works in a demo. When it comes to scaling MSP operations, things will get very messy, very quickly.
This isn’t just a technical problem
The same scenario happens on the business side of things as well. You can handle a few customers manually. You can handle a few exceptions manually. You can handle a few special cases manually.
Then one day, you can’t. Not because people are bad, but because repetition without structure eventually collapses. Hiring more people helps for a while, but after that you’re just scaling inconsistency.
This is where a lot of enterprise vendors completely miss the point. They build for a single environment and then try to stretch it across many. Or they assume MSPs can just add staff to compensate. Neither holds up for long.
Where things break down
I’ve seen brilliant companies hack away at growth, but what they lack is proper leverage to scale MSP operations the right way.
Engineers spend their time resolving problems that already have answers. They repeat troubleshooting steps, rebuild scripts and reinvent processes because there’s no shared, scalable way of doing things.
Sending an engineer to get his MS-102 or any other certification doesn’t fix this, but the sad truth is that tools don’t automatically fix this either. You can’t tool your way out of bad processes!
What does help is practical knowledge that’s already been used at scale. Patterns that assume failure. Automation that expects inconsistency. Solutions that were built knowing they would run hundreds of times, not once.
That’s also why it matters who builds MSP tools: experience shows. A lot of vendor staff have never lived in this world. They don’t see how their products are used once volume enters the picture.
How to scale MSP operations effectively
Scale changes behavior, in code and in companies. We’ve seen this first-hand with CIPP. Over 10,000 MSPs use it now, managing millions of tenants. The problems you face at that point are not the problems you plan for on day one.
If something only works when everything is clean and predictable, it’s not ready. If something relies on people remembering how to fix it every time, it won’t survive growth.
MSPs don’t need perfect tools or perfect engineers. They need approaches that assume repetition, failure and volume from the start. Solving a problem once is fine; having it still work the 200th time is where value shows up.
Community and feedback matters
This is also why community matters more than roadmaps. No single MSP sees every edge case. No internal dev team lives with consequences the way operators do. Scale exposes things one environment at a time, and the only way to stay ahead of that is shared experience.
Patterns emerge faster when feedback loops are short and public. Problems get solved once instead of a hundred times in isolation. Tools stop being shaped by assumptions and start being shaped by reality. That’s the difference between something that looks good and something that actually works for an MSP.
Final thought
You can’t personally have the experience to do everything anymore. Stop trying. Build in the open and build for the mess. That’s where scale really lives!
Work with a partner that empowers you to scale MSP operations successfully
Built based on community feedback and collaboration, CIPP streamlines Microsoft 365 license provisioning and simplifies tenant and user management. Integrated with Sherweb’s partner platform, CIPP makes it so much easier to scale MSP operations without worrying that everything will break once with any volume.
Add that to all the ways Sherweb can help your MSP thrive, and you have a winning combination for positioning your MSP business for growth. Become a Sherweb partner today to get started.
