K7 Insights

Build vs Buy Software: Should Your MSP Vibe Code a PSA?

By Kyle Christensen · September 29, 2026

Part of Grow Your MSP

Build your own software only when you’re ready to be its vendor. Answer five questions first: can you name what your current tool can’t do, have you asked the vendor for a fix, have you budgeted for upkeep, do you have a plan for when it breaks, and can somebody besides you repair it? Five yeses, go build it. Any no, close that gap first. AI coding tools have made building faster. They haven’t changed who gets the phone call when it stops working, so make this call as part of growing your MSP.

Why are MSPs thinking about vibe coding their own PSA?

Because now they actually can. I saw a Facebook post from an MSP who’d built their own PSA, the system that runs their tickets, time and billing. I get it. Spend enough years fighting your software and you start thinking, I could build this the way I want it. Today you can open an AI tool, describe what you want in plain language, and watch it write the code. People call that vibe coding. It’s pretty cool.

But I had a question for them. Do you want to own a PSA?

Picture Monday morning. Your team logs in and can’t see their tickets. You’re due in a customer meeting in 20 minutes. Who gets that phone call?

You do. You’re the vendor now.

Maybe the person who wrote that post has all of this handled. I don’t know their business. I do know the conversation I’d have if one of my customers said, “Hey Kyle, I built us a CRM this weekend. We’re moving the sales team into it Monday.” I’d have some questions before we did that. We ought to ask ourselves the same ones.

At Sierra Pacific Group, we worked through more than 1,500 PSA implementations, so I’ve sat in a lot of these conversations. And I build things with AI myself. Some of them save me real time. Here’s the test I’d put anything through before the business runs on it.

What is the “You’re the Vendor Now” test?

It’s five yes-or-no questions you answer before you build software your business depends on. Five yeses means you’ve done the work to decide whether you want the job. Any no means there’s work to do first, and usually some of that work can happen with the tools you already have.

1. Can you name one thing you need that your current software can’t do?
2. Have you asked your vendor whether there’s already a way to do it?
3. Have you set aside time and money to maintain what you build?
4. Do you have a backup plan if it stops working tomorrow?
5. Is there someone besides you who can fix it?

I put the five questions on a one-page worksheet with a YES/NO box for each and room to write your answers down. Fill it in before anybody writes a line of code. It’s a readiness check. Five yeses won’t guarantee the project works, and it’s no substitute for testing.

Can you name one thing your current software can’t do?

Start by naming a specific task the software prevents, in one sentence. “Our PSA is terrible” doesn’t give you anything to work with. “We need the software to do this, because it would let us do that” does.

My time at SPG taught me to ask how the team was actually using the tool. Had we set it up for the work they needed to do? Had we taught them to use it that way? I want to know we gave the thing a fair shot before deciding it can’t do the job.

Say your invoices go out late every month and you want them out on the first. Walk me through why they’re late. Are time entries missing? Is somebody sitting on approvals? Or does the software actually stop you from billing on time? If everybody waits until Friday to enter their time, deal with that before you build them another place to enter it late.

This is where I’d use Theory of Constraints. Find the step that’s holding up the result, get everything you can out of it with what you already have, and organize the rest of the work around it before you spend money expanding or replacing anything. Goldratt Research Labs has a short introduction to Theory of Constraints if you want the full version. Your problem might be one step in billing, and you might be able to fix that step without taking on everything else a PSA does.

Have you asked your vendor whether there’s already a way to do it?

Ask for real. Show the vendor the problem, have someone walk you through the answer, and bring in a person who knows that PSA if you need one. If there’s a way, you’ve saved yourself a project. If the answer is no, or it’s so clunky you still want to build, fair enough. Now you know.

Then give your team time to learn it. Have somebody take a real ticket through the process with them, show them where the time goes and how it ends up on the invoice, and have them do the next one on their own. Sending a login and a link to the training library doesn’t tell you whether anyone can do their job in the tool.

I got asked about switching PSAs during a live ConnectWise PSA AMA in February 2025. Switching means training your people again. There’s an onboarding fee, and there’s a stretch where you’re paying for both platforms. So how much faster does the work have to get before you’ve paid for all of that? And the question I asked on that call still stands: if people aren’t doing their paperwork now, what’s going to make them do it in a new PSA with one less button click?

Sometimes the tool really is in the way. Fine. Show me where. But if you haven’t made a real effort to set it up and teach people to use it, you’ve got work to do before you start over. Vibe coding your replacement still leaves you that work. You still have to move the data over, reconnect your other tools and retrain the team, and now you’re also responsible for fixing the software. If you’re weighing an AI product instead of building one, the same discipline applies in how to evaluate AI tools before your MSP buys.

Have you set aside time and money to maintain what you build?

Put a number on your own time before you compare anything to the subscription. The hours you spend keeping your version alive are a real cost, even though nobody sends you an invoice for them.

Here’s a made-up example. These aren’t anyone’s real numbers:

That’s $1,000 of your time against a $500 bill. You haven’t written yourself a check, so it isn’t extra cash out the door. You’ve still spent 10 hours. What were those hours supposed to be for? A customer, a proposal you never followed up on, a Saturday?

And that example doesn’t count hosting or the time it took to build the thing in the first place. Maybe your version earns or saves enough elsewhere to make it a good deal. Great. Count that too, with your own numbers.

One data point worth knowing: in the Stack Overflow 2025 Developer Survey, 66% of developers answering the AI-frustrations question picked “AI solutions that are almost right, but not quite,” and 45% picked “debugging AI-generated code is more time-consuming.” That question had 31,476 responses and allowed more than one answer. Those are professional developers describing their own experience, not MSP owners, and it doesn’t predict that your app will fail. It does give you a reason to put fixing things in the budget.

Then think about what a software company quietly handles for you:

• Something connects to your app, that connection changes, and your numbers stop coming through. Who figures that out?
• You add a feature and it breaks something that worked yesterday. Who checks that before the team starts using it?
• Somebody leaves the company. Who makes sure they can’t still get into your app and see customer information?

That’s part of what the subscription pays for: years of fixes, people who know the product, and somebody to call. You can absolutely decide the price is too high. Just count the work you’re volunteering to take over.

If you’re staring at your own version of that math and can’t tell whether it works, bring it to a call. We’ll go through what you’d be taking on and whether there’s a smaller fix inside the tool you already pay for.

Do you have a backup plan if it stops working tomorrow?

A real backup plan says what each person does while the system is down and how long it takes to bring it back. “We’ve got a backup” isn’t a plan until you’ve restored from it and timed it.

Go back to that Monday. The PSA won’t load and a customer calls. Where does the dispatcher put the ticket? Can the technician find the information they need? If it takes you all day to fix, what does everybody else do all day? Have you actually restored from the backup? Can you get to the information you need while the application is down?

You already have this conversation with customers. Bring that same standard into your own business.

The same goes when a client is the one building. Say the owner of a small company builds a CRM and shows you the demo. It looks great, and they saved the monthly fee. Then their salesperson needs the customer history to follow up on a quote, and the thing goes down. What did they agree to do when that happens? What did you, as their MSP, agree to support? I put it this way on one of our leadership calls this summer: you’re building something and then selling a warranty on it, and you don’t know the cost of that warranty.

That applies whether the builder is you or your client. Decide what happens when it needs fixing before anyone depends on it. If a client asks you to build it for them, write those support terms down the way you would in scoping an AI project for an MSP client.

Is there someone besides you who can fix it?

Give me a name: someone who has access, has looked at it, and knows where the information lives and how to bring it back. They can be on your payroll or someone you pay by the hour. Either way, they need to know they’re that person.

“I’ll find a developer if I need one” is a rough plan when you’re already down. And if your answer is “I’ll just ask the AI to fix it,” okay. Can the other person do that successfully while you’re unavailable?

Let them try before you need them to. Give them a test copy, have them make a change and put it back, and watch where they get stuck. If every question still ends with “we need to call you,” you’re still the person the business is waiting on. You wanted to get rid of a bottleneck. Don’t become the next one.

When does building your own software make sense?

Building makes sense when you already do the work, you know exactly what result you need, and you can put a number on the time it takes. Start small, next to the systems you have, before you think about replacing one.

Here’s a build I’d say yes to. This August, I walked a teammate through an automation I’d built for our month-end financial reporting. At the time, I estimated it was saving me about 12 hours a month. It pulls information out of the systems we already use. I didn’t have to replace our accounting system to get that benefit. And I still review what it gives me, because those numbers go into decisions about the business.

So there may be a very good thing for you to build: a report, a way to move information between two tools, or one screen that makes somebody’s day easier. Start there. You’ll find out whether it improves the work, and you’ll learn what it takes to keep it running. My AI for MSPs article covers where that kind of behind-the-scenes automation tends to pay off first.

If you really do need a whole new PSA and you’ve answered the five questions, you can make that call with your eyes open.

What’s the verdict?

Five yeses? Go build it. You’ve done the work to decide whether you want the job. Test it before you move everybody in.

Any no? Close that gap first. There’s probably work you can do with what you already have while you figure it out.

I get why somebody would be proud of building their own PSA. I’d be proud of it too. I just want to know who’s looking after it six months from now. Take the test on the thing you’re itching to build, write your answers down, and be straight with yourself about the no’s. You build it, you own it. Put that decision inside your MSP growth plan where it belongs.

Take the test before you build

One page with all five questions, a YES/NO box for each, and space to write down the one thing your software can't do, what your vendor told you, and the name of the person who fixes it when you're out. Fill it in before anybody writes a line of code.

First name Last name (optional) Email address Email me the test

Watch the conversation

Should Your MSP Vibe Code Its Own Software?