The build-vs-buy debate is as old as enterprise software itself. But when MSPs apply that familiar framework to AI, they often walk into the analysis with faulty assumptions. The logic sounds reasonable on the surface: you have engineers on staff, you understand your clients’ data, and you want control. Why pay a vendor when you could build something custom?
The answer comes down to three specific costs that internal advocates for building almost always underestimate. Not because they are careless, but because these costs are genuinely non-obvious until you are deep inside an AI infrastructure project and the invoices start arriving. John and Evan have watched this pattern repeat across the MSP space, and the numbers tell a consistent story.
This post breaks down each of those three costs so you can run the analysis honestly before you commit budget, engineering time, or leadership attention to a direction that may not serve you.
The First Cost: Token Economics Are Not What You Expect
If you have experimented with OpenAI, Anthropic, or any of the major model providers, you have probably looked at the per-token pricing and thought it seemed manageable. It is manageable at low volume, during testing, or when a single engineer is querying the API manually. The math changes significantly when you are running production workloads at MSP scale.
Consider what “at scale” actually means for an MSP. You are not running one query at a time. You are potentially processing tickets, summarizing documentation, generating client-facing reports, running anomaly detection across endpoints, and handling natural language interfaces for internal tools, all simultaneously, across dozens or hundreds of client environments. Token consumption compounds quickly.
Context windows are a major driver that teams consistently overlook. Many AI use cases require you to inject substantial context into each prompt: system instructions, relevant history, retrieved documentation, client-specific parameters. A single “simple” query with full context can consume ten to twenty times more tokens than a naive estimate would suggest. When you multiply that by request volume across a full production deployment, the monthly API bill can land two to four times higher than your initial projection.
Building your own AI infrastructure means you own that cost structure with no abstraction layer and no negotiating position. You are a small customer to the model provider, paying retail rates, with no built-in cost optimization logic unless you build that yourself too.
The Second Cost: Maintenance Is a Product, Not a Task
There is a mental model that treats infrastructure as something you build once and then maintain occasionally. That model does not apply to AI infrastructure, and applying it will create serious problems for your team.
AI models are not static. The underlying models you build on top of get updated, deprecated, and replaced. Prompt patterns that work reliably today may perform poorly after a model update. Retrieval-augmented generation systems require continuous attention to embedding quality, chunking strategy, and index freshness. Fine-tuned models need retraining as your data distribution shifts. Security and compliance requirements around data handling evolve constantly, and AI systems handling client data face particular scrutiny.
What this means in practice is that maintaining an AI system you built internally is not a support burden, it is a product ownership burden. You need someone accountable for the system’s performance, someone watching for degradation, someone evaluating whether the architecture choices you made six months ago still make sense given what the ecosystem has done since then.
That person exists in a buy relationship too, but they work for the vendor. In a build relationship, that person is one of your engineers, and their time spent on AI infrastructure maintenance is time not spent on billable work, on client relationships, or on the operational improvements your business actually needs.
The Third Cost: Engineering Hours Have a Real Opportunity Cost
This is the cost that gets the least honest treatment in internal build-vs-buy analyses, because it requires you to quantify something most organizations prefer to keep abstract.
Your engineering hours are not free. Even when you are paying salaries rather than billing clients directly for that time, every hour an engineer spends building and maintaining internal AI infrastructure is an hour not spent somewhere else. The question is whether that somewhere else is more valuable.
For most MSPs, the answer is yes, clearly and significantly. Think about the opportunity cost in concrete terms. A senior engineer spending 30 percent of their time on an internal AI infrastructure project is likely foregoing some combination of the following: billable client work at your standard rate, improvements to your service delivery operations that would reduce cost or improve margin, work on internal tooling that would make your team more efficient, or technical leadership on client-facing initiatives that could expand your accounts.
If that engineer bills at $150 per hour and works approximately 2,000 hours annually, 30 percent of their time represents $90,000 in potential billable revenue per year, before you account for overhead, before you account for the compounding value of client relationship development, and before you account for the fact that you will likely need more than one person to build and maintain a serious AI infrastructure. Multiply that across a small team over an 18-month build timeline and you are looking at a real number that should appear prominently in your analysis.
The build path is not just expensive in the ways that show up on infrastructure invoices. It is expensive in the ways that show up on your revenue line.
What “Build” Actually Requires at MSP Scale
It helps to be specific about what you are actually committing to when you choose to build. This is not a criticism of the build path in principle. Some organizations have the scale, the resources, and the specific requirements that make building the right choice. But MSPs evaluating this decision should go in with a clear picture.
A functional internal AI data infrastructure for an MSP typically requires:
-
A data ingestion and normalization layer that can handle heterogeneous client data sources
-
A vector database and retrieval system for knowledge management
-
An orchestration layer to coordinate model calls, context injection, and output handling
-
Security and access control logic to maintain client data isolation
-
Monitoring and observability tooling to detect performance degradation
-
An evaluation framework to measure output quality over time
Each of those components requires initial build time and ongoing maintenance, and each interacts with the others in ways that create compounding complexity. The ecosystem each component sits in is moving fast enough that your architectural choices have a shelf life measured in months, not years.
When the Buy Decision Is Clearly Right
Given those three cost categories, the buy path makes sense for most MSPs in most situations. Not because building is inherently wrong, but because the cost-benefit calculation is genuinely unfavorable for organizations operating at typical MSP scale.
The buy decision is strongest when:
-
Your engineering team is small or primarily focused on client delivery
-
You need AI capabilities operational within months rather than years
-
Your clients operate in regulated industries where data handling compliance is non-negotiable
-
Your competitive advantage comes from service quality and client relationships rather than from proprietary AI infrastructure
Buying also does not mean surrendering control or differentiation. The right AI partner gives you configurable systems you can adapt to your workflows, transparent cost structures you can plan around, and a maintenance burden that stays on their side of the relationship. You get to focus your internal resources on what actually differentiates your business.
The Argument Is Simpler Than It Looks
Three costs, honestly accounted for, usually resolve the build-vs-buy question for MSPs. Token economics at production scale come in higher than initial estimates. Ongoing maintenance is a product ownership commitment, not an occasional task. And internal engineering hours carry an opportunity cost that deserves to appear in the analysis the same way vendor fees do.
The MSPs that are moving fastest with AI right now are not the ones that built the most infrastructure. They are the ones that made a clear-eyed decision about where to focus their resources, and then moved.
