Key Takeaway: The minimum viable MSP stack is four tools: RMM, PSA, backup, and EDR. Pick one solution per function, standardize across every client, and build your tool costs into your pricing from day one. The tools matter less than the discipline you run them with.
The question gets asked in r/MSP every week: what tools do I need to start an MSP? The answers vary wildly, from people recommending enterprise stacks that cost more than a new MSP’s first month of revenue, to people suggesting you can run a managed services business out of a spreadsheet and a free remote access tool. Neither extreme is right.
This guide covers the categories you need, the order to add them, and how to think about what they cost. Product names appear as examples of what MSPs commonly evaluate, not as endorsements, and I have left out vendor price tags on purpose. Pricing changes often, varies by volume, and is usually negotiated. Get current quotes directly from vendors before you build a budget.
In this article
- The Principle Before the List
- The Minimum Viable MSP Stack: Four Tools
- What to Add Next: The Second Layer
- Budgeting for the Stack
- The Pricing Model Decision: Per-Device vs. Per-Technician
- The Tools You Do Not Need Yet
- The Stack Is Not the Business
- Frequently Asked Questions
The Principle Before the List
Standardize on one solution per function and require every client to move to your standard. This is the single most important tooling decision you will make, and it is not about which tool you pick. It is about committing to a stack and holding the line.
The MSPs that struggle with their stack are almost always the ones who said yes to whatever the client already had. One client on ConnectWise, another on Autotask, a third on a homegrown ticketing system. That is not a stack. It is chaos with a monthly invoice. Standardization is what makes you scalable, what lets you build runbooks that work across clients, and what lets you onboard a new technician without spending three weeks explaining why every client environment is different.
The Minimum Viable MSP Stack: Four Tools
These are the four categories you need before you take your first managed services client. Everything else can wait.
1. RMM: Remote Monitoring and Management
Your RMM is the operational backbone of your MSP. It monitors client endpoints, deploys patches, runs scripts, and gives you remote access. Without it, you are doing break-fix with a monthly invoice, not managed services.
NinjaOne, Atera, Syncro, SuperOps, and ConnectWise Automate are among the platforms MSPs commonly evaluate. Some are built for lean teams and quick onboarding. Others are built for larger operations and come with longer implementation projects and more rigid contracts. A new MSP generally does better with the first kind, because speed to value matters more than depth of customization when you have a handful of clients.
When you compare options, look at how licensing works. Some platforms charge per device and some charge per technician with unlimited endpoints. That choice changes your cost curve as you grow, and the pricing model section below explains how to think about it.
What matters more than which RMM you choose is how you configure it. An RMM configured to generate maximum alerts creates alert fatigue. Configure it to surface what matters, suppress what does not, and build a review process that ensures alerts are actually reviewed by a human who can act on them.
2. PSA: Professional Services Automation
Your PSA is where tickets live, where time gets tracked, and where invoices get generated. It is the operational record of your business. If it is not in the PSA, it did not happen.
The PSA market has split into two camps: dedicated PSAs such as HaloPSA and ConnectWise PSA, and unified RMM and PSA platforms such as Atera, Syncro, and SuperOps. For new MSPs, a unified platform often wins on simplicity: consolidated billing, one vendor relationship, and fewer integrations to maintain. A dedicated PSA makes sense if you already have an RMM you are committed to or you expect your service desk workflows to get complex.
Enterprise-focused PSAs tend to involve long implementation timelines and multi-year commitments. They are tools you grow into, not tools you start with.
The PSA is where your documentation discipline either gets built or does not. From your first client, every ticket should close with notes on what was found, what was done, and what the client should watch for. That discipline is the difference between a business that can scale and one that depends on your personal memory.
3. Backup and Business Continuity
Every managed services agreement needs a backup solution. More importantly, it needs a backup solution you have actually tested. The backup that has never been tested is not a backup. It is an assumption.
MSPs commonly evaluate Veeam, Acronis, Comet, Cove, and Datto, and the right fit depends on what you protect. Server and virtual machine environments, SaaS data, and workstations each have different requirements. Clients with tight recovery time objectives may need appliance-based instant virtualization, which costs more and often ties you to a vendor ecosystem. Clients with simple needs may be well served by lighter cloud-first tools. Ask each vendor where the data lives, who controls the storage, and how restores are tested.
Whatever you choose, the process matters more than the product. Document every backup configuration, schedule quarterly restore tests, and report the results to clients. That process is what separates you from the MSP that discovers the backup did not work during a ransomware recovery.
4. Endpoint Security: EDR, Not Just Antivirus
Antivirus detects known threats by signature. Endpoint detection and response monitors behavior and detects unknown threats. Antivirus alone is no longer sufficient for business-grade security, and cyber insurance carriers increasingly require EDR as a condition of coverage.
The key question when comparing EDR products is who watches the alerts. Some platforms are powerful engines that assume you have security analysts to operate them. Others, such as Huntress, pair the software with a human-led security operations team that triages alerts for you, which matters if you do not have dedicated security staff. Most SMB-focused MSPs are better served by the second model, because a tool nobody has time to monitor does not protect anyone. Lower-cost options exist, but check whether they include any human response before you treat them as equivalent.
What to Add Next: The Second Layer
Once you have the four core tools in place and your first clients onboarded, these are the next additions in priority order.
DNS Filtering
DNS filtering blocks malicious domains before a connection is established. It is one of the highest-impact, lowest-cost security controls available, and cyber insurance carriers increasingly ask about it. Look for a multi-tenant console so you can manage every client from one place, and compare how each vendor handles policy templates and reporting.
Documentation Platform
If your PSA does not handle documentation well, a dedicated platform is worth the investment early. Documentation is the infrastructure of a scalable MSP. IT Glue and Hudu are two platforms MSPs frequently compare. Weigh integrations, hosting options, credential handling, and how the vendor’s ownership and roadmap fit your long-term plans.
Security Awareness Training
Cyber insurance carriers ask for documented security awareness training as a condition of coverage. It is also a service you can charge for separately, which makes it a revenue line as well as a security control. Check whether a platform you already own includes a training module before you buy another vendor.
Email Security
Email is still the primary attack vector for most SMB breaches. Microsoft’s built-in protections provide a baseline for Microsoft 365 environments. Third-party email security gateways add layers for clients who need more than the baseline, such as those in regulated industries or with a history of phishing incidents.
Password and Credential Management
You need a secure way to store client credentials that is accessible to your team and auditable. Many documentation platforms include credential management, and standalone options exist. Do not store client passwords in a spreadsheet or a shared email account.
Budgeting for the Stack
New MSPs frequently underestimate their tool costs and underprice their services as a result. The fix is a simple process, not a price list.
First, list every tool in your stack by category. Second, get a current written quote from each vendor for the number of users, endpoints, and technicians you expect in your first year. Third, add the totals and divide by the number of users you expect to support. That figure is your tool cost per user, and it has to sit comfortably inside your per-user price with room left for labor, overhead, and profit.
Revisit the exercise whenever you add a client segment or hire a technician. An MSP that does not account for tool costs in its pricing tends to discover the problem when it tries to hire its first employee, and by then the agreements are signed. If you need a framework for the revenue side, the managed IT services cost guide linked below walks through how per-user pricing is built.
The Pricing Model Decision: Per-Device vs. Per-Technician
How your RMM and PSA charge has a larger impact on your total stack cost than which specific tool you choose. This is the most underappreciated decision in MSP tooling.
Per-device pricing is predictable and scales with your client base. It rewards efficiency because your cost per device stays constant regardless of how many technicians you have.
Per-technician pricing is usually cheaper when each technician manages many devices, which is common for solo operators and very small teams. The math can reverse once you have multiple technicians who each manage fewer devices.
Run the numbers for your specific situation before committing. The right model depends on your device-to-technician ratio, and that ratio changes as you grow.
The Tools You Do Not Need Yet
New MSPs frequently over-invest in tooling before they have the clients to justify it.
A dedicated SIEM is valuable at scale. For a new MSP with fewer than 10 clients, it is overhead you cannot operationalize. A separate NOC platform is a scaling tool, not a starting tool. Multiple RMMs are a trap: the cost of running two RMMs is not just the licensing, it is the operational complexity, the training burden, and the documentation inconsistency. The most expensive version of everything is a cash flow problem disguised as a quality decision.
The Stack Is Not the Business
The most important thing to understand about your MSP stack is that it is infrastructure, not differentiation. Your clients do not care which RMM you use. They care whether their systems are monitored, their backups work, and their team can get help when something goes wrong.
Pick reasonable tools, configure them well, standardize across clients, and build the processes that make the tools useful. The MSP that wins is not the one with the best stack. It is the one with the best operational discipline around a good-enough stack.
Frequently Asked Questions
What is the best RMM for a new MSP?
There is no single best answer, and anyone who gives you one without knowing your client base is guessing. Shortlist two or three platforms that fit your size, run a trial against a real client environment, and judge them on how fast you can onboard devices, how clean the alerting is, and how good the vendor support is. Solo operators should look hard at per-technician pricing models, since the math changes when each person manages many devices.
Should I use a unified RMM and PSA or separate tools?
For new and small MSPs, a unified platform usually reduces operational overhead: one vendor, one invoice, and a shared data model. Separate tools make sense when you already have an RMM you cannot displace or when your ticketing and billing needs outgrow what a unified platform offers. Either way, pick one per function and standardize across every client.
What is the minimum security stack for a new MSP?
Endpoint detection and response, tested backup, and DNS filtering are the baseline, with security awareness training and email security close behind. Cyber insurance carriers increasingly ask about these controls, so documenting them from your first client saves you a scramble at renewal.
How do I budget for my MSP tool stack?
Start from your per-user price and work backward. List every tool, get a current written quote for your expected endpoint and user counts, and add them up. Then confirm that tool costs leave enough margin to pay for labor and still turn a profit. Vendor pricing changes often and varies by volume, so quote it yourself rather than relying on anyone’s published numbers, including ours.
Do I need a documentation platform on day one?
You need a system of record on day one, whether that is your PSA’s documentation features or a dedicated platform. A dedicated tool becomes worth it as soon as more than one person is working in client environments and the knowledge can no longer live in your head.
About Brent Lacy: Brent Lacy is a technology advisor and the voice behind Rewired MSP. He helps MSPs operate with greater maturity and helps business owners make IT choices that make them more secure and more efficient. He is the author of Rewired MSP: Mastery, Scalability & Performance, vCIO Rewired: Virtually Conquering IT Obstacles, and Near Miss: Preventable IT Failures Threatening Your Business Security.
Related Reading
- From Technician to MSP Owner: What Nobody Tells You Before You Make the Jump
- MSP Documentation: Why It Matters, What to Document, and How to Make It Stick
- MSP Cybersecurity: The Monitoring Trap, Backup vs. Continuity, and What Competent Security Looks Like
- Building a Documentation Culture: The Invisible Engine of MSP Scalability
- Backup Is Not Business Continuity: What Every Business Owner Must Know
- What Does Managed IT Services Cost? A Transparent Pricing Guide
Related Reading: NOC vs SOC | MSP incident response plan | PSA best practices | SIEM for MSPs
