Most MSPs already own the tools that should fix their worst operational gap. The trouble is that those tools do not talk to each other, and the usual answer is to buy a third one.
Sometimes that is the right call. Often it adds another login, another renewal and another place for the truth to drift. This is how we tell the difference, and why the answer has shifted in the last couple of years.
The gap is usually between systems, not inside one
Your PSA knows contracts, tickets and time. Your RMM knows endpoints. Your accounting package knows what was actually invoiced. Each one is good at its own job. The breaks happen where data has to cross from one to another.
The agent count in the RMM does not match the seats on the contract. A signed order has to be retyped into an onboarding project. A quarterly business review takes someone a day because the numbers live in four places. None of these is a crisis. Each one is small enough that it never justified an integration project.
So each one got a person instead. A spreadsheet, a recurring task, a tech who just remembers to check. Twenty of those is a noticeable slice of your margin and the reason nobody can take a proper holiday.
When off-the-shelf is the right answer
Buy when the problem is common and your way of handling it is not what makes you different. Backup, remote monitoring, documentation, the PSA itself, most of the security stack: these are mature markets. A vendor will maintain the integrations, ship the patches and carry the compliance burden.
The honest test is whether you are willing to change your process to fit the tool. If you are, buy it, adopt its way of working, and move on. If you find yourself writing a list of workarounds before the contract is signed, that is the tool telling you it was built for someone else.
- The process is standard across MSPs and you have no reason to do it differently.
- The vendor already integrates with the PSA and RMM you use, and covers the rules you actually bill by.
When a small custom build wins
Build when the gap sits between two tools you are not going to replace, and the rule that closes it is specific to you. How you count a billable endpoint. What a priority one means for a particular client. Which contract lines should trigger which onboarding tasks. A generic product either does not know your rule or makes you configure around it forever.
The clearest signal is the alternative. If the only other option is a person whose job is chasing the gap, you are choosing between a build that takes days and a salary that lasts indefinitely.
- The gap is between systems you will keep, not a missing feature in one of them.
- The logic is yours, and it changes when your contracts or service tiers change.
- Doing nothing means someone checks it by hand, every week, for good.
Four questions before you buy or build anything
We put every request through the same short test.
- Which number does it move, and whose name is on it? If you cannot name the metric and the owner, neither a tool nor a build will help. You have a vague wish, not a gap.
- Does your process bend to the tool, or the tool to your process? If you will bend, buy. If the process is the thing that makes your service good, protect it and build the glue around it.
- What does doing nothing cost for a year? Count it in hours of chasing and the errors that slip through, not in licence fees.
- Can you delete it? Whatever you add should be narrow enough to remove the day it stops earning. Nothing should accumulate by default.
Why the arithmetic changed
Custom software used to mean a business case, a developer and a quarter of calendar time. For a gap worth a few hours a week, that never made sense, so the workaround won every time.
AI-assisted building has changed that. A narrow build that reads from your PSA and RMM, applies your rule and posts the result where your team already works can now go from idea to production in days. That makes it rational to fix the small things, and to throw the fix away if it does not pay its way.
It also makes it easy to build too much. Cheap software is still software someone has to own. So the constraints matter more, not less: the build lives inside the tools people already use, no role exists just to feed it, it shows how it reached each result, and you hold the source when we leave.
A worked example: contract reconciliation
Take the gap between endpoints under management and endpoints on the invoice. Many PSA and RMM pairings offer some form of sync. If it handles your billing rules, use it. That is the off-the-shelf answer, and it is a good one.
If you bill servers and workstations differently, bundle per user, or carry client-specific exceptions, the sync will either miss them or need a person to tidy up after it. That is when a small nightly comparison earns its place: read both systems, apply your rules, and post the difference to a channel with an owner tagged. It finds unbilled devices and billing for devices that no longer exist in the same pass.
The short version
Buy the commodity. Build the glue that is specific to you. And before you do either, write down what the gap costs, which number closing it should move, and who answers for that number.
That last step is most of what we do. See what we build, or book a diagnostic and we will tell you which of your gaps are worth closing at all.