11 min read

Should Your MSP Build Its Own Integrations Instead of Paying for Middleware?

Picture of Gary Boyle Gary Boyle : August 6, 2026

From the Trenches
Should Your MSP Build Its Own Integrations Instead of Paying for Middleware?

Josh Peterson has spent roughly twelve thousand dollars over twenty years on a single connector — a piece of middleware whose entire job is moving invoices out of a PSA and into an accounting package. That is not a story about a bad vendor. The vendor built something the channel genuinely needed and got paid for it, which is how the arrangement is supposed to work. It is a story about what an MSP quietly agrees to when it fills the gaps between its core systems with rented software: a permanent line item, a dependency it does not control, and an exit that belongs to somebody else the moment a private-equity buyer shows up. Most owners have never priced that agreement. They price the subscription. The subscription was never the expensive part — the expensive part is that the integration layer holding your operating stack together is assembled from other people's roadmaps, and every one of those roadmaps can be sold. What changed in the last twelve months is not the cost of the subscription. It is the cost of the alternative. When Rob Miller of VIP IT, Inc. rebuilt a website he had paid twenty thousand dollars for four years earlier, it took him an afternoon and about two thousand dollars in tokens. That number is the whole argument. It reframes every integration and plugin decision an MSP has already made, and it puts a question on the table that most owners are not yet asking out loud: which of the things we rent are we renting because they are hard, and which are we renting because they used to be hard? Answering that honestly is the practical shape of future-proofing an MSP — not a technology bet, but a standing discipline about where dependency is worth its price.

The trap is assuming the answer is simply to build. Miller — as AI-forward an operator as exists in this channel, running a five-figure annual token budget across three platforms — is the one who applies the brake, and he applies it precisely where an owner's judgment matters most. Yes, you can build it. Whether you should feel comfortable running it in production is a different question, and it is a question about liability, not capability. That distinction is the entire leadership test in this cycle. The financial leverage is real and it is large: a build that used to be a capital decision is now an afternoon, which means the marginal cost of solving a client's specific operational problem has collapsed toward zero, which in turn means an MSP can finally charge for outcomes instead of for hours spent keeping computers alive. But leverage without execution discipline is just exposure with better margins. The owners who win this cycle will not be the ones who build the most; they will be the ones who can say clearly which workloads are safe to automate, which client data never touches a third-party artifact, and which promising internal build is not going anywhere near a production environment until somebody has actually tested it. Positioning follows from that discipline rather than preceding it. The MSP that can hold both truths at once — the build is cheap now, and the responsibility is not — is the one whose clients start asking what else is possible instead of asking why IT costs so much.

Listen on Your Favorite Platform

Should Your MSP Build Its Own Integrations Instead of Paying for Middleware?

Twelve thousand dollars, one connector, twenty years. That is what Josh has spent to move invoices from a PSA into an accounting package — a function so basic he still asks why it was ever a separate purchase. The honest answer is that for two decades it genuinely was hard, and somebody solved it, and charging for the solution was fair. The question worth asking now is narrower and more uncomfortable: is it still hard? Because the price of that connector was never really the subscription. It was the dependency. When the company that built it sells to a private-equity buyer, the roadmap you have been quietly relying on becomes somebody else's asset, and an MSP that has assembled its operating stack out of a dozen such dependencies has no leverage in any of those conversations. Building is not automatically the answer. But an owner who has never seriously asked the question is not making a decision — they are renewing one, every year, by default.

  • Separate the two costs before deciding anything: the subscription price, and the price of not controlling the roadmap. Only the first one shows up on the P&L.
  • The right test is not "can we build this?" — it is "is this still hard, or does it only look hard because it was expensive when we bought it?"
  • A dependency you have never re-evaluated is a decision your past self made with information that no longer applies.

The Build Cost Collapsed. The Liability Didn't.

Rob Miller paid twenty thousand dollars for a website four years ago. He rebuilt it in an afternoon for about two thousand dollars in tokens — not to save money, but to find out whether he could. The number matters less than what it exposes: the constraint that made buying obviously correct has moved, and it has moved far enough that a great many "obviously buy" decisions are now genuinely open. Then comes the sentence that separates an operator from an enthusiast. Yes, you can build it. Whether you should feel comfortable running it in production is a different question. Miller is not hedging there; he is naming the actual boundary. Capability has become cheap and abundant. Judgment about where that capability is allowed to touch client data, financial records, and PII has not become cheap at all, and it does not come bundled with the model. This is the point at which most MSPs will get the cycle wrong in one of two symmetrical ways — either building nothing because production feels risky, or building everything because building feels free.

  • "Can we build it" and "should we run it" are different questions with different owners. If the same person answers both, the second answer is not a control.
  • Draw the production line explicitly: what a build may touch, what it may never touch, and who tests it before it goes live. Write it down before the first build, not after the first incident.
  • The internal-tool build is the safe place to develop this muscle. Client-facing production is the wrong place to learn it.

The Vendors Most at Risk Die of Security Debt, Not Competition

Miller describes a moment that should worry anyone whose stack depends on small software companies: a frontier model, held back from release, was finding vulnerabilities in old software at a rate nobody had seen — three hundred of them in a product shipped fifteen years ago, built by a traditional development team with no AI in its own process. Set aside the security researchers for a second and look at it as an operator. That company now has three hundred defects, across however many operating systems and browsers it supports, and a remediation capacity built for a world that surfaced defects one at a time. There is no money in security patching. You cannot sell a patch. So the pressure lands entirely on the cost side of a P&L that was never structured to absorb it. The conclusion is not that AI will out-compete these vendors on features. It is that a class of small, long-lived, subscription-converted software businesses is about to be handed a bill it has no revenue model to pay — and MSPs that depend on them will feel the failure as an abrupt end-of-life, not a gradual decline.

  • Vendor risk in your stack is now partly a function of the vendor's own engineering velocity. A slow team with old code is a different risk profile than it was two years ago.
  • Ask your smaller vendors how they are handling AI-assisted vulnerability discovery. The quality of the answer tells you more than any SOC 2 letter.
  • Plan for abrupt end-of-life on at least one stack component. Knowing which one you would replace first is cheap; discovering it under pressure is not.

The Giveaway, Not the Build, Is What Breaks the Subscription

Josh's thesis is sharper than "everyone will build their own tools," and it is worth stating precisely, because the precise version is the one that is actually happening. One capable person builds the thing they were renting for thirty dollars a month. They were never going to sell it. They hand it to a friend, who improves it and hands it back, who mentions it to somebody else. One cancelled subscription becomes ten. Miller confirms the mechanism from inside it — this is exactly what his AI mastermind groups do, and it is the open-source dynamic applied to a category of software that never had to survive open-source pressure before. For an MSP, the strategic read is not "cancel your subscriptions." It is that the pricing power of small, single-function tools is quietly evaporating, and any vendor relationship priced on the assumption that building is hard is now priced on an assumption with an expiry date.

  • Single-function tools with thin moats are the first to reprice. Audit your stack for them before your renewal calendar does it for you.
  • The threat to a vendor is not one customer building an alternative. It is one customer building it and giving it away.
  • This cuts both ways: whatever you build internally is also, eventually, buildable by your clients. Build for judgment and outcomes, not for the artifact.

The Opportunity Isn't Saving $30 a Month. It's a Different Conversation.

Miller puts a number on it that will sound aggressive and isn't: a two-million-dollar shop can reach four million in eighteen months to two years with a genuine AI capability attached. The playbook he describes is unglamorous and entirely operational. Go find the strongest people in the AI build communities and hire one. Pick a good client and run a time study — what tasks eat ten or twenty hours a week and grind people down. Build the fix, charge nothing, then take a share of the labor you gave back, plus a testimonial and a referral. Then apply the lowest common denominator: most of your clients have the same pain, so the thing you built once sells ten more times. What that actually buys is not the project revenue. It is a change in what the client thinks you are for. An MSP that fixes computers is a cost the owner resents. An MSP that gives an owner back twenty hours a week and helps them sell more is a partner, and partners do not get squeezed on price at renewal. That is a positioning shift, and positioning shifts are where the durable margin lives — the same reason working on the business rather than in it keeps producing the results it does.

  • Do not sell AI. Sell hours returned, and price it as a share of the value created. The technology is an implementation detail to the buyer.
  • Build once against the lowest common denominator across your base. A bespoke build for one client is a project; the same build across ten is a practice.
  • The measurable outcome is not revenue from automation work. It is that renewal conversations stop being about the price of IT.

Evolve or Die, Revisited

Josh has been dogmatic about this: evolve and grow, or don't and die slowly. Miller used to agree with him completely, and now doesn't — which is the most useful thing either of them says. His revision is not optimism, it is segmentation. Adoption is not moving at one speed; it is moving industry by industry. His financial-services clients are picking the technology up, deploying it, enabling their staff. Manufacturing is not. Retail is doing business intelligence and calling it done. So an MSP's exposure to this cycle is determined less by the MSP's own posture than by the vertical mix in its client base, which is a strategic input most owners have never used this way. It also means the timeline is not the same for everyone, and an owner who reads the industry-wide urgency and applies it uniformly to a book of manufacturing clients will spend money early for a demand curve that has not arrived. Meanwhile the deflection tactic — answer the client's AI question with a Copilot license and move on — is not a strategy. It is a way of being present for the conversation without being useful in it.

  • Map AI adoption appetite by vertical across your client base. That map, not the industry headlines, sets your timeline.
  • Handing a client a Copilot license is not an answer to "what should we be doing with AI." It is a way to end the conversation.
  • The reflex to outsource this to an AI consultant deserves scrutiny — many are six months ahead of you and charging for what is freely available.

Give Me the API. Keep Your AI Agent.

Miller spent years as an anti-ConnectWise holdout, then converted, and now runs every system off it while still calling the interface clunky. He wanted to chat with his own data. He did not wait for the vendor to build it — he had API access, so he built his own dashboard and moved on. That is the whole argument about where platform vendors should be spending, delivered as a lived example rather than a position. No vendor can serve every use case; that is not a failure of the vendor, it is arithmetic. What a vendor can do is make the data genuinely accessible, which converts a limitation into a non-issue and, not incidentally, is why Miller has no intention of leaving a platform whose interface he does not love. The bolted-on AI agent inside the tool is mostly a signal — it says we are still evolving, and there is real value in saying that. But it is a much weaker retention mechanism than an API that lets a competent customer stop needing the roadmap.

  • Weight API quality heavily in platform selection. It is the difference between being stuck with a vendor's priorities and being indifferent to them.
  • An in-product AI feature is a signal of vendor health, not a substitute for data access. Do not let it drive a platform decision.
  • Data portability is the practical form of vendor leverage. If your data is reachable, a clunky interface is an annoyance rather than a strategic risk.

Frequently Asked Questions

Should an MSP build its own integrations instead of paying for middleware?

Sometimes — but the decision is about production risk, not build cost. AI has collapsed the effort required to build a working connector from a multi-week project to an afternoon, which makes many "obviously buy" decisions genuinely open again. What has not changed is the responsibility for anything touching PII, financial records, or client systems. The practical answer for most MSPs is to build internal-facing tooling first, establish a real review and testing process, and only then consider replacing production middleware.

What is the difference between AI and automation in an MSP context?

Automation is a sequence of steps triggered by an event, following logic you defined in advance. AI makes decisions — either autonomously or against business rules you have layered in — without you having to enumerate every if-then branch first. Most useful MSP work is a blend: AI is used to build and reason about the workflow, while the workflow itself runs as deterministic automation.

What does it actually cost to run AI seriously inside an MSP?

More than a single seat license, and the shape of the spend is unfamiliar. Rob Miller runs several platforms in parallel at a combined five-figure annual cost, and routes work between them by task — cheaper models for building, stronger models for hard reasoning. The budgeting lesson is that consumption is per-use rather than per-seat, so the discipline is model selection and workflow design, not license counting.

What is the main security risk when an MSP starts using AI tools?

Third-party artifacts. A session where a person is simply typing to a model is a relatively contained risk. The exposure appears when documents, PDFs, and transcripts from outside systems enter the workflow — a legitimate-looking file can carry hidden instructions intended to make the model act against the user. The corresponding control is treating any externally sourced artifact as untrusted input rather than assuming the surrounding environment is sealed.

How does an MSP start an AI practice without hiring a large team?

Recruit one strong builder from the AI automation communities where those people already congregate. Run a time study with a client who trusts you and find the tasks consuming ten to twenty hours a week. Build the fix at no charge, then price against a share of the labor returned, and ask for a testimonial and a referral. Because most clients share the same pain points, the work built once can be sold repeatedly across the base.

Is every MSP under the same pressure to adopt AI right now?

No, and treating it as uniform is a costly mistake in both directions. Adoption is running industry by industry — financial services clients are actively deploying and enabling staff, while manufacturing and retail are largely not. An MSP's real timeline is set by the vertical mix of its client base, which makes that mix a strategic input rather than a marketing detail.

Episode Highlights

  • 00:00 — Twelve thousand dollars on one connector over twenty years, and why the subscription was never the real cost.
  • 01:00 — Why the next generation of builders, not the current vendors, sets the ceiling on what middleware can charge.
  • 02:33 — The line that separates capability from responsibility: you can build it, but running it in production is a different decision.
  • 06:31 — What changes when you no longer have to know every if-then branch before you can automate something.
  • 10:11 — Consumption pricing as an operating discipline: routing work to the cheapest model that can do the job.
  • 18:06 — The giveaway effect — why one build shared freely cancels ten subscriptions, not one.
  • 21:38 — Security debt as the real vendor killer, and why nobody can fund three hundred patches.
  • 28:33 — The time-study playbook for standing up an AI practice inside an existing MSP.
  • 32:06 — Evolve-or-die, revised: adoption moves by vertical, so your client mix sets your timeline.
  • 38:41 — Why an open API is worth more to a customer than the AI agent a vendor bolts into the product.

About the Guest: Rob Miller

Rob Miller is the founder of VIP IT, Inc., a Los Angeles–based managed IT services and cybersecurity provider serving clients across financial services and other regulated verticals. Before starting VIP IT, he served as CIO and Director of Operations for LunaTech IT, and held IT director roles at Final Draft and Baseline Studio Systems. He has been a member of the Bering McKinley peer community for several years. Rob is one of the most AI-forward operators in the MSP channel — he participates in multiple AI mastermind groups, runs a multi-platform build practice, and has taken a working position on where AI-assisted development belongs in a production MSP environment and where it does not.

Connect with Rob on LinkedIn →

About the Host: Josh Peterson

Josh Peterson is the CEO of Bering McKinley and host of The BMK Vision Podcast. Since 2004, Josh has worked with hundreds of MSP owners to build operationally sound, profitable businesses through consulting, peer teams, and direct coaching.

Connect with Josh Peterson on LinkedIn →

Related Resources from Bering McKinley

Want to Continue the Conversation?

The build-versus-buy question is really a question about where your business creates value and where it merely absorbs cost — and that is a decision that belongs in your operating plan, not in a renewal email. The Vision Operating System is how Bering McKinley helps MSP owners make those calls deliberately, with the financial and operational clarity to know which dependencies are worth keeping.