Why $3M+ Service Businesses Build Custom AI (And $1-2M Shouldn't Yet)

The honest version of this answer is the one I give on audit calls: most operators trying to build custom AI shouldn't yet, and most operators staying on SaaS AI should have built custom six months ago. The sizing logic isn't intuitive, but the math is more predictable than people expect once you actually run it.

Here's the framework I use, in the order I work through it on a call: the breakeven math, the complexity threshold, the case for staying on SaaS below $3M, and the case for graduating to custom above it. By the end you should know exactly which side of the line you fall on.

01.The Breakeven Math

The cost delta between SaaS and custom is significant but not gigantic. SaaS voice AI for a service business runs $200-500/mo all-in. Custom (agency-built) runs $3,500-6,500/mo for Growth/Scale tiers. The delta you need to justify is roughly $3,000-6,000/mo, or $36K-72K/year.

What does it take to justify $50K/year of incremental AI spend? At a $480 average ticket, you need to recover roughly 105 incremental booked jobs per year — about 9 a month. That's not a huge number. The question is whether the integration depth of custom actually produces that lift over SaaS.

The data across our 60+ deployments says yes, comfortably, once you cross $3M. The reason is that custom AI handles the 10-30% of calls that SaaS drops or misroutes. At $1M revenue, that 10-30% is a small absolute number of jobs. At $3M+ revenue, it's enough booked work to fund the build several times over.

02.The Complexity Threshold (More Important Than Revenue)

Revenue is a useful proxy but it's not the actual variable. The actual variable is workflow complexity. A $4M shop with a simple single-trade single-location call flow might genuinely be fine on SaaS. A $2M multi-trade outfit with location-aware dispatch and warranty-tier routing probably needs custom even at that revenue.

The honest test: count the branching decisions in your call flow. Every "if X then Y else Z" in your real workflow is a branch. Roofing emergency vs roofing inspection. Commercial vs residential. In-warranty vs out-of-warranty. Membership tier A vs B vs C. Northern territory vs southern. Sales rep A vs B based on lead source.

• Under 4 branches: SaaS handles it. Off-the-shelf scripts are built for this complexity level.
• 4-8 branches: hybrid territory. SaaS for intake, custom for the routing logic underneath.
• Over 8 branches: custom is the only option that doesn't drop calls or misroute. Period.

This is why a multi-trade, multi-location operator at $2M can need custom while a single-trade single-location operator at $4M can stay on SaaS. The revenue is a proxy for complexity, but the underlying decision is about complexity itself.

03.Why $1-2M Shops Shouldn't Build Custom Yet

I push back on $1-2M operators who want to build custom roughly 70% of the time. The reasons are consistent:

• The integration depth doesn't pay back at low call volume. The whole point of custom is the depth that SaaS can't replicate. At 40-60 calls a day, the incremental conversion lift from that depth is measured in 4-6 extra bookings a month. That's $20-30K of recovered annual revenue against $50K of incremental spend. You'd be paying $50K to make $25K, which is a great trade in the opposite direction.
• Your CRM probably isn't ready. Custom AI is only as good as the data layer it sits on top of. At $1-2M, most operators have CRMs that are inconsistent at best, half-populated at worst. Deploying custom AI on a messy CRM amplifies the chaos. Clean the CRM first, then revisit.
• You don't have the ops capacity to manage the relationship. Custom builds need a day-to-day point of contact on your side — someone to review transcripts, flag edge cases, push refinements to the build team. At $1-2M, the owner is usually that person, and the owner is already drowning. SaaS doesn't require this.
• The opportunity cost is real. The $50K/year you'd put into custom is probably better spent on marketing, hiring your first dedicated salesperson, or fixing your gross margin. At $1-2M, the highest-ROI moves are usually not in the AI stack.

The right play at $1-2M is to deploy SaaS aggressively (Goodcall + OpenPhone + Birdeye for ~$300-500/mo) and graduate to custom when you cross $3M. You'll spend less, deploy faster, and free up capital for moves that actually compound at your stage.

04.Why $3M+ Shops Should Build Custom

Past $3M, the math flips hard and fast. The reasons:

• The integration depth pays back. At 100-200+ calls a day, the 10-30% of calls SaaS drops or misroutes becomes 10-30 missed bookings a day. Even at the low end, that's $50K-150K/month of missed bookings — not annual, monthly. A $5K/mo custom build that recovers half of that is the easiest ROI math in the business.
• Your workflow complexity has crossed the SaaS ceiling. At $3M+ you almost certainly have multi-trade, multi-location, warranty-tier, or specialty-dispatch logic that off-the-shelf agents can't handle natively. Every call those agents handle wrong is a margin hit.
• The competitive moat matters. SaaS AI is what your competitors are deploying. Custom is what they can't copy. At $3M+ you're competing for the same homeowners as 3-5 other serious operators in your market — and the AI tuned to your exact business logic is one of the few moats they can't replicate.
• The ops cost savings are real. Running five standalone SaaS tools at this revenue tier means 8-15 hours a week of someone reconciling data between dashboards. A bundled custom build kills that work entirely. The labor savings alone justify the cost delta.

05.The Wegner Roofing Case (Why Multi-Location Forces Custom)

The clearest example I can point to is Wegner Roofing & Solar, a 9-location operator across 5 states. Pre-AI, every branch had its own phone coverage, its own intake script, its own dispatch logic. Call coverage degraded sharply outside the home office's hours. SaaS could have handled any single branch's intake — but it couldn't handle the routing logic of "answer the call as Wegner, identify the caller's zip code, route to the correct branch's dispatch calendar, apply that branch's warranty rules, and notify the right on-call tech."

That's not a configuration problem. That's a code problem. Custom build, deployed across all 9 locations, gives them identical 24/7 coverage with branch-aware routing. SaaS literally cannot do this without 9 separate vendor relationships and a glue layer the operator has to maintain.

The Wegner case is the clearest illustration of the complexity threshold I gave above. Their revenue alone (well past $3M) would have suggested custom. Their workflow complexity (9 branches × multi-state warranty logic) made it mandatory.