How I Would Build an MSP From Scratch Today

Charles Weaver, CEO, MSP Alliance | Lessons from Season 7, Episode 368

Not long ago, someone called me and said they wanted to start a managed services practice from scratch. They had no technology purchased, a few prospects in the pipeline, and nothing else. It felt like a throwback to 25 years ago, when most of my conversations were about how to become an MSP. It also made me ask: if I were starting today, what would I do? The answer is very different from what I would have advised ten, fifteen, or twenty years ago. These fundamentals apply whether you are pre-revenue or have been in IT services for years.

Start With the Customer, Not the Tools

Before you choose a ticketing system, RMM, firewall platform, EDR vendor, or backup product, answer one question: what kind of MSP are you trying to build? That is the one piece of advice that has not changed in 25 years.

Build an ideal customer profile (ICP). Ask yourself:

• Are you targeting companies with 10, 50, or 500 employees?
• Will you specialize in a vertical such as healthcare, legal, financial services, professional services, or government?
• Will you focus on core IT, cybersecurity, compliance, cloud infrastructure, or strategic advisory work such as vCISO and vCIO services?

Your target customer shapes your technology, staffing, insurance, contracts, security stack, pricing, marketing, and sales approach. The profile can change, but you need a starting point, and the sequence of these decisions matters.

Lay the Three Foundational Pillars

Regardless of your size or country, a competent, secure, and resilient MSP rests on three pillars. You can build most of them before you have a single customer.

1. Certification

Start with a framework built for what you do. The Unified Certification Standard for Cloud and Managed Service Providers (UCS) is an MSP control framework that has existed for more than 20 years and is reviewed at least annually. It is published at mspalliance.org.

If your customers operate under HIPAA, SOC 2, or ISO, do not pursue those frameworks first. They are good cyber frameworks, but they were never designed as MSP frameworks and will leave considerable gaps. Using the UCS from day one helps you answer key questions. Can you demonstrate your controls? Can you deliver services repeatably? Can you recover quickly from a disruptive security or data incident? The structure benefits you even if you never pursue certification.

2. Contracts

Do not download an agreement, change the company name, and start sending it out. The same goes for asking an AI tool to write one. Have a lawyer who understands managed services review your agreements, including state-specific requirements.

MSPs have unique access to systems, data, and administrative credentials, so your agreements must clearly define scope, limitations, security expectations, payment terms, termination rights, and customer obligations. A typical structure is:

• A master service agreement (MSA) that governs the overall legal relationship, including terms, conditions, and choice of law.
• A lighter service agreement, service attachment, quote, or proposal that covers the specifics of each engagement and refers back to the MSA.

Ambiguity is not your friend. Customers must understand what is expected of them, because the MSP is not a bottomless pit for customer risk and bad behavior.

3. Insurance

Insurance is the backstop beneath your certification, contracts, security, and technology. Do not buy it just so you can say you are insured. Understand what the policy covers and look for coverage designed for how MSPs deliver services. MSP Alliance has offered such a program since 2008, built for MSPs that follow best practices, are certified, and use sound contracts.

Without any one of these three pillars, you are at significant risk. Today, I would argue it is impossible to scale without all three.

Choose Technology Based on Services

Do not ask a conference vendor, an AI tool, or even me, "What is the best RMM?" You will get a confident answer you should not trust. Start with the service: what do you want your service catalog to look like? Will you offer endpoint management, identity management, security monitoring, backup as a service, patch management, cloud infrastructure, vCISO or vCIO services, or compliance support?

Once you know that, ask a better question: "I want to deliver these services to this type of customer. Which platforms suit that segment?" That is not the final answer, but it is a far better start.

• Buy minimally. Choose the best tool you can afford in each category you need, and nothing else. The middleware that once bridged tools that could not talk to each other is largely gone, since most major platforms integrate through APIs.
• Verify independently. Ask vendors purposeful questions about functionality, compliance, and security. Then talk to MSPs with a similar stack and ask whether the tools really work together.
• Standardize aggressively. Half a dozen backup tools or four or five firewall vendors will cost you money and cut efficiency, scalability, and profitability. Standardize on as few best-in-class tools as possible for each service you deliver.

Secure Your Own House First

The cobbler's kids should not go without shoes. An MSP is an unusually attractive target because compromising one provider can open paths into many customer environments. Before you open your doors or collect your first dollar, lock down your own practice:

• Strong authentication and least-privilege access
• Tight control of administrative access
• Endpoint protection and logging
• Credential handling
• Documented onboarding and offboarding for customers and staff
• Backup and recovery after an incident
• Vendor risk management, which is easier with fewer vendors

Build Around the Customer, Not the Ticket

Do not make the ticket your primary unit of measurement. Customers do not care how many tickets you open or close. They want stability, predictability, productive employees, and protection from upstream risk. They are buying outcomes, not alerts or a dashboard showing 99.9 percent uptime.

Ask yourself this: if ticket volume dropped to zero tomorrow, would your customers still see the value you deliver? If the answer depends on ticket counts, you are selling activity, not outcomes.

Price the Service, Not Your Labor

With AI changing the profession, I would price around the defined service obligation, not technician hours. Move away from block hours and blended hourly rates as quickly as you can. Pricing can be per user, per endpoint, or a hybrid of the two. I like to call the hybrid risk-based pricing.

Some requests do not fit a per-user or per-endpoint model. Consider a customer who asks how to use AI in their business. That might be a project, or an advisory tier above your base managed services. Whatever you choose, do not give that advice away. It is valuable, so do it well and charge for it.

Standardize, Document, Then Automate

Everyone wants automation, but you cannot automate chaos. First standardize how you deliver each service, then document it so your team performs it the same way every day. Only then ask where manual effort can be automated and whether your tools support it.

When every customer environment is different, every service becomes an exception, and automation becomes nearly impossible. That is why break-fix is dying. Chaos is not white glove, boutique, or bespoke. It is just chaos.

Build a Practice You Can Walk Away From

Could you disappear for 30 days? You do not need 50 or 100 employees to do it. Ten or twenty people can be enough. Ask yourself:

• Can someone else sell for me and onboard new customers?
• Will invoices go out and technicians show up every day?
• Will technical problems escalate without me?
• Can someone else handle a security incident or explain our services to a customer?

If you cannot answer yes to all of these, you have built a job for yourself, not a scalable business. Start working toward this on day one, even if it begins with a single day away.

Measure the Business Model

Dashboards from your RMM vendor are fine, but also track whether the business model works:

Being busy is not an indicator of quality. These numbers show whether you have a sustainable managed services organization or just a perpetually busy IT company.

Stay Focused

Do not try to be everything to everyone. A new MSP does not need 25 services, six security packages, or three backup platforms. Focus on customers who are willing to pay and who fit the business you want to build.

Build an MSP Practice, Not an IT Company

If I were starting an MSP tomorrow, I would not begin by shopping for software or hunting for customers. I would design the company first: who we serve, which problems we solve, which services solve them, and which standards govern how we operate. Then I would put certification, contracts, and insurance in place. After that, I would build a standardized service model and technology stack around a narrowly defined customer. I would build in security from day one, understand the economics of every service line, and document processes so no knowledge lives only in one person's head.

It does not take a lot of money. It takes a little thought. Do not rush, and do it right the first time. If you get the fundamentals right, almost everything else gets easier.

Have thoughts on what has worked or not worked for you? Send us a note. Until next time, stay safe, and get certified.