Mid-sized US solar and clean-energy installers spend two engineers a year keeping a bespoke CRM alive that handles maybe 60% of the workflow. Permits, AHJ inspections, NEM interconnection and ITC handling end up on spreadsheets. Here's the real cost of the build, and what the off-ramp usually looks like.
Matt Franklin
The conversation that keeps showing up on US outbound calls in 2026 isn't "we're on Salesforce" or "we're on HubSpot." It's "we built our own." The prospects have a bespoke CRM, often four or five years old, sometimes built by a contracted dev shop, sometimes maintained by an internal engineer who is still on payroll and still patching it. They paid for it. They're proud of it. They don't want to talk about replacing it.
The honest version of what we see when we get past that objection is that the bespoke CRM is doing the job it was scoped for in 2021. The job has changed. The system has not. The cost of dragging it forward, year after year, has quietly become the single biggest tax on the business.
This isn't a pitch. It's the working we've shown to founders and ops leads in the last quarter when they've asked us to be straight about whether their in-house build is actually serving them.
Already running an in-house CRM and feeling the maintenance load?
We've helped US installers retire a bespoke CRM without losing a single project record. Book a 30-minute walkthrough and we'll map your in-house schema to a Payaca workspace, including AHJ permit state, inspection sign-offs, NEM interconnection tracking, and ITC documentation, so you can see the migration shape before you commit.
Almost every in-house CRM we've seen in this market started life as a quoting tool. A founder or a technical hire built something to replace the spreadsheet. It handled customers, deals, and a basic stage pipeline. It did the job for the business that existed at 5-10 staff.
The work has moved on. A 25-person US solar installer in 2026 is running design through OpenSolar or Aurora, pulling utility data, scoping ITC eligibility, building a multi-line proposal that includes panels, inverters, battery and sometimes an EV charger, submitting permits through a city or county AHJ portal, scheduling around inspector availability, completing the install, getting the AHJ inspection sign-off, filing the NEM interconnection paperwork with the utility, capturing the commissioning data, registering warranties with manufacturers, and running an O&M (operations and maintenance) plan on the back end. The bespoke CRM models maybe the first third of that, sometimes a bit further if someone has tacked on a project module.
The rest lives on spreadsheets, in a Drive folder, in someone's inbox, in a separate scheduling tool. We did a workshop with a US installer in early 2026 and counted the systems the office and field teams touched in a single project lifecycle. The in-house CRM was one of seven. The other six were the load-bearing ones; the CRM was the one that held the customer name and a deal value.
If your CRM is "the place we put deals" and your operational team has built a parallel system for everything that happens after a deal is signed, the bespoke CRM is not your operational system. It's a contact database with extra steps.
The line we hear most often, almost word for word, is "we built it ourselves so it costs us nothing." That's never the actual cost.
A US installer at 25-50 staff with a bespoke CRM is, in our experience, paying one of three flavors of bill. Either there's an internal engineer (sometimes co-founder, sometimes hire) whose full-time job is keeping the CRM alive. Or there's an external dev shop on retainer, somewhere between $5,000 and $15,000 a month, doing the same job remotely. Or the work is sliced between a half-time engineer and a part-time agency, which is the most expensive of the three because nobody owns the roadmap.
That is not a sunk cost. That is two full-time engineers of clean-energy business, every year, going into a system that isn't your product and isn't your differentiator. The customer doesn't see it. The installer down the road who's running purpose-built software has those two engineers doing something else, like winning more work or designing more systems.
A useful exercise: ask your finance lead for the all-in cost of the in-house CRM for the last twelve months. Include the developer salary or agency fee, the hosting, the licenses for the things it integrates with, the time the operations lead spends specifying changes, and the time the field team spends working around it. Most of the founders we've shown this to land somewhere between $120,000 and $250,000 a year. That's the real comparable, not the $0 the system pretends to cost.
US installer compliance does not work the way generic CRM data does, and it doesn't work the way a UK MCS pipeline works either. There's no national standard. Every install is governed by an AHJ (authority having jurisdiction) that varies by city, county and utility. The data model has to handle that variance natively, or it doesn't handle it at all.
AHJ permit state. A solar permit application has a state. Submitted, in review, corrections requested, approved, expired, closed. The AHJ may be a city building department, a county PV-specific portal, a state-level permit system in places like NY or CT, or all three for the same job. On a bespoke CRM this typically lives as a dropdown on a deal, an attached PDF, and a reply email from the inspector that's sitting in someone's inbox. There's no project rule that refuses to let the install be booked until the permit state is approved, because nobody scoped one for the seventeen different AHJs you actually work with. Purpose-built software treats permit state as a first-class compliance field on the project, not a tab somewhere else.
Inspection sign-offs. Most jurisdictions require pre-installation, mid-installation and final inspections, with a separate utility inspection on top. Each has its own scheduling window, inspector assignment, pass/fail outcome, correction list, and re-inspection trigger. A bespoke CRM treats this as a checkbox. A real operational system treats it as a workflow stage with its own timeline.
NEM interconnection. The utility's net energy metering interconnection process is a separate paperwork track from the permit. Approval to install, witness test, permission to operate. Every utility has its own portal, forms, and timeline. The interconnection state should gate whether an install is commissioned, because turning a system on without permission to operate is a real problem. On most bespoke CRMs we see, this state is not modelled at all. It lives as a tab in a spreadsheet with one column per utility.
ITC substantiation. The federal Investment Tax Credit is the single biggest economic driver in residential solar. Substantiating it for the homeowner means clean documentation of system specification, install date, installer credentials, equipment serial numbers, and commissioning. That documentation pack should be a project artefact, generated from the project record, not assembled by hand at year end. On bespoke builds, it's almost always a year-end scramble.
State and utility rebates. Most states layer at least one rebate program on top of the federal ITC. Eligibility, application windows, evidence requirements, payout sequencing. Each one is its own track. On purpose-built software they're project fields with their own state. On a bespoke CRM, they're a folder.
The difference is not that one tool has compliance features and the other doesn't. The difference is that compliance is a first-class citizen of the data model in one and a custom-field afterthought in the other. You can't bolt that on without rewriting the schema.
The hardest thing about a bespoke CRM is not what it does today. It's what it has to do next year.
Every clean-energy installer's operational world is changing under them. The IRS guidance on ITC substantiation has shifted twice since 2022. State-level interconnection rules around battery storage and virtual power plants are evolving in California, Texas and the Northeast. AHJ portals get rebuilt and break the integrations. OpenSolar, Aurora and the design-tool ecosystem all change their export formats. Manufacturers swap warranty registration APIs.
A purpose-built platform absorbs that change as part of its product cycle. A bespoke CRM absorbs it as a backlog ticket fighting against every other request from the operational team. The operations lead wants the new commissioning workflow. Sales wants a new dashboard. Finance wants the QuickBooks reconciliation tightened. The engineer or the dev shop picks two of three for next quarter.
Every one of those backlog items is a margin call against the actual business. The founder ends up being the product owner of a CRM, on top of running the installation business. We've watched founders spend half a leadership team meeting working through CRM tickets, because there isn't anyone else to do it. That's not where you want your most senior person.
When we sit with a team running a bespoke CRM, the question that breaks the deadlock is not "what features are we missing?" It is "what is the unit of work that this system is built around?"
Almost every bespoke CRM we've seen treats the deal as the unit of work. Which is exactly the problem we describe in the post about generic CRMs. A deal closes. The system thinks the work is done. In reality, the signed proposal is the start of the project: design integration, permit submission, permit approval, install scheduling against inspector availability, install, AHJ inspection, NEM interconnection, commissioning, customer handover, ITC documentation, monitoring and O&M plan.
A purpose-built platform is built around the project. One record carries the customer from cold lead through year-three monitoring. Office and field see the same project. Finance reconciles against the same project. Compliance gates sit on the project. That continuity is what an installer means when they say "everything in one place." It is not a feature you can add to a bespoke CRM. It is the schema of a different kind of system.
The single most expensive realization for a team running an in-house CRM is that they aren't a feature or two short. They're a model short. Every individual ticket they raise is fighting against an underlying object graph that doesn't match how clean-energy installs actually work in the US. That's why the backlog never catches up. The backlog is not the problem. The model is.
The pattern is sharpest in the businesses that have grown fastest. Once you cross thirty installs a month, the cost of the model gap shows up in metrics: install lead time, percentage of jobs blocked at inspection, NEM interconnection delay, ITC documentation defects at audit. The bespoke CRM doesn't have those reports because the underlying records don't have those fields. Building them means writing custom objects, and at that point you are paying a developer to build a project management tool inside a CRM that was already supposed to be a project management tool. That's the moment most of the operators we talk to start an off-ramp project.
Three patterns show up when a founder has internalized the maintenance cost.
The first is "we'll keep it alive for two more years." This usually correlates with someone on the leadership team having sponsored the original build. The system stays. The spreadsheet layer keeps growing. The cost compounds. The installer down the road that's running purpose-built software pulls ahead on installs per engineer.
The second is "we'll port it onto a platform but keep our customizations." This works if the platform is genuinely extensible. Payaca's pipeline guards, custom workflows, API and webhook layer are designed for exactly this. The customizations move; the schema stops being yours to maintain. The engineer or dev shop is freed up to work on something the customer actually sees.
The third is "we'll cut over and decommission." This is the cleanest exit and the least common, because most teams want a transition period. We've handled both. The migration shape on a 25-50-staff installer is typically four weeks parallel running, with project records ported by stage rather than big-bang.
There is one case where the in-house CRM is the right call, and we'll say it openly. If the CRM is a genuine differentiator, if your product is the platform you've built and you sell access to it (some EPC and franchise networks do, legitimately), the build is justified. We've seen one or two of those. The rest are expensive sunk-cost assets that an installer is paying to maintain instead of paying to grow.
If you've read this and recognized the building you've been doing for the last few years, the move isn't urgent and it isn't an emergency. It is a decision worth making with the same seriousness you'd give to a senior hire or a new line of credit. It's that big a line item, even when it doesn't show up on the P&L as one.
See how Payaca helps clean tech installers save time and grow their business.
Book a demo
Decision-stage migration guide for US clean-energy installers leaving HubSpot. What imports cleanly, what doesn't, what HubSpot stays good at, and how to sequence a 4-week cutover without losing project history or AHJ permit state.
Mid-sized UK installers spend two engineers a year maintaining a bespoke CRM that handles maybe 60% of the workflow. The other 40% is on spreadsheets. Here's what's actually being paid for, and why the build never catches up to MCS, DNO and BUS V5.
Decision-stage migration guide for UK clean-energy installers leaving HubSpot. What imports cleanly, what doesn't, what HubSpot stays good at, and how to sequence a 4-week cutover without losing project history.