The MSP That Ships Code Is a Different Business Than the MSP That Tickets Code

A lot of MSPs became software shops by accident. It usually starts with a script someone wrote to stop doing the same fix by hand, and a year later the team is bolting an AI feature onto a client's stack. Somewhere along the way "we manage your IT" turned into "we also build your software" — and nobody checked whether the team could actually do that job.

Two different skills are getting priced as one. Resolving a 2am outage and architecting a product feature are not the same discipline, and treating them as interchangeable is where the trouble starts.

Two jobs, one invoice

Support work is bounded: a ticket comes in, there's a runbook, there's a resolution time, and margin holds because no single person is a bottleneck. Building software isn't like that. There's no runbook for a feature that doesn't exist yet. Scope gets renegotiated every time the client sees a working screen and realizes what they actually wanted.

In the deals I see, contracts are still priced like the first thing while the team is increasingly delivering the second. Most of the margin trouble I hear about traces back to that gap between what the contract assumes and what the team is actually doing.

What dev hours do to a support contract

Say a client has 20 hours a month included. The MSP starts using those hours to build a custom integration or an AI feature. On the invoice nothing changes, so it reads as efficiency: the same people getting more done under the contract the client already signed.

In reality, scope creep goes unpriced. A half-built feature delivers nothing until it's finished. Do one custom build "for free" inside the retainer, and every future request gets measured against it. Your best engineers end up doing product work under a pricing model built for tickets, and support margin quietly funds product development. That's how "custom work" becomes the line item bleeding the P&L — while looking, from the outside, like just one more thing the team did for the client.

Fix the skill gap first

Before touching pricing, be honest about capability. Some MSPs have technicians who've genuinely picked up engineering discipline: code review, testing, deliberate architecture. In my experience, many teams haven't built that muscle yet — their people are excellent at support, which is a different job than shipping and maintaining a product.

Two ways to close that gap: hire real engineers and build the practices around them, or partner with a firm that already has that discipline and let them own delivery while you own the client relationship. (Disclosure: this is a market I work in, so weigh that second option accordingly.) What doesn't work is assuming technicians will absorb product engineering by osmosis.

Separate the contract, not just the calendar

Once the skill is real, fix the commercial structure. Any work with real engineering uncertainty — custom software, AI features, product builds — needs its own container:

A separate statement of work. Pricing tied to milestones or to the value the feature delivers, with its own budget that never draws from the support hours. A written definition of "done" that both sides sign off on before anyone opens an editor, which is how software vendors have always run projects. (Contract terms vary by jurisdiction — check with legal counsel before changing anything.)

It also means being clear about who does what. Blur the two roles and you get senior engineers doing ticket triage while technicians ship features they were never set up to own.

The choice

In my experience, MSPs losing money on custom work usually aren't bad at engineering. They built the capability and kept pricing it like a ticket queue.

Software can be a good business for an MSP. It just has to run as its own line, with economics built for engineering work and a P&L that sits beside managed services, where everyone can see whether it's paying off. Whether you hire the engineers or bring in a partner, price the work the way a product team would price it. Do that, and the work that's currently bleeding margin can become the thing that grows the company.