The real IT decision for PE-backed companies is not whether to outsource or stay in-house. It is whether leadership has continuous visibility into what the company runs, what it pays for, and what risks are quietly compounding beneath the support model.
There is a moment in nearly every post-acquisition period when the new CEO or the operating partner turns to the CFO and asks a version of the same question: who is going to run IT from here?
It gets answered fast. Roughly 60 to 70 percent of PE portfolio companies bring in a managed service provider within 18 months of close. It has become one of the standard moves in the early value creation playbook, alongside procurement consolidation and finance function cleanup.
The speed is understandable. The rigor behind it often is not. Most of these decisions get justified with a single figure: MSPs are typically pitched on a 25 to 40 percent reduction in IT operating costs compared to keeping a team in-house. That number is accurate, and it is also the wrong basis for the decision. Cost is what gets presented to the board. It is rarely what determines whether the company is better off a year later.
Bottom line The outsource-versus-in-house choice is not the decision that protects value in a portfolio company. The decision that matters is whether leadership has continuous visibility into what the company runs, what it pays for, and what it is exposed to, regardless of who holds the support contract. Get the support model wrong, it is expensive to fix. Get the visibility layer wrong, it is invisible until diligence, an insurance renewal, or an integration exposes it, and by then the cost has already compounded. |
The Number That Gets Quoted and the Question That Gets Skipped
A 25 to 40 percent saving looks compelling until you look closely at what it is comparing. Most of these analyses stack the fully loaded cost of an internal team, salaries, benefits, tools, training, against a flat MSP retainer. On that basis, outsourcing wins almost every time.
What the comparison leaves out is everything that actually determines the outcome: security posture heading into the next add-on’s due diligence, uptime during a systems migration, response time when a plant floor system goes down overnight, and whether IT can keep pace with the deal thesis rather than lag behind it.
CFOs who anchor the decision to run-rate savings alone tend to discover the real cost later. It shows up during the next bolt-on acquisition, when systems need to be integrated quickly and nobody planned for that. It shows up at cyber insurance renewal, when the underwriter asks for evidence of controls the MSP was never asked to implement. It shows up at exit, when a buyer’s diligence team starts asking about IT governance and the answers are thin.
Why This Is Harder to Get Right in a PE Context
For a standalone private company, build versus buy for IT is largely an operating question. In a PE-backed company, it is a value creation question, and that shifts the calculus in a few important ways.
Holding period. A three to five year hold means every IT decision has to earn its keep faster than it would in a business with an indefinite time horizon. An internal team that takes 18 months to mature is racing against a clock the operating company does not fully control.
Roll-up complexity. A platform company completing four or five add-ons over a hold period needs IT capacity that can absorb new environments, standardize tooling, and consolidate SaaS spend without slowing the deal team down. This is where the build-versus-buy line gets blurry. Some MSPs are strong on steady-state support and weak on integration work. Some internal teams are the reverse.
Exit readiness. Buyers and their advisors look closely at IT governance, data security, and license compliance during diligence. A disorganized SaaS estate or a support arrangement nobody can clearly explain becomes leverage against the seller at the negotiating table. That risk exists whether IT sits in-house or with a provider. The structure matters less than the visibility a company can produce on demand.
When In-House Actually Is the Right Call
None of this is an argument that outsourcing is always correct. It is worth saying plainly: for a certain kind of portfolio company, building an internal team is the better decision, and the current MSP-adoption trend can push leadership past that answer without much scrutiny.
Scale changes the math. A portfolio company above roughly 500 to 700 employees, with predictable, repeatable IT demand, often reaches a point where an internal team costs about the same as an MSP retainer but delivers deeper institutional knowledge of the company’s specific systems and workflows. MSPs are built to standardize across many clients. That is their strength and also their limit. A business with a genuinely unusual technical environment, custom-built manufacturing systems, proprietary platforms, a heavily regulated data architecture, often needs people who live inside that complexity every day, not a rotating support desk working from a ticketing queue.
Speed of institutional response matters too. In sectors where downtime has an immediate revenue or safety consequence, the marginal cost of an internal team that already knows the environment can be lower than the marginal cost of an MSP relearning it during an incident. This is a real tradeoff, not a theoretical one, and it deserves its own line item in the diligence model rather than a default toward outsourcing because the industry trend points that way.
The point is not that one model is universally superior. It is that the decision should be made on these grounds, deal thesis, scale, technical complexity, incident tolerance, rather than defaulting to whichever model has the better headline savings number.
What the Wrong Call Actually Costs
The mistake most portfolio companies make is not choosing outsourced or in-house support. It is choosing one or the other without building the visibility that makes the choice defensible later.
Here is a specific, anonymized example drawn from a SaaS stack review conducted on a mid-market industrial services company. Revenue sat in the $150 to $300 million range. The stack included 74 applications, a mix of legacy contracts carried over from the platform company and tools individual departments had adopted on their own over several years. There was no single owner of that stack and no consistent record of spend, licensing, or actual usage. Within the first year of ownership, the company brought in an MSP to handle infrastructure and help desk support, and the MSP performed that role competently. What nobody assigned was ownership of the application layer itself: overlapping subscriptions, unused seats, contracts renewing automatically at rates nobody had benchmarked against the market.
When that stack was finally reviewed using SaaSrooms, four contract renegotiation opportunities came back worth just under 12,000 dollars in identified savings against roughly 235,000 dollars in annual recurring SaaS spend under review, sitting untouched because no one owned the follow-through, months after they had already been flagged and approved internally. That is a modest figure on its own. Multiply it across a typical portfolio of eight to twelve platform companies, each carrying its own version of the same gap, and the number stops looking modest.
That gap has nothing to do with whether the MSP or the internal team is doing its job well. It is a visibility gap, and it can open up under either operating model.
This is the part of the build-versus-buy debate that gets missed most often. The decision about who staffs the help desk and patches the servers does not automatically decide who tracks SaaS spend, who catches a redundant tool before its renewal date, or who notices that three departments are separately paying for competing project management software. Without a layer of visibility into the SaaS stack that exists independently of the support arrangement, both models can erode margin quietly while looking entirely fine from the outside.
A Better Framework Than Cost Alone
CEOs and CFOs weighing this decision are better served by four questions than by a cost comparison alone.
How fast does the business actually need to move. If the investment thesis depends on multiple add-ons in close succession, the decision should favor whichever model, internal or outsourced, has a proven record integrating acquired environments rather than simply maintaining a static one.
What does the compliance and security bar genuinely require. Companies operating in regulated industries or handling sensitive data need a model that can produce auditable evidence of controls, not just a log of resolved tickets. Ask any prospective MSP to show a sample of the documentation they would produce for an insurance renewal or a diligence request before signing anything.
Who owns SaaS governance, separate from who owns support. This is the question boards rarely ask. Whichever party handles day-to-day support, someone needs clear ownership of the full application stack: spend, licenses, usage, shadow IT, and renewal timing. That function, whether it sits with a fractional IT leader, a finance owner, or a dedicated platform, should be able to survive a change in the support model without disruption.
What will this look like to a buyer in three years. Regardless of the model chosen, the company should be able to produce a clean, documented picture of its IT environment on short notice. That is the real test of whether the decision was sound, and it has very little to do with whether the name on the support contract is internal or external.
Where to Start
If you are a CEO or CFO of a portfolio company and you are not certain which model applies, the fastest way to find out is not to relitigate the outsource-versus-in-house debate. It is to ask one question at the next leadership meeting: who in this company can tell me, today, exactly what SaaS applications we pay for, what they cost, and when each contract renews.
If there is a clear answer, the support model is very likely a manageable operating decision either way. If there is not a clear answer, that is the gap to close first, before spending more time debating who answers the help desk.
Outsource versus in-house is a legitimate operating choice, and reasonable leadership teams land on different answers depending on scale, sector, and growth strategy. The mistake is treating that choice as the whole decision. The one that actually protects value is whether leadership has clear, continuous visibility into what the company is running, what it is paying for, and what it is exposed to, independent of who holds the support contract.
Get that part right, and outsource versus in-house becomes what it should have been from the start: an operational detail rather than a bet the entire portfolio company is riding on.
