Josh Peterson built a small web app for a client in Claude in less than an hour. It held the client's real sales prospects, it calculated, it let people enter data and move things around, and it replaced a spreadsheet nobody wanted to maintain. Then he shared it with a public link, and Gary Boyle told him to stop. That moment is the whole AI question for MSP owners in miniature: the tooling now lets a non-developer build something genuinely useful in an afternoon, and the same tooling makes it trivially easy to publish a client's data to the open internet. Most MSPs have answered by locking AI down. That answer protects the client, but it does not grow them, and it ignores what is now possible with development in the age of AI, when vibe coding hits production. It also ignores how quickly AI is reshaping MSP service delivery and how clients now judge their providers against the metrics every CEO should monitor, which are revenue, leads and cost, not blocked websites.
This is a leadership decision before it is a technical one. Sharing an AI-built app safely is solvable with governance MSPs already run every day in Teams, OneDrive and email. The harder question is positioning: whether your firm stays the provider that says no, or becomes the one that asks how it can make the client's business better and uses AI to deliver the answer. The financial leverage is real. One small MSP rebuilt a client's broken legacy application over a weekend and billed roughly four thousand dollars for a fix the client had wanted for years. The execution discipline is real too, because the same firm has to own what it builds. The MSPs that win the next five years will be the ones that hold both thoughts at once.
Josh asked a client to build out their sales pipeline, and the client sent back a spreadsheet. Instead of filling it in, Josh opened Claude and built a working model of what the pipeline should be: a small web application with real calculations, editable fields and the client's own prospects in it. Most of it came from the first prompt. Roughly seventy one-line tweaks later, it worked. He did not call an IT person or ask a data analyst for anything. What Claude calls an artifact can be a document, a spreadsheet, a presentation or a functioning app, and for an executive who has always wanted calculators and dashboards but skipped them because they took too long, that changes the economics of every internal tool.
The implication for an MSP owner is that your clients' executives are about to build things whether you are involved or not. The demand for small, specific software inside every business was always there. It was suppressed by cost and time. With that suppression gone, the only open question is who guides it, who secures it, and who gets paid for it.
The answer depends almost entirely on how the link is shared. Josh's first instinct was the public share link, the one that lets anyone with the URL open the app. Gary's concern was specific and historical: when shared AI conversations first appeared, people shared them publicly, search engines began indexing those URLs, and information leaked that nobody realized was exposed. A public link holding a client's financials is the same as posting their spreadsheet to the internet. Invite-only sharing is different. The person has to be invited by email and has to authenticate to open it, and the owner can assign them editor, commenter or viewer rights. That is, as Gary put it, the same trust model as right-clicking an Excel file in OneDrive and sharing it to one address. You are trusting the platform's back end, as you already do with Microsoft.
Two practical problems remain even with invite-only sharing. The first is identity friction: during the live recording, Josh shared to an address that was not attached to Gary's account, and Gary could not open the app at all. The second is versioning. Gary shared a multi-page trip agenda as a public page, kept editing it, and his wife kept seeing the old version, because the published link was pinned to an earlier release. Before an MSP builds a client workflow on top of a shared artifact, it has to confirm who can see it, whether they see the current version, and whether the data in it belonged in the tool in the first place.
Gary named why MSPs cringe at all of this. Inside Microsoft 365, an MSP can stop employees sharing documents through Teams to anyone outside the organization with a single policy setting. Email can be scanned for sensitive content on the way out. Claude's share button has none of that around it. An employee can drop a data set into a model and then publish an app built on that data through a link the MSP never sees. The instinct to restrict is not paranoia. It is the same instinct that built every data loss prevention policy you already run.
The useful reframe is that this is not a new discipline. Sharing is sharing, and the rules MSPs wrote for OneDrive, Teams and email transfer directly to AI tools: who is allowed to share outside the organization, with whom, what data classes are allowed into the tool at all, and whether the client has agreed to have their data there. Josh's first step with a client's prospects should have been a conversation, not a prompt. Once the client has said yes and the sharing model is invite-only, the risk looks a lot like every other collaboration platform you already manage.
Gary described a large, very successful, very conservative MSP owner who told BMK flatly that his firm is not doing AI development. If a customer wants it, they will help with governance and guide the journey, but they will not build anything. Josh's view is that this is probably right for that business, which is vertical and serves clients whose demand is predictable. Gary's worry is that it describes most of the industry, and that stopping at restriction is hard to defend as beneficial to any client. He has been on that side himself. When he ran an MSP he wanted everything locked down because he did not want the phone call about a breach.
The trouble is that clients do not feel the value of being locked down. They forget how much the security work protects them, because nothing new happens. They simply stop getting hit with ransomware and assume that is how a business works. What they do feel is friction: blocked sites, slow device approvals, a provider that says no. The MSP that asks how it can generate more leads, more revenue or lower cost for the client, and then uses AI to deliver it, is offering something the client can actually see. In Gary's words, that is the MSP that wins.
The clearest case in the episode is a small, AI-forward MSP owner who noticed he kept getting tickets about a client's old custom scheduler application. He told the client's CEO he could probably rebuild it. The CEO agreed the app was old, possibly insecure and never did what they wanted. Over a weekend, the MSP fed Claude Code the recorded conversation with the client, screenshots and the old code, and asked it to build a replacement. Around five hours of supervised work later, the new app did everything the old one should have done and signed users in with their Active Directory credentials. He is not a developer. He billed it as a project of about twenty hours at two hundred dollars an hour, roughly four thousand dollars, to fix something that had been broken for years.
Josh's caveat is the right one: an MSP doing this should be candid that it is not a software house, and explore the build with the client rather than posing as an expert. Gary's counter is that custom developers were never uniformly good either, and old code written by rotating teams is often insecure and inconsistent. His sharpest argument is about websites. Most MSPs say they do not do websites, so a contractor (call him Johnny) builds one, and when it gets hacked and starts sending spam, the MSP still takes the call. With AI tooling, the MSP can own that website, secure it, integrate it with the client's scheduler, and make it generate leads. Twenty more leads a month is worth more to a client than a web filter, and the two are not mutually exclusive.
Not if it contains client data. A public link lets anyone with the URL open it, and shared AI content has been picked up and indexed by search engines before. Use invite-only sharing for anything containing real business information.
An artifact is something Claude produces alongside a conversation, such as a document, a spreadsheet-style tool, a presentation, a web page or a small working application with calculations and data entry.
The owner invites specific people by email. Each person must sign in with an account tied to that address, and the owner can assign them the role of editor, commenter or viewer.
Yes. In the episode, Gary Boyle separates an MSP's own internal data, where the productivity gain may justify the risk, from client data, where the client has to agree first.
The episode describes a small MSP owner, not a developer, who rebuilt a client's legacy scheduler in Claude Code in about five hours of supervised work and billed it as a roughly $4,000 project. Josh Peterson recommends being explicit with the client that the MSP is exploring the build with them rather than acting as a software house.
Because the MSP already takes the call when a client website is hacked. Gary Boyle argues that AI tools now let an MSP own, secure and improve the site, including turning it into a source of leads for the client.
Gary Boyle is a Partner for Strategy & Business Development at Bering McKinley. With a background spanning network engineering, entrepreneurship, and strategic consulting, Gary brings real-world operator experience to helping MSP owners build stronger, more profitable businesses.
Connect with Gary on LinkedIn →
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 →
Deciding whether your MSP builds with AI or only governs it is a strategy question, and strategy is what the Vision Operating System is built to answer. If you are working through where AI fits in your services, we would like to hear how you are approaching it.