Should an MSP Build Its Own Software Instead of Paying for It

The Cancellation That Took Three Billing Cycles

Josh Peterson put a member of his team on the job of reducing an oversized PSA license count. Sandboxes, retired RMM seats, overage that had accumulated across years. Her first task was not cancelling anything. It was finding the original contract and the invoices, which were not housed anywhere she could reach, and then working out which licenses renewed annually and which renewed on a three year term. That reconstruction took hours before a single cancellation could be requested. Josh is careful to say that part might be on them. The part that is not on them is what happened next, which is that the correctly timed written requests went unanswered until well after the renewal dates had passed, and the next invoice arrived higher because the annual increase had been applied to seats that should no longer have existed.

What makes this worth writing about is not the inconvenience. It is that the cost of the dispute lands entirely on the customer, and the vendor's resolution mechanism is a credit rather than a refund. A credit converts a billing error into future revenue. The customer who was overcharged roughly seven thousand dollars can only recover it by continuing to buy, which means the vendor's worst case in a billing dispute is that it retains the money and the account. Whether anyone designed that outcome is beside the point for an owner trying to run a business. The structure produces it either way, and structures that produce a result reliably do not need anyone's intent to keep producing it.

• If reconstructing your own contract terms takes hours of internal labor, you do not have a vendor relationship, you have an exposure. Document renewal dates and terms where your team can reach them without asking the vendor.
• A credit is not a refund. Treat any resolution that can only be redeemed through future spend as a partial recovery and price the difference into what the relationship is worth.
• Cancellation requests should be sent with the same evidentiary discipline as a client dispute: dated, in writing, to a named party, with confirmation of receipt treated as a required response rather than a courtesy.

Bundling Is What Built the Annual Price Increase

Gary Boyle refuses the villain reading and offers a mechanism instead. Before the managed services era, software was bought the way minutes on a cell phone were bought. You purchased a thing, you used it, and using more of it cost more. Then the industry bundled. A flat monthly fee replaced the meter, and the fee was set low enough to make adoption easy. Gary's point is that the low entry price was not generosity, it was customer acquisition, and it created a specific downstream problem: a large share of customers signed up at fifty or a hundred dollars a month and then barely used the product, because at that price nobody audits their usage.

A business built on that base has a revenue problem that only becomes visible later. Growth was supposed to come from expansion within the customer base, but expansion does not happen when the product is cheap enough to ignore. So around year five, with investors expecting a curve, the only lever left is price on the installed base. That is the origin of the annual increase, and it is also the origin of the longer contract term, because a company raising prices on customers who are not deriving proportional value needs to make leaving expensive. The lock-in and the uplift are not two separate vendor behaviors. They are the same decision, and both were set in motion by the bundling choice years earlier. MSPs should recognize the pattern, because it is the same one that produces a client paying full freight for a month in which the MSP did nothing.

• A flat fee low enough to be ignored produces a customer base that cannot be grown into. Price increases on the installed base are the predictable consequence, not an aberration.
• Contract length and price escalation travel together. When a vendor extends terms, read it as a signal about their expansion revenue rather than about their confidence in the product.
• The same structure sits inside most managed services agreements. If a client called and said you had done nothing for them for a month, the discomfort in your answer is the measure of your own misalignment.

The Input Costs Nobody in the Argument Controls

Gary tests Josh's theory against a company Josh admires. Arizona Iced Tea has held its price at ninety nine cents for decades while its founder became extremely wealthy, which Josh offers as proof that a company can simply choose to stop raising prices. Gary accepts the example and then points out what it actually demonstrates. Unless that business found an untapped input it pays nothing for, its cost multiple today is nowhere near what it was at the start. Holding price while costs rise does not mean the owner discovered restraint. It means the owner accepted a smaller margin. That is a legitimate choice, and it is available to any vendor, but it should be described accurately: the request being made of software vendors is that they voluntarily make less money.

The largest input in a software business is labor, and labor cost is driven by cost of living rather than by any decision the vendor or the customer makes. Gary remembers earning twenty dollars an hour as a level one technician and feeling well paid; today a two bedroom near him runs four thousand a month. That pressure is not a vendor policy and no MSP can negotiate it away. This is the part of the analysis that changes what an owner should do, because it separates the portion of the price increase that is a legitimate pass through from the portion that is margin protection for shareholders. Only one of those is worth spending negotiating capital on, and an owner who treats the whole increase as bad faith will lose the argument about the half that is real.

• Separate the inflation pass through from the margin expansion before you negotiate. Arguing against the entire increase forfeits credibility on the part of it that is genuinely contestable.
• Asking a vendor to hold price is asking a vendor to accept a lower margin. It is a reasonable request, but frame it as the commercial trade it is rather than as a fairness claim.
• The same input pressure sits under your own rate card. An MSP that has not raised prices in three years has made the Arizona Iced Tea choice without deciding to.

Should an MSP Build Its Own Software Instead of Paying for It?

Gary has spent roughly two hundred hours since June building an internal application for Bering McKinley with AI assisted development. He is direct about what that felt like, which was mostly waiting and checking rather than writing code, and direct about what it means: priced at his own hourly rate, two hundred hours is a great deal of money. That is the honest starting point for the arithmetic, and the arithmetic is where this decision should be made.

Run it. A large MSP paying forty thousand dollars a month for its tooling stack has an annual budget of nearly half a million dollars to attack, and at that scale building becomes a serious option with real payback. But most MSPs are not that company. Most are paying two or three thousand a month, call it thirty six thousand a year, and that is the entire pool of savings available. A level two technician at eighty thousand dollars represents roughly half a year of salaried time against that pool, and half a year of one mid level engineer does not produce a system that replaces a PSA, an RMM, and the integrations hanging off them. The conclusion is uncomfortable and worth stating plainly: for the typical MSP, building your own stack to escape your stack bill does not pay. It is cheaper to build than it has ever been, which is a real change, and it is still more expensive than the thing you are trying to avoid.

• The threshold question is not whether you can build it. It is whether your current tool spend is large enough to fund the build. Below roughly forty thousand a year, it is not.
• Development cost has fallen sharply and has not fallen to zero. Two hundred hours of a partner's time is a capital expenditure whether or not it appears on an invoice.
• The comparison most owners run is against the full feature set of the incumbent, which is the wrong benchmark, because almost nobody uses the full feature set. Price the build against what you actually use.

One MSP Building Its Own Tool Sends No Signal

The most strategically useful moment in the conversation is Gary declining to recommend the thing he has just spent two hundred hours doing. Building a purpose built tool for yourself is not a response to vendor behavior, because to a company of that size you are one account and your departure is invisible. A single MSP writing its own ticketing system changes that MSP's cost basis and changes nothing else. The satisfaction is real and the leverage is zero.

What would carry weight is aggregation. Fifty or a hundred or two hundred MSPs moving together to a shared, good enough, dramatically cheaper system is a market event, and it is the only version of this that reaches a boardroom. That reframes the opportunity away from the solo build and toward the peer group, which is where an owner with development curiosity should actually be spending energy: finding the others already building, proving a concept jointly, and deciding together whether it goes to market. It also explains why the incumbents are not asleep. An established vendor facing a competitor at a fifth of the price confronts the innovator's dilemma directly, and the honest read is that they can match the technology far more easily than they can match the cost basis, because their cost basis is people. That is the pressure worth watching, and it is not created by any single customer leaving.

• Individual defection is invisible to a vendor at scale. Collective movement is the only customer action that changes vendor behavior.
• If you have development capability, the higher return use of it is a shared proof of concept with peers rather than a private tool nobody else can adopt.
• Incumbents can copy the technology quickly. What they cannot quickly copy is a lean cost structure, which is where a genuine challenger's advantage lives and where it will be attacked first.

Frequently Asked Questions

Should an MSP build its own software instead of paying for it?

Only when the tool spend being replaced is large enough to fund the build. An MSP paying forty thousand dollars a month for tooling has close to half a million a year of savings to work against and can make a serious case. An MSP paying two or three thousand a month has around thirty six thousand a year available, which is roughly half the salary of one mid level engineer and not enough to produce a system that replaces a PSA, an RMM, and their integrations.

Has AI actually made it cheaper to build internal software?

Yes, materially, and not to zero. Gary Boyle built a working internal application for Bering McKinley in about two hundred hours of AI assisted development starting in June. That is dramatically less than the same system would have cost three years ago, and it is still two hundred hours of a partner's time, which is real money whether or not it shows up as an invoice.

Why do PSA and RMM prices increase every year?

Two forces stack. The first is genuine input cost inflation, mostly labor, which no vendor or customer controls. The second is structural: bundled low entry pricing created a customer base that was too cheap to grow into, so once expansion revenue stalled the only remaining lever was price on the installed base. Longer contract terms follow from the same decision, because raising prices on under engaged customers requires making departure expensive.

What is the difference between a credit and a refund in a vendor billing dispute?

A refund returns your money. A credit returns it only if you keep spending with the vendor, which converts a billing error into future revenue and leaves the vendor whole. When a dispute over incorrectly billed licenses resolves in a credit, the customer has recovered less than the headline number suggests, and that gap belongs in any assessment of what the vendor relationship is actually worth.

Is a consumption pricing model better aligned with clients than a flat fee?

It is better aligned on one specific axis. A flat fee creates an incentive for the provider to do as little as possible, and hourly billing creates an incentive for the client's environment to stay broken. A base fee covering the tooling required to monitor and secure an environment, plus payment for support time actually consumed, removes the incentive to minimize service without rewarding dysfunction. It also carries real costs in revenue predictability and in valuation, since buyers of MSPs price recurring revenue highly.

Would switching to a cheaper PSA solve the underlying problem?

Not by itself, and not for one company acting alone. A single MSP changing vendors is invisible at the scale these companies operate. The change that would alter vendor behavior is aggregate movement, fifty to two hundred providers adopting a shared and substantially cheaper alternative, which is a market signal rather than a churn event. That is why the more productive question for an owner is what their peer group is doing, not what their own migration would cost.

Episode Highlights

• 00:00 - Josh opens in an unusually foul mood and names the reason, which frames the episode as an owner working through a live problem rather than teaching a settled lesson.
• 00:29 - Years of hearing the same vendor billing complaint from other owners, and what changes when you become the one living it.
• 02:15 - Reconstructing your own contract terms before you can cancel anything, and why that step is itself the warning sign.
• 06:20 - Gary tests whether this is a deliberate playbook or a large organization whose processes have gone cold, and lands on the second.
• 12:36 - The argument that vendors sold the industry the managed services model and then built their own contracts to work against it.
• 18:16 - Which pricing model is genuinely misaligned with the client, and why the case against hourly was never as strong as it sounded.
• 22:35 - How bundling low monthly fees produced an installed base too cheap to grow into, and therefore produced the annual increase.
• 28:13 - Input costs, labor inflation, and the Arizona Iced Tea test: holding price is not restraint, it is accepting a smaller margin.
• 41:50 - Build it to save your own money, not to enter the market. The second version is a different business with different demands.
• 44:37 - The actual arithmetic on building your own tooling, and the tool spend threshold below which it does not pay.

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 financial and structural decisions that determine whether an MSP grows deliberately or by accident.

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

• How to get a real return on the PSA investment you are already making
• Why time entry is the whole MSP story, and how to inspect at the rate you expect

Want to Continue the Conversation?

Deciding whether to keep paying for a tool, renegotiate it, or replace it is a capital allocation question, and it should be answered with the same rigor as any other one. That is the discipline the Vision Operating System is built to make routine. If you are building something in this space, we would rather hear about it than speculate about it.