Josh Peterson was up at 5 a.m. with a client in the UK and worked until eight that night, and at the end of that day he did something he had never done before. He asked Claude to build him a small widget that would show, in real time, how many hours he had spent with clients. Three minutes later it existed. Over the next fifteen or twenty hours he kept adding to it, and by the time he sat down with Gary Boyle to record this episode he had a working app, not one line of code written by hand, and three clients in mind who could use exactly the same thing. His instinct was the one every MSP owner is going to have this year: build it for them, charge five grand, and if they don't like it, no harm done. The economics behind that instinct are real. BMK has already looked at how the math has changed on whether an MSP should build its own software rather than rent it, and at what goes wrong once vibe coding hits production. The harder question is what happens when the software is not for you. Selling an app you built with Claude turns a personal productivity win into a product someone else depends on, and those are two very different businesses.
Gary's answer was not no. It was a map. He sees a journey every business is now on with AI, from the owner who has only heard of it to the one running a real application other people depend on, and a stretch in the middle he calls the danger zone, where building is exciting and easy and almost nothing is supportable. The leadership judgment in this episode is about where an MSP actually stands on that map, and whether it is honest with itself about it. Execution discipline decides whether a build starts with a goal and a plan or just a lot of late nights. Positioning decides whether the client is buying a proof of concept or believes it is buying finished software. The financial leverage cuts both ways: $40,000 to build and $1,000 a month to maintain is attractive revenue, and it turns into a liability the first time the client asks for a change nobody on the team knows how to make. And the long-term strategy is a fork Gary believes every MSP now faces: become a software development company that also delivers managed services, or keep reselling licenses while clients find someone else to build what they actually need. What follows is how BMK thinks about each of those, and about the question underneath all of them: should your MSP sell the app you built with Claude?
In 1998 Gary Boyle was about eighteen, working at a small computer company in Anaheim, California, that paid roughly $2,000 a month for a T1 line while most of its customers were still on dial-up. A colleague ran websites off a server under his desk and was convinced that everyone needed one, so the owner started offering a website to every customer who came in to buy a computer. Gary and his colleagues would have twenty of them going at once, built in FrontPage and sold for $500 to $1,000 each, and he remembers feeling uneasy about charging for something he did not fully understand. Looking back, he calls most of that work best effort. Within a few years the web moved from hand-typed HTML to Flash to sites backed by databases that could take orders, and anyone who had not leveled up was outpaced almost immediately. Gary's point is that AI has recreated that moment on a much larger scale. It has handed the ability to build to everyone, and the MSP sits exactly where that computer shop sat: in front of the customer at the moment the customer is ready to buy. The opportunity is real. So is the lesson of 1998, which is that the first wave of anything new is mostly disposable, and the businesses that last are the ones that get past it.
Gary describes the failure in a single scene. An MSP has built a client an AI workflow that the CEO now relies on. One morning the technician who built it does not show up. Another technician has to support something he did not build, does not understand and cannot find documentation for, while the CEO is trying to walk into a meeting with the presentation the workflow was supposed to produce. The client paid for something that worked once, maybe twice, maybe for a week. That scene sits inside a framework Gary uses for where people are with AI. At the bottom is patient zero, the coffee shop owner who has heard about AI and has no time to experiment with it. Level one uses it as a better search engine and a faster writer, and there is little for an MSP to sell there beyond tool choice, security and governance. Level two is where people start building: interactive artifacts, skills, agents, scheduled tasks, a morning brief compiled from a few websites, a dashboard that pulls QuickBooks and HubSpot together and shows exactly what matters and nothing else. This is where MSP project work begins, and it is also where the danger zone begins, because the work is exciting, it is easy, and a voice conversation with a computer can take you a very long way without your understanding where you went.
Josh recognized himself immediately. His end-of-day automations already felt fragile, dependent on one application dropping a file in a folder and on instructions he had written seven months earlier and was now afraid to look underneath. Gary had put the core question to him off the air: do you want it to work, or do you want it to be cool? Josh compared his first burst of building to the first day of school, when every kid wears all of their favorite new clothes at once, and admitted that six weeks later he might not care about half of what he had added and would still have to maintain all of it. The danger zone is not a failure of the tools. It is the predictable result of building fast with no standard for what finished means.
Gary said it bluntly: if you do not end the day feeling like you spent too much time in Claude, you are probably not going to make it. The value is that large. But the same sentence has a darker version, the one where you end the day having spent too much time in Claude and having no idea what you built. The difference, in Gary's telling, is whether you started with a goal and a plan. Without them you have handed a tireless worker a vague instruction, and it will interpret that instruction however it likes, with no way for you to tell whether it is on the right path. AI also removes the friction that used to force a pause. Anyone who has worked in technology for twenty years remembers being stuck for an hour or a day on a server install. These tools do not get stuck. When they hit a wall they dig a tunnel under it, and you may never know whether the tunnel took twenty hours or led anywhere you meant to go.
Josh connected it to the pattern BMK sees in nearly every owner it works with. An MSP runs from day zero to day thirty thousand without a plan, meets everything as it comes, and lands somewhere decent but stuck: two million dollars in revenue, six percent net profit, and an owner taking home two hundred thousand a year with no clear way to get further. His Claude experiment compressed that whole story into twenty-four hours. He had no stated goal, built quickly, and now had to ask the tool to backfill a roadmap and a plan for what it had already done. The correction is the same in both cases. Decide what you want, plan it, then build it, rather than building first and working out afterward what you built.
Josh made the case as concretely as it can be made. Gary built a hub for the firm that reads from the four tools BMK uses, pulls the information together, and reminds and nags the team about what matters. Josh's clients run the same kind of scattered tools and need the same thing. So why not walk into a power-user client and say that Gary will be there Monday, will work out what they need and build it, for $40,000 and $1,000 a month to maintain, delivered by January 1? Gary's answer was candid. He is not a developer. He understands hosting, APIs, MCP servers and databases well enough to direct the work because Claude understands them deeply, and he does not fully know what he built. A developer friend described his situation as building in green pastures: nobody is using the software yet, no data depends on it, and changing a screen costs nothing. The moment the software belongs to a client, the first change request arrives, and if you do not know what you are doing at that point, you have lost. Josh named the client's side of it: they want certainty, they deserve it, and they will expect the reliability they get from software they buy off the shelf.
Gary called that the biggest sticking point for MSPs adopting this model, and it is not a reason to refuse. Josh pushed back with the right client: one who understands that the first version will be excellent and that later changes will not come with off-the-shelf guarantees, and who accepts that risk explicitly. Gary's answer reframes what is being sold. At level three, an MSP can build an excellent proof of concept that people can genuinely use, and the risk is manageable when everyone, including the end user who will assume it is a finished product, understands what it is. BMK's answer to the question is yes, with conditions. Sell it as a proof of concept, to a client who knows the difference, with the maintenance priced as the real cost it is and a clear agreement on who owns the next change.
Gary reached for a memory most MSP owners share. Somewhere in your history is the first time a client wanted a Cisco 3800 series router you had never touched, and you said yes and figured it out. If someone had checked your work, they would have found plenty to fix. It worked anyway, and you built on it. Gary's concern is that many MSPs have stopped taking that kind of risk. Some no longer install servers at all; they resell Azure at a markup and call it infrastructure, which narrows how much they understand about the technology they support. AI flips that. Building software for a client means taking full ownership of something whose inner workings you may not fully understand, and the real question is how much risk and liability you are willing to carry for the money.
His prediction is that over the next ten years the MSP turns into a software development company that also delivers managed services. Most companies run broad systems built for millions of users that fit them only roughly, and they bend their business to fit the software. AI makes it possible to give them what they actually need instead, sometimes by replacing twenty different tools with one that does the job better at a fraction of the cost, and the developers building that future use the same tools the MSP already has. The decision in front of every owner is whether to become an AI software development company or keep selling Copilot in the cloud. Josh's practical answer for owners who choose to go: take inventory of who is on the team and what you have already built for yourselves, get uncomfortable internally first, find a client who understands exactly who you are and where AI is, take a modest fee, be willing to give it back, and push yourself.
It can, and some clients will gladly pay for it. The risk is not the first build but everything after it: support when the person who built it is unavailable, the changes the client will ask for, model updates underneath the app, and security and compliance obligations. BMK's view is to sell it as a proof of concept, to a client who understands the difference, with maintenance priced and ownership of future changes agreed in advance.
It is Gary Boyle's name for the stage where a business, or the MSP serving it, builds AI automations, agents and dashboards that work well enough to be relied on but are not documented, repeatable or supportable. It is dangerous precisely because the work is exciting and easy, and because a build can work once or for a week before failing on the day the person who built it is not around.
In the framework discussed in this episode, patient zero has heard of AI but does not use it. Level one uses AI for search, writing and documents. Level two builds artifacts, automations, scheduled tasks and dashboards connected to business systems. Level three needs a real application that several people use, which brings hosting, security and change management with it.
It describes developing software that nobody depends on yet. With no users and no production data, changes carry no consequences. That changes completely once the software is delivered to a client, because every later change has to work without breaking something the client relies on.
Someone has to be able to, which means documentation, a repeatable build and more than one person who understands how it works. If only the technician who built it can maintain it, the client is exposed on any day that technician is unavailable, and in the client's eyes the MSP owns that problem.
Gary Boyle expects that over the next ten years many will become software development companies that also deliver managed services, because AI lets them build what clients actually need instead of reselling broad tools. Whether a particular MSP should is a strategic decision about risk, staffing and the kind of company its owner wants to run.
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. On the Vision roundtable he co-hosts with Josh Peterson, working through the decisions that determine how an MSP grows, sells and runs.
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 what kind of company an MSP becomes in the AI era is a planning question before it is a technology question. Building the goals, plans and operating discipline to make that call deliberately is what the Vision Operating System is designed to do.