The average $1–3M home service contractor is paying somewhere between $200 and $1,000 a month for a CRM. ServiceTitan is closer to $245–$398 per technician per month according to recent pricing analysis, with $5K–$50K of implementation on top. Buildertrend runs $299 to $900+ per month. GoHighLevel is $97–$497 with another $20–$150 in usage fees. Jobber and Housecall Pro have lower entry points but climb fast once a team needs real seats and add-ons.

What almost nobody pauses to ask is what they're actually buying.

Structurally, every contractor CRM is three things stacked on top of each other: a database, a UI, and a set of opinions about how the business should work. Only one of those three is genuinely differentiated. The other two are now cheap.

I've been spending the last few months replacing the parts that should be cheap for a contractor we publicly work with, Black River Design and Build Inc, the Wisconsin remodeler whose pipeline grew 150% YoY after we put a Repeatable Revenue Engine in place. We did not kill their CRM. We didn't even try to. What we did is harder to explain and more interesting to operate.

This post is the honest version. What we moved off the CRM. What we left on it. What the new stack costs. Where it works. Where it fails. And who this is and isn't for.

What you're actually paying a CRM for

Take any contractor CRM apart and the three layers are obvious once you see them.

The database. Customers, jobs, invoices, leads, calendar events, communications history. Rows and columns. This is the only piece every CRM unambiguously needs to have, and it's also the cheapest piece to build in 2026. Supabase Pro gives you a production-grade Postgres database, including compute, for $25/month. That same database tier supports 8 GB of storage and 100,000 monthly active users. For a contractor doing $3M in revenue with a few thousand customers and tens of thousands of communications a year, you would never get close to those limits.

The UI. The screens, forms, pipeline views, dispatch boards, mobile apps, and reporting dashboards the team interacts with every day. Some of this UI is genuinely good and would be expensive to rebuild. Some of it is mediocre, and used to be expensive to rebuild, and is now buildable in days with Claude Code plus a thin frontend framework.

The opinions. The actual product differentiation. The workflow ServiceTitan thinks a service business should run. The pipeline GoHighLevel thinks a remodeler should manage leads through. The dispatch model Housecall Pro thinks should govern same-day calls. This is what you're really paying for, whether you realize it or not. And this is the part that almost nobody should try to build from scratch. The opinions of a mature contractor CRM are 10 to 15 years of compounded learning about how this kind of business actually works.

The reason CRMs cost what they cost is that they bundle these three layers together. Until recently, that bundling made sense. The database alone was hard to operate, the UI alone was expensive to build, and the opinions on their own had no surface to express through. Today, the database is a $25/month commodity, the UI is a Claude Code project, and the opinions are the only piece that justifies a real subscription.

The implication for an owner-operator is that the right play, more often than not, isn't to keep paying for the full bundle. It's to keep paying for the opinions, build the UI and database layer yourself for the workflows the CRM does poorly, and stop paying for the workflows that should never have been bundled in the first place.

That's what we did at Black River.

The decision and the math

Black River was already running on GoHighLevel as their operational source of record. The pipeline lived there. The campaigns lived there. The SMS and phone layer lived there. The opinions, in other words, that we actively wanted: the pipeline philosophy, the communication automations, the calendar logic.

What did not live well in GHL: cross-system reporting, custom dashboards, ad-hoc analytical questions, and any workflow that required pulling structured data from outside GHL (accounting, ad platforms, estimating). The native reports were either limited or required a higher-tier add-on. The chat interface didn't exist. The semantic layer (a single agreed definition of "customer acquisition cost" or "gross margin per job type") wasn't a thing GHL was ever built to provide.

The math was straightforward. To unlock the reporting and the cross-system view inside GHL, we would need to upgrade to higher tiers and add several monthly add-ons, paying somewhere on the order of $300 to $500 more per month, with limited customization and no ability to ask questions outside the workflows the platform already supported.

The alternative was to leave GHL alone for the workflows where its opinions earned their keep, and to spin up a thin custom layer underneath it for everything else.

The thin layer ended up looking like this. Supabase Pro at $25/month for the warehouse. Vercel for serverless compute and a Next.js dashboard, roughly $20/month at this scale. Claude API for the chat interface and the AI-assisted ingestion connectors, running between $20 and $60/month depending on usage given Claude Sonnet 4.6 pricing of $3 per million input tokens and $15 per million output tokens. A handful of cheap supporting tools (Resend for email, Cloudflare for the edge layer, Sentry for error monitoring), maybe $10–$20 total.

All in: about $75 to $130 per month for a layer that does work the CRM was either charging meaningfully more for or wasn't capable of doing at all.

That's not a 50% savings. That's a structural unbundling.

What we actually moved off the CRM

A few specific workflows that now live in the thin layer instead of GHL.

Unified customer and job view. Every Black River customer's full history, joined across GHL (CRM activity), QuickBooks (invoices, payments, profitability), Buildxact (estimates), and ad platforms (touchpoint history), in a single queryable view. GHL by itself couldn't see most of this. The new view is the table the operator actually wants when answering a customer question or quoting a return job.

Cross-source revenue and margin reporting. Closed revenue by lead source, gross margin by job type, customer lifetime value by acquisition channel, all calculated against a single semantic definition stored in a YAML file. This used to be the kind of report that required a $30K analytics package or a quarterly hand-built spreadsheet. Now it's a dashboard view that refreshes nightly.

Ad-hoc question answering. The owner can ask the system, in plain English, "what's my close rate on Google Ads leads from Q1 versus Q4 last year?" The chat interface reads the same semantic layer the dashboard does, so the answers don't drift from the reports. This is the workflow that produces the most actual operating decisions and the one CRMs do most poorly.

Custom workflow automations. Workflows that required a higher GHL tier or a separate Zapier-style tool. Things like: when a deal closes above a certain value, trigger a specific multi-step follow-up sequence that pulls in profit-margin data from the warehouse and chooses a customer-segment-specific message. These are workflows that benefit from being in code, not in a no-code builder, because the conditional logic gets long and the data dependencies cross systems.

A second-opinion lead scoring model. Each inbound lead gets scored against historical conversion data on the same lead source, job type, and ad spend pattern. The score sits next to GHL's native lead routing so the sales team can prioritize. GHL was never going to build this for one customer's specific business. We did it in a weekend.

None of this killed GHL. Every one of these workflows still references GHL as a source. We just stopped paying GHL to do work it does worse than a thin custom layer can do at one-fifth the marginal cost.

What we left on the CRM, and why

This is the part of the post that breaks the lazy "kill your CRM" narrative.

We left the pipeline UI on GHL. The sales team uses it daily, the visual logic is good, and replacing it would have been an own-goal: weeks of UI work for a marginal improvement, on a workflow GHL already does well.

We left the email and SMS sending engine on GHL. Building a reliable transactional and bulk-email infrastructure that handles deliverability, bounces, unsubscribes, compliance, and the regulatory edge cases is not a weekend project. The CRM is competent at this. We pay for it and move on.

We left the calendar and dispatch UI on GHL. Mobile-friendly, technicians know it, no reason to rebuild it.

We left the campaign builder on GHL. The opinions baked into it (lead nurture sequences, abandoned-quote follow-ups, review-request flows) are the kind of compounded learning we explicitly want to rent rather than build.

The pattern is consistent. We kept the layers where the CRM's opinions and out-of-the-box workflow earn their cost. We replaced the layers where the CRM is just a generic database with a markup, or where it was charging extra for capabilities a custom layer delivers for nearly nothing.

What the build actually took

A specific number people always ask me for and almost no build-in-public post is willing to give.

Roughly three weeks of focused work, spread over about six calendar weeks of part-time effort, to get the warehouse, the ingestion connectors, the semantic layer, and the first version of the dashboard live. Another two weeks for the chat interface and the lead-scoring model. Ongoing maintenance has been a few hours a week, mostly tweaking metric definitions as the operator asks new questions.

That timeline is only achievable because of two things specifically. One, I'm working with Claude Code at every step of the build, which collapses the work that used to be tedious (writing connectors, fixing schema mismatches, scaffolding tests, writing the dashboard glue) into a fraction of the time. Two, I already know the business cold, because we built the Repeatable Revenue Engine on top of GHL for them last year. If either of those weren't true, the timeline would be different.

For an operator coming to this build cold, with a less mature AI workflow and without deep prior knowledge of the business, double the timeline at minimum. Maybe triple. The savings versus the traditional build are still significant, but they're not "weekend project" significant.

The honest tradeoffs

If you read this and the only thing you take away is "everyone should replace their CRM with code," you should not replace your CRM with code.

Here is the unsparing version of where this approach fails.

No out-of-the-box workflow. Every workflow that lives in the thin layer is a workflow somebody designed, built, tested, and now maintains. The CRM gives you that for free once you pay the subscription. The custom layer gives it to you only if the operator commits to running it.

No vendor support. When something breaks in the custom layer, there is no support team to call. The operator is the support team. For a contractor whose owner is in the truck 50 hours a week, this is a real constraint.

Security is now your problem. AI-generated code produces misconfigurations at 75% higher rates and security vulnerabilities at 2.74x the rate of human-written code according to recent research. Public buckets, missing row-level security, leaked API keys: these are the failure modes of the new stack, and every build needs explicit governance constraints to keep them out.

The mobile experience is not free. GHL's mobile app for technicians exists because GHL built it. Your custom layer's mobile experience exists only if you build it. For a service business with field teams, this is a real consideration.

Identity resolution is the unglamorous tax. A customer in GHL is not the same row as a customer in QuickBooks is not the same row as a lead in your ad platforms. Reconciling these is the part of the build that takes the longest and that no AI agent will get right on the first pass. The operator who supervises the agent has to know the business well enough to spot the wrong join.

You need an operator who can supervise an AI agent. This is the part that almost everyone underestimates. The work that's now cheap is the typing. The work that's still expensive is the judgment: schema design, identity resolution, governance, what to measure, what to ignore, when the agent is wrong. The right operator is someone who has lived in the business problem and can supervise the agent at that layer, not someone hoping the agent will figure out the business for them.

If you don't have that operator, the custom layer fails. Not because the technology fails, but because nobody is steering it.

Who this is and isn't for

This approach is for contractors who already have a working CRM that they understand, who feel the constraints of that CRM in specific reporting and cross-system workflows, and who have either an operator inside the business or a partner outside it who can supervise the build.

It is not for contractors who do not have a CRM yet. Buy one. Use it for a year. Find out where its opinions match yours and where they don't. Then, and only then, think about replacing or augmenting parts of it.

It is also not for contractors whose pain is in the parts the CRM is genuinely good at (pipeline UI, dispatch, mobile, email, SMS, opinions about workflow). If you are unhappy with your CRM in those areas, you probably need a different CRM, not a custom layer underneath the one you have.

The contractors this works for, in my experience, share a profile. They are running $1.5M+ in revenue. They have outgrown the reporting capabilities of their entry-level CRM. They have a real desire to know things about their business they can't currently know. And they have access to someone (themselves, an internal hire, or a partner) who can keep the layer running.

The strategic implication

The unbundling of CRM into database, UI, and opinions is happening regardless of whether any individual contractor notices. The CRMs themselves are already responding. Most major contractor CRM vendors have spent the last twelve months adding AI features, building integration marketplaces, and quietly repositioning toward higher-tier plans that compete more on opinions and less on database-plus-UI. The bundle that worked for fifteen years is being pulled apart by economics the vendors can't reverse.

For a contractor reading this, the strategic question isn't "should I dump my CRM." It's "which parts of my CRM stack are still earning their cost, and which parts am I paying a premium for because they used to be expensive to build?" The honest answer is usually that the opinions are still worth what you pay. The rest is renting a database with a markup.

The contractors who notice this first won't have a permanent advantage. But they'll spend the next three to five years operating on a stack that costs less, tells them more, and gives them faster answers to the questions that actually drive their P&L.

That's worth paying attention to.

This is the second post in a series on the new economics of SMB data and software, following The Data Moat Just Collapsed. If you want to talk through what a partial CRM replacement would look like for your business, start with a Revenue Audit at massivelyuseful.ai.