How to start a small MSP: a practical first 90 days

Short answer: Do not spend the first 90 days assembling a perfect stack. Prove that a specific client will buy a bounded service your business can deliver safely, repeatedly, and at a margin. By day 90 you should have a clear offer, an operating baseline, a weekly sales rhythm, one controlled onboarding path, and a written trigger for adding capacity.

The first problem is not technology

Technical experience helps, but it does not automatically create a managed service. A new MSP has to make five systems work together:

1. A market narrow enough to reach.
2. A promise narrow enough to price and support.
3. A delivery path that works when the owner is busy, sick, or unavailable.
4. A security and documentation floor that protects the client and the MSP.
5. A sales rhythm that produces conversations without depending on luck.

Recent public discussions in r/SmallMSP repeatedly return to the same pressure points: finding clients during the first few months, starting without being the primary technician, starting part-time, and setting contractor rates. Those threads are useful signals, not a universal formula or formal community consensus.

This guide turns the recurring questions into a testable 90-day operating plan.

Before day one, define your go or no-go boundary

Do not sign a managed client until you can answer these questions plainly:

• Who can interrupt you during supported hours?
• What happens when a priority incident arrives while you are at another job or client?
• Who can deliver if you are unavailable?
• Which services, client sizes, locations, and technologies will you refuse?
• What is the minimum security posture you require?
• How much cash and time can you invest before the business must pay you?
• Which employment, non-solicitation, confidentiality, licensing, tax, insurance, and conflict-of-interest obligations apply locally?

If you are starting alongside another job, keep the separation absolute. Do not use the employer's time, devices, software, data, accounts, relationships, or intellectual property. Written expectations and qualified backup coverage matter more than believing that emergencies will be rare.

Starting part-time can work for bounded projects or a deliberately limited service window. It is a poor fit for an agreement that implies immediate daytime response when nobody is actually available.

Days 1–30: build a service that can survive contact with a client

Choose a client profile before choosing tools

Define a starting profile with operating facts, not just an industry label:

• Typical endpoint and user count.
• Cloud, on-premises, remote, and multi-site mix.
• Supported operating systems and core applications.
• Regulatory, insurance, or contractual constraints.
• Internal contact who can approve access, spending, outages, and risk.
• Geographic and onsite limits.
• Problems the client already recognizes and will fund.

“Any small business” is not a useful profile. A 15-user professional office with Microsoft 365, no internal IT, business-hours support, and one location creates a much clearer starting boundary than “SMBs that need technology.”

Market focus is not permanent. It gives the first sales message, onboarding checklist, stack trial, and price a real environment to fit. The U.S. Small Business Administration's planning guidance similarly connects market research, competitive analysis, startup costs, and the business plan rather than treating them as separate exercises.

Write a one-page operating plan

Your first plan should answer:

• Client: Who is the starting client profile?
• Problem: Which recurring operational risks are you taking ownership of?
• Offer: What is included, excluded, and separately quoted?
• Coverage: Which hours, channels, response targets, and escalation paths apply?
• Delivery: Who performs, reviews, approves, and documents the work?
• Security floor: Which controls and access practices are mandatory?
• Economics: What must the client pay for the promise to remain supportable?
• Acquisition: Which two or three channels will run every week?
• Capacity trigger: What evidence will cause you to add a contractor or employee?
• Exit: How will the client receive data, credentials, and documentation if the relationship ends?

A lean plan is enough when it changes operating decisions. The SBA's business-plan guide includes customer segments, channels, cost structure, revenue streams, key resources, and strategic partners—all useful when the owner is deciding what must exist before the first contract.

Define the minimum deliverable service

Write the first offer as an operating commitment:

• Supported users, devices, sites, cloud tenants, and applications.
• Ticket intake and supported hours.
• Priority definitions and response targets.
• Patch, monitoring, backup, restore, identity, and endpoint-security responsibilities.
• Vendor coordination and onsite limits.
• Project, after-hours, incident, compliance, and procurement boundaries.
• Client responsibilities and approval contacts.
• Onboarding, term, renewal, price-review, and offboarding rules.

Use the scope and SLA boundaries guide to keep the promise finite. If the service cannot be described without saying “whatever they need,” it cannot be priced or delegated reliably.

Build functions before buying a large stack

Your operation needs these functions from the beginning:

• Named identity and strong authentication for administration.
• A controlled record of assets, contacts, vendors, access ownership, and exceptions.
• One place for requests, actions, approvals, time, and closure evidence.
• Monitoring and patch evidence appropriate to the service promise.
• Backup ownership and a tested restore path where backup is included.
• Secure documentation and a way to export it.
• Recurring billing and reconciliation.

An RMM, PSA, documentation platform, and billing system may provide those functions, but purchasing them does not prove the workflow. Use the tool stack selection framework to pilot tools against real acceptance tests and contract terms.

Rehearse the service before selling it

Run tabletop and hands-on tests with a lab or authorized environment:

1. A new user needs access.
2. A laptop is missing critical patches.
3. A backup job is green but a restore is requested.
4. A priority ticket arrives outside the owner's availability.
5. A vendor blocks progress for three days.
6. A privileged credential must be rotated.
7. A client asks for work outside scope.
8. The relationship ends and all data must be transferred.

For each test, record intake, owner, approval, action, evidence, client communication, billing treatment, and closure. The gaps become your first process backlog.

Days 31–60: create a repeatable path to first clients

Sell a specific operating result

Avoid leading with a list of tools. A small business buys reduced uncertainty: accountable support, known response paths, recoverable systems, safer administration, or a controlled transition away from ad hoc IT.

A useful starting statement has four parts:

We help [defined client] reduce [recognized operational problem] through [bounded managed service], with [evidence or service boundary].

The statement should make it easy to decide who is not a fit.

Use multiple channels, but one weekly cadence

Referrals matter, but “wait for word of mouth” is not a process. Start with a small prospect and partner list that you can research properly:

• Former professional relationships you may contact ethically and legally.
• Accountants, telecom providers, cabling firms, software consultants, security specialists, and other adjacent providers.
• Local business groups and industry associations.
• Carefully selected businesses that match the client profile.
• Existing project clients who may have a recurring operational need.

Every week, record:

• New researched accounts.
• Relevant introductions requested.
• First conversations.
• Discovery calls.
• Qualified opportunities.
• Assessments or proposals.
• Wins, losses, reasons, and source.
• Next action and date for every open opportunity.

Cold email, calls, LinkedIn, events, partnerships, and referrals can all work differently by market. The first 90 days should identify which channel produces qualified conversations for your profile—not declare a universal winner after a few attempts.

Use discovery to disqualify risk

Before proposing managed service, confirm:

• Business size, locations, hours, and critical workflows.
• Current IT ownership and why change is being considered.
• Users, devices, servers, tenants, vendors, network, backups, and security controls.
• Existing incidents, unsupported systems, projects, and deadlines.
• Decision maker, budget process, contract dates, and target start date.
• Regulatory, cyber-insurance, audit, or customer requirements.
• Whether the client accepts your minimum security and access standards.

Discovery is not free design work. When the environment requires deep assessment or remediation planning, define and price that work separately.

Days 61–90: onboard one controlled promise

The first managed client should validate the operating model, not force the business to impersonate a mature 24/7 provider.

Use an acceptance gate

Do not begin recurring responsibility until you have recorded:

• Signed scope, pricing, term, support hours, and exclusions.
• Authorized contacts and approval limits.
• Asset and identity baseline.
• Administrative-access ownership and MFA status.
• Backup ownership, retention, and restore expectations.
• Required agents, licenses, vendors, and exceptions.
• Open incidents, projects, unsupported systems, and accepted risks.
• Onboarding milestones and the date recurring responsibility starts.

The client onboarding checklist provides the detailed handoff path. When the intake reveals unknown risk, pause the affected promise or convert the gap into a separately approved remediation project.

Review the first 30 days of delivery

At the first operating review, ask:

• Did every request enter the agreed channel?
• Could the queue show owner and next action?
• Which work was outside scope?
• Which alerts created action and which created noise?
• Did time and direct cost match the price assumptions?
• Were decisions and credentials documented securely?
• Did any promise depend entirely on one person's memory or availability?
• What should change before accepting the next similar client?

Do not scale a workflow merely because the first month was survivable. Scale it when the evidence is repeatable.

Owner-led delivery versus business-only ownership

An owner does not have to remain the primary technician forever. At the beginning, however, someone qualified must own technical truth and client-facing delivery.

If the founder will not perform the work, establish before selling:

• A named technical owner with verified experience.
• Written availability, response, escalation, and handoff expectations.
• Access to the selected stack and a completed workflow rehearsal.
• A second path for absence or failure.
• Clear authority for routine changes and client approval for higher-risk actions.
• Enough cash to pay for delivery, rework, and escalation before the client pays.

A list of possible freelancers is not delivery capacity. Capacity exists when a qualified person has accepted the role, understands the environment and process, can access what is needed securely, and has a tested escalation path.

Contractor or employee: decide from the relationship and the work

Do not set contractor pay as a universal percentage of your client rate. Location, skill, scarcity, schedule, responsibility, tools, insurance, travel, utilization, and employment classification all change the answer.

Use a contractor when

• Work is bounded, specialized, project-based, onsite, or variable.
• You can specify an outcome and acceptance evidence.
• Demand does not yet support steady utilization.
• Independent delivery and substitution fit the real relationship.

Consider an employee when

• Work is recurring, central to the service, and needs consistent availability.
• You need close scheduling, coaching, process control, and client continuity.
• Forecastable margin can support loaded payroll and non-billable time.
• The real relationship operates like supervised employment.

For every option, model the loaded delivery cost: compensation, payroll or contractor overhead, taxes where applicable, management time, tools, insurance, travel, training, bench time, rework, and escalation. Then test whether recurring revenue still funds sales, administration, risk, and profit after delivery.

Classification is a legal and tax question, not a naming choice. In the United States, the IRS classification guide considers behavioral control, financial control, and the relationship of the parties. In the United Kingdom, GOV.UK's contractor guidance notes that tax and employment-law status can differ. Use qualified local advice for your jurisdiction.

A weekly dashboard for the first 90 days

Keep the dashboard small enough to review every week:

• Qualified sales conversations created.
• Open opportunities with next action and date.
• Recurring revenue signed and start date.
• Onboarding work remaining and blockers.
• Tickets by priority, owner, and waiting state.
• Billable, included, onboarding, and rework time.
• Direct service cost and estimated delivery margin.
• Security, backup, access, and scope exceptions without an owner.
• Owner hours spent on delivery, sales, administration, and after-hours work.
• Cash runway and committed monthly costs.

The purpose is not investor reporting. It is to expose when growth, service quality, or the owner's workload is becoming unsafe.

First-90-days checklist

By day 90, confirm:

• A starting client profile and explicit non-fit profile exist.
• One bounded recurring offer is documented.
• Support hours, priorities, exclusions, and escalation are written.
• Minimum security, backup, access, and documentation standards are defined.
• The end-to-end service has been rehearsed.
• Pricing includes delivery, administration, risk, and non-billable work.
• A weekly prospecting cadence has run long enough to show real signal.
• Discovery captures both commercial fit and technical risk.
• The first onboarding uses an acceptance gate and responsibility date.
• Every ticket can show owner, next action, and closure evidence.
• A backup delivery path exists for owner absence.
• Contractor or hiring triggers are written in operational and financial terms.
• The operation can export client data and complete a clean offboarding.

Common mistake

The common mistake is building the visible parts of an MSP before the invisible operating system. A polished website, several vendor subscriptions, and a long service catalog can exist while nobody knows who answers a priority ticket, how an exception is approved, whether a restore works, or which channel creates the next qualified conversation.

Build the promise and proof first. Add tools, clients, and people only when each addition has an owner, a funded workflow, and evidence that it works.

When to change level

Add dedicated capacity when recurring work is documented, forecastable, and consistently crowds out sales, review, or safe delivery—not merely after one busy week. Strengthen the service desk when ownership and next actions live in chat or memory. Narrow the offer when every new client creates a different stack and process. Raise price or change scope when the service consumes more delivery and risk than the agreement funds.

Before expanding into 24/7 coverage, regulated environments, advanced security response, complex cloud work, or broad onsite support, confirm that qualified people, contracts, insurance, tooling, escalation, and cash can support the stronger promise.

For the cybersecurity baseline behind the business itself and its client service, use the NIST CSF 2.0 Small Business Quick-Start resources. The guide is a starting point for risk decisions, not a substitute for obligations specific to your clients or jurisdiction.