Walk into the average MSP solutions practice and you’ll find a graveyard of good intentions.
A custom onboarding portal for one client. A bespoke billing reconciliation integration for another. A one-off provisioning workflow that someone clever built two years ago, for a logo that churned eighteen months ago, that three current clients now quietly depend on. Each one shipped to win or save an account. Each one made sense the day it was built.
And every single one of them is still on the books — not as an asset, but as a liability you re-pay every year.
This post isn’t about margins on paper or the AI execution gap. Those get their own treatment. This is about the operational reality of delivery: what actually happens when an MSP builds custom software for every client, one snowflake at a time, and then has to keep all of it alive.
Bespoke code doesn’t scale. It accretes.
Here’s the thing nobody tells you when you spin up a solutions practice. Custom builds don’t add up. They pile up.
Scaling implies leverage — you do the work once and it gets cheaper per unit after that. Accretion is the opposite. Every new client app is net-new effort, net-new surface area, net-new something-that-can-break at 2 a.m. You’re not building a product line. You’re operating a museum, and admission is free for everyone but you.
The cruel part is that the build cost — the part you actually quote and invoice — is the cheap part. It’s the one number everyone fixates on, and it’s the smallest one.
The day you ship a bespoke app is the day you start paying rent on it. Forever.
The maintenance tax compounds across the portfolio
A widely cited industry rule of thumb puts annual software maintenance at roughly 15 to 20 percent of the original build cost. Patches, dependency upgrades, the vendor that changed an API, the integration that broke when the client moved from one M365 tenant to another, the security review, the “small tweak” that’s never small.
Take that seriously for a second. Every bespoke app you ship adds a recurring line item that runs 15 to 20 percent of build cost, every year, for as long as that app lives. One app, fine. You can absorb it. But you don’t have one app.
You have a portfolio. And maintenance is the tax that compounds across it.
Picture a modest practice: 40 clients, and for each one you’ve built or wired up an average of 5 things — a portal here, a couple of integrations there, a custom workflow or two. That’s 200 living artifacts. Two hundred snowflakes, each demanding its slice of that annual maintenance tax, each competing for the same senior engineers you’d rather have selling new work.
Now do the multiplication that really hurts. Integrations don’t grow with your client count. They grow with your client count times your tech stack. Every system in the stack, times every client, times every client you’re forecasting next year. Add one new RMM to your standard kit and you haven’t added one integration — you’ve added one per client, plus one for every client you sign. The matrix expands in two directions at once, and bespoke code makes you rebuild a cell of it every single time.
This is why solutions practices that look profitable in year one quietly bleed by year three. The new-build revenue is visible and exciting. The maintenance drag is invisible and relentless. By the time it shows up in utilization reports, your best people are spending their weeks keeping the museum lit instead of building the next thing.
The build is slow, too — and slow stacks on top of expensive
Snowflakes aren’t just expensive to keep. They’re slow to make. Every bespoke engagement starts closer to zero than it should: new data model, new auth, new UI, new integration plumbing, new test cycle. You’re re-solving problems you’ve already solved, because last time you solved them for a different client in a way you can’t cleanly reuse.
So the practice is slow to deliver new work and buried in maintaining old work. The two problems feed each other. The slower you build, the more behind you fall; the more you maintain, the less capacity you have to build. That’s not a growth engine. That’s a treadmill set to incline.
The instinct is to hire your way out. More engineers, more capacity. But you can’t out-hire accretion — every new head you add eventually gets pulled into the maintenance gravity well, because the portfolio keeps growing faster than the team.
The fix is a standard framework, not more heroics
The way out isn’t working harder on snowflakes. It’s refusing to make snowflakes in the first place.
You need a standard framework: configuration-driven, multi-tenant, connector-based. Build the capability once, then clone and adapt it per client instead of starting from scratch. That single shift changes the entire economics of the practice — and it’s exactly what Kinetic is built to do.
- Multi-tenant by default. Separate portals, workflows, and branding per client, all from one deployment. You’re not running 40 codebases. You’re running one platform with 40 tenants. The maintenance surface is centralized, not multiplied.
- Configuration-driven delivery. Clone a working solution and adapt it to the next client’s needs by configuration, not by re-coding. Onboarding measures in days, not weeks, and industry studies put config-driven work at roughly 2 to 3 times faster than traditional development.
- 100+ pre-built connectors. PSA, RMM, AD, M365, and any REST API. You don’t rebuild the integration to the same RMM for the 41st client. You configure the connector you already have.
- IL5-certified, federal-grade governance and audit trails. Compliance and audit are handled at the platform level, once, instead of bolted onto every snowflake individually.
And crucially, this sits as an orchestration and experience layer on top of the tools your clients already run. No rip-and-replace. You’re standardizing how you deliver and maintain, not asking anyone to throw out their stack.
The maintenance math inverts. Instead of N snowflakes each carrying their own 15-to-20-percent tax, you maintain one framework and propagate fixes everywhere at once. Patch the platform, every tenant benefits. Upgrade the connector, every client gets it. The tax stops compounding across the portfolio because there’s no longer a portfolio of one-offs to tax.
This is the same posture already working for MSPs like Dataprise and Advanced — turning what used to be slow, per-client custom projects into repeatable, high-margin, sticky managed-service solutions they can actually scale.
Build once. Reuse everywhere.
The custom-app backlog feels like proof your practice is thriving. It’s actually the bill coming due. Every snowflake you ship is slower to build than it should be and more expensive to keep than you admit, and the costs compound in two dimensions you don’t control.
A standard, configuration-driven, multi-tenant framework is what makes a solutions practice profitable at scale instead of merely busy. Build with AI. Execute with Kinetic. Build the thing once, and reuse it across your whole book.
Want to see what that does to your numbers? The calculator’s default profile shows roughly 60% less build effort when you move from bespoke to a standard framework. Run yours: model your MSP practice transformation, read the strategic case in The MSP Race to the Bottom Is Over, or see the bigger picture on the Kinetic MSP solution.
Share this article