RMM software without the PSA you did not want

What to look for, and what to ignore

What RMM Software actually costs

RMM pricing in 2026 splits into two fundamentally different models that create wildly different economics depending on your business structure. Per-endpoint pricing charges for every device under management: great for MSPs with few technicians managing many endpoints, painful for MSPs still growing their client base. Per-technician pricing charges a flat rate per technician with unlimited endpoints, which is great for MSPs with large endpoint counts, but the per-technician fee must be high enough to cover the vendor's infrastructure costs, which means each seat runs $99–$209/month. Here is what the market actually charges.

For a growing MSP managing 1,000 endpoints across 30 clients with 5 technicians: per-endpoint pricing (NinjaOne at ~$2.50/endpoint) would run approximately $2,500/month plus a separate PSA at ~$350/month, totaling $2,850/month. Per-technician pricing (Atera at $129/technician with built-in PSA) would run $645/month. The per-technician model saves $2,200/month, until you add more technicians. At 15 technicians and 3,000 endpoints, the gap narrows. At 25 technicians and 3,000 endpoints, per-endpoint becomes cheaper. Model your 12-month and 24-month projections for both technician headcount and endpoint growth before choosing a pricing model.

How to compare them

Patch management reliability and third-party application coverage

Every RMM patches Windows. The differentiator is how reliably it patches third-party applications: the Chromes, Zooms, Adobes, and Java runtimes that attackers actually exploit. A platform that supports 200 third-party apps is meaningless if patch deployment fails silently on 15% of endpoints.

Ask: During your POC, deploy a third-party patch to 100+ endpoints and measure the success rate 24 hours later. Ask the vendor for their average patch deployment success rate across all customers. If they cannot answer or deflect to 'it depends,' be cautious.

Remote access speed and reliability under real-world conditions

Remote access is used dozens of times per day by every technician. A 2-second connection delay versus a 10-second delay multiplied across thousands of sessions per month is the difference between a responsive MSP and one that frustrates both technicians and end users.

Ask: Test remote access to endpoints on different network conditions: corporate LAN, home WiFi, and cellular hotspot. Measure connection time from click to interactive session. Test file transfer speeds. If the vendor demo only shows access on a local network, insist on testing over the internet.

Automation depth and scripting flexibility

The margin difference between a profitable and unprofitable MSP often comes down to how much routine work is automated. An RMM with a flexible scripting engine and event-driven automation multiplies technician capacity. One that restricts you to pre-built automations caps your efficiency.

Ask: Can you run custom PowerShell, Bash, and Python scripts? Can scripts be triggered by monitoring alerts, schedules, or manual execution? Is there a community script library? Can you test scripts on a single endpoint before deploying to thousands?

PSA integration quality, not whether an integration exists

Every major RMM claims PSA integration. The quality of that integration (whether it creates tickets with the right priority, maps devices to the correct client, populates configuration items, and updates ticket status when the alert resolves) varies enormously.

Ask: Set up the PSA integration during your POC and generate 50+ alerts. Verify that tickets are created with the correct client, device, priority, and category. Check whether resolved alerts automatically close tickets. Test bi-directional sync if the vendor claims it.

Multi-tenant management and per-client isolation

For MSPs, every client is a separate security boundary. Policies, data, reports, and access controls must be isolated between tenants. A misconfigured cross-tenant policy that reboots every client's endpoints during business hours is a career-ending event.

Ask: Can technicians be restricted to specific client tenants? Can policies be scoped per client, per site, and per device group? Can you generate per-client compliance reports for QBRs? How does the platform handle technician offboarding? Can you revoke access to specific clients without removing the technician entirely?

Contract terms and exit flexibility

Some RMM vendors lock MSPs into multi-year contracts with auto-renewal clauses, annual price escalators, and punitive early termination fees. If the platform underperforms, you need the ability to leave without financial penalty.

Ask: What is the minimum contract term? Is there an auto-renewal clause, and what is the cancellation notice period? Are there annual price increase caps? Can you export your data (inventory, scripts, policies) if you leave? What is the agent uninstall process?

Before you buy

1. 1Count your current endpoints by client, by OS (Windows, macOS, Linux), and by type (workstation, server, network device). This determines which pricing model is favorable and which platforms support your environment.
2. 2Calculate your endpoint-to-technician ratio. If it is above 300:1, per-technician pricing is likely cheaper. If it is below 200:1, per-endpoint pricing may be more economical. Run the math for both models at your current scale and at projected 12-month growth.
3. 3Document your PSA requirements. If you already run ConnectWise Manage or Autotask, prioritize RMM platforms with deep native integration. If you do not have a PSA yet, consider platforms that include one (Atera, Syncro, SuperOps) to avoid a second subscription.
4. 4List your top 5 automation use cases in priority order (e.g., automated patching, disk cleanup, user onboarding scripts, software deployment, compliance reporting). Weight your evaluation toward the platform that handles these workflows best.
5. 5Verify the RMM vendor's security posture: SOC 2 Type II certification, MFA enforcement on the admin console, IP allowlisting support, and a documented incident response history.
6. 6Test remote access speed and reliability during the POC, not on the vendor's demo, but on your real endpoints over real network connections. This is the feature your technicians will use most.
7. 7Evaluate the scripting engine by building or porting your 3 most complex automation scripts during the POC. If the scripting engine cannot handle your real workflows, the platform will cap your automation maturity.
8. 8Read the contract terms completely: minimum term, auto-renewal clause, cancellation notice period, annual price escalator, and early termination penalties. Negotiate for a 1-year initial term.
9. 9Confirm data export capabilities. If you leave the platform, can you export inventory data, scripts, and configuration policies? A vendor that traps your data is a vendor that knows their retention depends on switching costs, not product quality.
10. 10Check the vendor's recent product release cadence. How frequently do they ship meaningful features, bug fixes aside? A platform that has not shipped a significant feature in 6+ months may be coasting on its install base.
11. 11Talk to 2–3 reference customers, not the vendor-provided references, but MSPs you find on r/msp, MSP community Slack groups, or peer groups. Ask about their real experience with support escalations, platform outages, and surprise price increases.
12. 12Run a 30-day proof of concept with 100+ endpoints across at least 3 client environments. Test patching through a full cycle, validate the PSA integration under real alert volume, and measure agent performance impact on your oldest hardware.