9 min read

The MSP Owners Who Got Tired of Waiting and Built Their Own PSA

The MSP Owners Who Got Tired of Waiting and Built Their Own PSA

The most important sentence about the PSA category is not about a feature. It is about a feeling. "I've been here before the ConnectWises and the AutoTasks of the world. I loved the early days. And now, 20, 25 years later, I'm just exhausted by these companies. The fights I fought in 2008 are the fights I have no more energy to fight today." That is Josh's opening line in this episode, and it is the line most MSP owners we work with have said out loud at least once — usually at the end of a quarter when the bill arrives, a true-up lands, or a feature ships that turns out to be the old feature renamed. The deeper problem is not a vendor problem. It is a stewardship problem: when a category stops getting better, the owners inside it have to decide what to do about it. A small group of operators have decided to stop waiting. This is an episode about what happens next. As a companion read, our take on the structural deterrents that erode a PSA investment sits next to this conversation, and a tiered strategy for tool selection is the operator's playbook for what to do with the bolt-ons either way.

What Yaron Baitch and Tom Goembel did instead of waiting is the leadership case study underneath the product story. They named the structural problem in the category — "putting an API on or a new skin on something that is still a disparate database is not unifying anything" — and then committed two years of architectural work to actually solve it. Single data model. AI at the database layer, not bolted on top. Month-to-month pricing. A dual-write bridge so the buyer does not have to bet operations on a single cutover moment. The decisions are interesting on their own. The frame is more interesting: an operator who refuses to keep paying for the incumbent's idea of "good enough" is making a positioning decision, not a procurement decision. The same is true of the operator who chooses to stay. The question this episode forces, regardless of which seat you are in, is whether you have actually named the trade you are making — or whether you have inherited it from a tool that quietly stopped serving the business years ago.


Listen on Your Favorite Platform


What "Unified" Actually Means — and Why Almost Nothing in the PSA Category Qualifies

The word that gets the most abuse in the MSP tooling category is "unified." Every vendor uses it. Almost none of them mean what an operator means when they hear it. Yaron's opening frame is the cleanest definition the industry has put on tape recently: a unified platform shares one data model. Your PSA does not look at the ticket and then ask the RMM for context — they look at the same ticket because there is only one ticket. The same logic extends to contracts, documentation, billing, projects, and the dozens of other modules an MSP business actually runs on. When the founders say the platform is AI-native, they do not mean there is a chat box in the corner. They mean every module sits next to the same data the AI sits next to. The third option in reporting — beyond canned and custom — is the AI as the report writer, and it only works because the database underneath it is whole. That is the load-bearing claim, and it is the part the incumbents cannot easily build into a platform that grew by acquisition. This is also why measuring profitability inside your PSA tends to feel harder than it should — the question is rarely the report; it is the architecture underneath it.

  • A "unified" platform on a disparate database is a UI claim, not an architecture claim. The operator pays the integration tax either way.
  • Reporting is the canary. If the canned report is not what you need and the custom report writer is too complicated to use, the architecture under the platform is the constraint — not the report tool.
  • AI sitting on top of a fragmented data layer cannot give you reliable cross-functional answers. AI sitting on a single data model can.

Familiarity Bias Is the Hardest Moat in the PSA Category

The most honest moment in the conversation is Josh's. He looks at the new platform and admits that if someone had asked him two years ago to reimagine a PSA, he would have just rebuilt what already exists — because that is the only PSA he can picture. The leadership lesson is uncomfortable: the operators who use the tool every day are the worst-positioned to redesign the tool, because the tool has trained them into a set of expectations the tool itself decided are normal. That is what familiarity bias actually is. It is not laziness. It is the cost of a decade of muscle memory the buyer never agreed to pay. Yaron's response is the only one that holds: the founders deliberately refused to anchor on the legacy product. They redesigned the workflow from a blank whiteboard with their CFO — not from a screenshot of the incumbent. The implication for any operator considering a new category bet, not just in PSA, is that the design must come from the operating reality, not the incumbent's interface. The cost of the design starting from the interface is paid forever.

  • The operator using the legacy tool every day is not the best architect for the next tool. The muscle memory is the cost.
  • A platform redesign that begins with screenshots of the incumbent will ship the incumbent's blind spots with it.
  • The hardest moat a new entrant has to clear is not features. It is the buyer's relationship with their own discomfort.

Pricing Is a Positioning Decision — Not a Procurement Decision

The pricing thesis is the part of the conversation that sounds the most like a sales pitch and is actually the part that has the most leadership in it. Josh names the reaction every honest buyer has had: the price is so low it sounds naive. Yaron's answer is the Arizona Iced Tea answer — we can be profitable enough at this price, so we are going to stay here. The reframe is important. The founders did not pick the price to win deals. They picked the price to widen the addressable market and to keep the platform out of the hands of buyers who treat pricing as the proxy for quality. The same operator-as-stewardship question shows up in the contracting model. Month-to-month, unlimited users, unlimited endpoints, and a data-export clause that says "if you leave, your data leaves with you." These are not pricing decisions. They are signals about who the founders think the buyer is, and what trust between the two parties is supposed to look like. The hard truth underneath — and the one most operators will have to wrestle with on either side of a switch — is that the incumbent's pricing model is also a signal about what the incumbent believes about the buyer. The operator just stopped noticing.

  • A pricing decision that is too low to be a "loss leader" and too low to be a "premium signal" is a positioning decision — it names the buyer the founder wants to serve.
  • Long-term contracts and "true-up" mechanics are also signals — they say what the vendor believes about the buyer's likelihood of leaving.
  • The dual-write bridge — running both systems in parallel during cutover — is not a feature. It is a refusal to make the buyer's cutover risk into the vendor's revenue moat.

Marketplace and Partners Is the Go-To-Market Most MSPs Will Actually Hear

The least obvious strategic decision in the build is the go-to-market. The founders' answer is not blast email and SEO. It is credibility through marketplace partners — recognizable security, backup, finance, and consulting names that the buyer already trusts — and an in-person presence at industry events where a live demo answers the "is this real" question in a way a website never can. The leadership lesson is that net-new awareness for a category entrant is borrowed, not bought. The buyer trusts the friend who already trusted the founder; the founder's job is to be worth that trust when it gets extended. The same dynamic applies to the customer-success scale problem the founders are already preparing for. The decision to "bolster customer success now," before the inbound demand actually arrives, is the discipline most growth-stage companies do not have. Most companies wait for the support queue to break and then hire. The signal in this conversation is that the founders are building the support team against an honest forecast of where their inbound will land, not against the comfort of the current load. That is the operating maturity that, in twelve months, will look like the reason the company did not blow up under its own momentum.

  • Net-new awareness for a new category entrant is borrowed from trusted partners, not bought from ad spend.
  • "We will figure out customer success when we need to" is the line that every growth-stage company says before they fail to figure it out.
  • An in-person live demo at an industry event is the highest-trust marketing investment a B2B platform can make. It is also the most expensive — and the most undervalued in pipeline-attribution math.

Frequently Asked Questions

What is IgnitHQ?

IgnitHQ is an MSP operating platform that launched publicly in May 2026. It is built from scratch on a single, unified data model, with 80+ native modules sharing one source of truth and AI native at the database layer. The founding team is composed of MSP operators — Yaron Baitch (Founder & CEO, also CIO of Digital Practice Inc.) and Tom Goembel (Operations) — who decided to build the platform they wished existed instead of continuing to evaluate incumbents that grew by acquisition.

What makes a "single data model" different from existing PSA platforms?

Most existing PSA platforms grew by acquisition: a ticketing tool, a contract tool, an RMM, a billing engine, and a documentation product were each bought from a separate company and bolted together with middleware. The result is a UI that looks unified and a database layer that is not. A single-data-model platform stores every module's data in the same place — which means changes propagate without integration latency, reports run against the same source of truth no matter what view they come from, and AI built on top has reliable context across every module.

Why does AI at the database layer matter more than AI in a chat box?

An AI assistant that lives in a chat box on top of the platform has to ask the platform for context before it can answer. When the underlying database is fragmented, the AI gets fragmented context — which is why most cross-functional questions ("which clients are 90 days past due AND have an open project AND have churn risk signals?") fail in legacy tools. AI native at the database layer means the model can read the whole picture in one query. The question's complexity stops being the constraint; the architecture under it is.

How does the dual-write bridge change a PSA cutover?

The biggest objection to switching PSAs is not pricing or features. It is the cutover risk — what happens if billing breaks on day one, or ticket history does not come over, or the new system goes down during a peak service window. The dual-write bridge keeps both systems running in parallel and synchronized during the transition, which lets an operator pilot a function (the after-hours team, or a single service board, or a specific client) in the new platform while the rest of the business continues on the existing system. The cutover stops being a binary moment and becomes a measured shift.

Why month-to-month pricing instead of multi-year contracts?

Multi-year contracts and "true-up" pricing mechanics are not just pricing structures — they are signals about how the vendor expects the buyer to behave. A month-to-month model says the vendor believes they will earn the renewal every month. The founders' explicit thesis is that long contracts hide product friction; if a tool keeps its customers because they cannot leave, that is a different business than one that keeps its customers because they do not want to leave. The pricing decision is a positioning decision.

Is this an alternative to ConnectWise or AutoTask?

IgnitHQ is positioned as a category alternative, not as a category replacement for any specific incumbent. The founders' frame is that the addressable market for MSP operating platforms is upwards of 50,000 MSPs and is currently served by a handful of incumbents in a slow license-trade equilibrium. A credible alternative with a different architecture and a different pricing model widens the field — it does not just take licenses from one named competitor.

Episode Highlights

  • 00:48 — The founder's clearest definition of what "unified" actually means — and why a new skin on a disparate database does not qualify, no matter what the marketing says.
  • 07:48 — Why two-year-old architectural plans plus rapidly improving AI tooling is the rare combination that produces a working platform instead of a slide deck.
  • 10:08 — Familiarity bias as the hardest moat in the PSA category — and why the operators using the legacy tool every day are the worst architects for the replacement.
  • 13:54 — The "skeptics corner" approach to selling to a tired buyer: answer every objection in public, post the answers on the website, then invite the skeptics to find what is missing.
  • 27:45 — The license-trade equilibrium that defines the current incumbent landscape — and what changes when a new entrant refuses to play that game.
  • 38:29 — The Arizona Iced Tea pricing thesis: profitable enough at the low price, widening the addressable market by refusing to extract maximum margin per customer.
  • 42:25 — Preparing the customer-success team before the scaling problem arrives — the discipline most growth-stage companies talk about and then fail to execute.
  • 49:11 — Why marketplace partners and in-person events out-perform blast email and SEO as the go-to-market for a credible category entrant.

About the Guest: Yaron Baitch

Yaron Baitch is the founder and CEO of IgnitHQ, Inc., a unified MSP operating platform that launched publicly in May 2026 with 80+ native modules sharing a single data model and AI native at the database layer. Yaron has 20+ years of MSP operations experience: he is the CIO of Digital Practice Inc. (DPI), one of the largest dental-focused MSPs in the country with offices in Hawaii and Connecticut, and he previously co-founded AuthAir, Inc., which was acquired by LogMeIn in 2016. He sits in the rare seat of building software for the operators he is one of.

Connect with Yaron on LinkedIn →

About the Guest: Tom Goembel

Tom Goembel leads operations for IgnitHQ and brings front-line MSP execution experience — including transitioning a large MSP team between PSA platforms and integrating acquired companies — to the platform's day-to-day workflow design. Tom's role in the build is the workflow translation layer: how the architectural plan meets the reality of how a service team actually moves a ticket from intake to billing without hating the tool by Wednesday.

Connect with Tom 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

Want to Continue the Conversation?

If this episode named a frustration you have been carrying about your current tooling stack, that is the conversation BMK has every week with MSP owners through the Vision Operating System — naming the structural decisions buried inside operational pain so the right ones get made before the wrong ones get expensive.

#40 – From the Trenches: Starting an MSP & Owning the Risk (Nelson Archila)

5 min read

#40 – From the Trenches: Starting an MSP & Owning the Risk (Nelson Archila)

In this episode of From the Trenches on the BMK Vision Podcast, Josh Peterson sits down with Nelson Archila—an emerging MSP founder in Los...

Read More
#69 – From the Trenches: Owner-Led Sales, Dispatch Discipline & Sustainable MSP Growth (Chad Kempt)

1 min read

#69 – From the Trenches: Owner-Led Sales, Dispatch Discipline & Sustainable MSP Growth (Chad Kempt)

In this From the Trenches episode, Chad Kempt joins Josh Peterson for a practical conversation on what really drives sustainable MSP...

Read More