The Multiples Problem
MSPs are valued at 0.5x to 1.5x annual recurring revenue. SaaS companies are valued at 5x to 10x. For MSP owners who have spent a decade building revenue to $5M-$20M, that multiple gap represents millions in unrealised enterprise value.
This is the core driver of the MSP-to-SaaS pivot β not technology ambition, but wealth creation. The owner of a $10M MSP walks away with $5M-$15M at exit. The owner of a $10M SaaS walks away with $50M-$100M.
The gap is too large to ignore. Which is why so many MSPs are trying to bridge it β and why so many fail.
Why Most Pivots Fail
The MSP-to-SaaS graveyard is well-populated. Common failure modes:
1. The Customisation Trap
MSPs are conditioned to build for specific clients. When they build a product, they over-customise for their own operations or their largest client. The result is a product that doesn't generalise β it solves one MSP's problems in a way that doesn't fit others.
2. The Pricing Problem
MSPs typically price based on cost-plus. SaaS pricing requires value-based pricing. MSP owners who charge $100/hour for consulting struggle to charge $500/month for a tool that saves the client 10 hours per month. The mental model doesn't translate.
3. The Sales Motion
Selling services means building relationships, responding to RFPs, and winning trust. Selling SaaS means cold outreach, product-led growth, and self-service onboarding. These are fundamentally different skills that rarely coexist in a single organisation.
4. The Talent Gap
Product management, UX design, and growth marketing are not MSP core competencies. MSPs attempting to pivot typically assign a technical owner (usually the best engineer) who builds something functional but unmarketable.
5. The Channel Conflict
The most obvious market for an MSP-built product is other MSPs. But selling to competitors is uncomfortable β do you share your tool with the MSP that just underbid you? Most MSPs struggle with this dynamic and either pull their product from the market or price it so high that no one buys.
The Successful Pivot Pattern
A small minority of MSPs have successfully transitioned toward product revenue. Their pattern:
| Factor | Failure | Success |
|---|---|---|
| Origin | Internal tool for own use | Tool solving a recognised market gap |
| Validation | Assumed demand | 20+ pre-commitments before build |
| Pricing | Cost-plus | Value-based ($500-$2000/mo) |
| Sales | Services team | Dedicated SaaS sales motion |
| Channel | Direct only | MSP partner program |
| Engineering | Same team | Ring-fenced product team |
| Rebrand | Same brand | Separate product brand |
| Timeline | 0-3 months | 12-18 months to MVP |
The Hybrid Model
The most realistic outcome for most MSPs is not a pure pivot but a hybrid model:
Phase 1 (0-12 months): Productise one internal tool. Generate 5-10% product revenue. Validate demand.
Phase 2 (12-24 months): Build dedicated product team. Separate brand. Generate 15-25% product revenue.
Phase 3 (24-36 months): Consider whether the product can be a standalone business. If yes, spin it off with separate ownership and funding.
What Engineers Should Know
If your MSP is attempting a SaaS pivot:
- Ask about the dedicated product budget. If there isn't one, the pivot isn't serious.
- Volunteer for product roles if you're interested β services-to-product experience is valuable.
- Document what you build. If the pivot fails, your product experience is still career gold.
- Be realistic about timelines. A genuine product takes 12-18 months to validate.
- Watch for the distraction trap β if services quality drops, the pivot is costing more than it's generating.
The Honest Verdict
The MSP-to-SaaS pivot is a siren song. The promise of 10x multiples is seductive, but the failure rate is crushing. Most MSPs should focus on being great MSPs β optimising delivery, building moats through specialisation, and maximising the value of what they already have.
But for the MSP with a genuinely differentiated internal tool that other MSPs are asking to buy β the pivot is worth pursuing. Just go in with eyes open, ring-fenced resources, and 18 months of patience.
Building an MSP product? Tell your story.
Was this helpful?