11 min read

Should Your MSP Sell the App You Built With Claude?

Picture of Gary Boyle Gary Boyle : Published

BMK Vision Roundtable
Josh Peterson and Gary Boyle discussing whether an MSP should sell an app it built with Claude to its clients, on the BMK Vision Podcast roundtable.

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?

Listen on Your Favorite Platform

Everyone Can Build Now. That Was True in 1998, Too.

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.

  • Building has become cheap. Owning what was built has not, and the gap between the two is where MSPs will win or lose.
  • The MSP already holds the access and the trust that made the computer shop a natural seller of websites.
  • Early work in a new medium tends to be thrown away. Plan to level up past your first version rather than defend it.

The Danger Zone: Easy to Build, Hard to Support

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.

  • A build that depends on one person's memory is a liability, for the client and for the MSP that sold it.
  • The questions that matter are the boring ones: can it be replicated, supported, configured, secured and kept compliant?
  • Enthusiasm produces features. A definition of done produces something a client can rely on.

Plan Before You Build, the Way You Should Run the Business

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.

  • AI removes the natural stopping points that used to force a builder to think.
  • A goal and a plan are what turn a tireless builder into a useful one.
  • The discipline that grows an MSP is the same discipline that decides whether its AI work becomes a product or a mess.

Should You Sell an App You Built With Claude to Your Clients?

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.

  • The first sale is easy. The first change request is the real test of whether you sold a product or a demo.
  • Price the support honestly. The monthly fee is the part of the deal that has to be true.
  • Make the risk explicit, so the end user does not mistake a proof of concept for finished software.

The Fork in the Road: Software Company or Copilot Reseller

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.

  • Every MSP has already said yes to technology it had never touched. The question is whether it will do so again.
  • The market is every client running software that fits it only roughly.
  • Choosing not to build is also a decision, and competitors may make it differently.

Frequently Asked Questions

Can an MSP sell an app it built with Claude to a client?

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.

What is the AI danger zone?

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.

What are the levels of AI adoption for a small business?

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.

What does building software in green pastures mean?

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.

Who supports an AI automation after an MSP builds it?

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.

Will MSPs become software development companies?

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.

Episode Highlights

  • 00:00 - Cold open: Josh asks why an MSP cannot build a client a tool like Gary's hub for $40,000 and $1,000 a month.
  • 00:28 - Josh builds a working app in Claude in a day without writing code, and already sees clients who would pay for it.
  • 02:09 - Selling websites in 1998 shows how new tools turn the people at the counter into natural sellers.
  • 06:24 - Building more serious tools raises the question of how much of the underlying technology you have to learn.
  • 07:52 - The AI journey starts with patient zero and level one, where an MSP has little to sell beyond governance.
  • 10:54 - Level two brings automations, agents and daily briefs, and the first real MSP project work.
  • 12:56 - The danger zone: builds that work until the technician who made them is out.
  • 14:52 - Level three begins when other people need access and a real application is required.
  • 18:04 - Overbuilding a first app trades resilience for features you may not want six weeks later.
  • 20:15 - Spending too much time in Claude is necessary, but only useful with a goal and a plan.
  • 22:25 - Building first and backfilling the roadmap mirrors running an MSP without a plan.
  • 24:18 - AI never gets stuck, which means it can dig a long tunnel toward nowhere.
  • 25:53 - AI is both hype and opportunity, and the MSP may be on its way to becoming a software company.
  • 30:41 - The case for selling a custom hub to a power-user client for $40,000 plus $1,000 a month.
  • 32:19 - Green pastures: software with no users behaves very differently from software a client depends on.
  • 34:50 - The first change request is where an MSP that does not understand its own build loses.
  • 35:43 - A client who knowingly accepts the risk changes the conversation, if the messaging is clear.
  • 39:17 - Every MSP has said yes to technology it had never touched and figured it out.
  • 40:33 - The fork in the road: become an AI software development company or keep reselling Copilot.
  • 42:47 - Take inventory, build internally first, then find a client who understands the journey.

About the Co-Host: Gary Boyle

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 →

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?

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.