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...
9 min read
Josh Peterson
:
July 13, 2026
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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 →
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 →
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 →
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.
5 min read
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...
1 min read
In this From the Trenches episode, Chad Kempt joins Josh Peterson for a practical conversation on what really drives sustainable MSP...
1 min read