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.
Matt Franklin
The conversation that's surfaced most often on UK outbound calls in 2026 isn't "we're on Salesforce" or "we're on HubSpot." It's "we built our own." The prospects have an in-house CRM, often four or five years old, sometimes contracted out to a development agency, sometimes built by an internal engineer who is still there and still maintaining it. They're proud of it. They paid for it. And 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. And the cost of dragging it forward, year after year, has quietly become the single biggest tax on the business.
This post isn't a pitch. It's the working we've shown to MDs and Ops Managers in the last quarter, including some at enterprise franchise scale, when they ask 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 UK 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 DNO state, MCS doc handover, and BUS voucher tracking, 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 UK installer in 2026 is running design sign-off through EasyPV or Heatpunk, submitting G98 or G99 to the DNO, preparing the MCS documentation pack, redeeming BUS V5 vouchers on heat pump work, scheduling installs against engineer certifications, ordering materials against an install date, capturing commissioning forms in the field, registering warranties with manufacturers, and running a service 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 at a UK 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 an address.
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 UK installer at 25-50 staff with a bespoke CRM is, in our experience, paying one of three flavours 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 agency on retainer, somewhere between £4,000 and £12,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 tech 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 team 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 licences for the things it integrates with, the time the Ops Manager spends specifying changes, and the time the field team spends working around it. Most of the MDs we've shown this to land somewhere between £80,000 and £180,000 a year. That's the real comparable, not the £0 the system pretends to cost.
UK compliance doesn't behave the way generic CRM data does. It isn't a custom field you tick. It's a sequence of stage gates with regulator deadlines, document evidence, and consequences if you get it wrong.
DNO submissions on G98 and G99. The application has a state. Submitted, under review, conditional offer, accepted, rejected. That state needs to gate whether an install can be scheduled. On an in-house CRM, this typically lives as a dropdown on a deal, an attached PDF, or a reply email from the DNO that's sitting in someone's inbox. There is no project rule that refuses to let the install be booked until the DNO state is clear, because nobody scoped one.
MCS documentation. The pack is design, schematics, commissioning, handover, customer documentation. On a bespoke build, those are usually files attached to a record, with a checkbox for "MCS submitted." On purpose-built software, the documents are tied to the project stage, generated from on-site data, and entered into the MCS Installation Database as a workflow gate, not a manual cross-platform copy.
BUS V5 voucher state. The Boiler Upgrade Scheme V5 ties the voucher to installer, property, technology and redemption window. Voucher state has its own gate. The pre-install evidence pack has to be complete. In-house CRMs don't have this. Most weren't built when BUS V5 came in (28 April 2026), and retrofitting it onto a system that wasn't designed for it is a backlog ticket that keeps getting bumped.
MIS 3005 D and I, F-Gas, MCS 020 (a) sound calculations. Engineer certifications gate which jobs they can complete. F-Gas record-keeping is statutory. MCS 020 (a) sound calculations gate permitted development on the heat pump side. Each of these is a project-level field on a real operational system. Each is a spreadsheet on a bespoke CRM, or a knowledge-of-the-Ops-Manager-only field that breaks if she's on holiday.
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 tech installer's operational world is changing under them. Last year it was Boiler Upgrade Scheme V5. The year before, the DNO ENA HP/EV connection process shifted. This year there are new MCS standards on the horizon and BUS V5 itself is mid-stream. Manufacturers change their warranty registration APIs. EasyPV releases a new design export format. Spruce, Heatpunk and OpenSolar all change cadence.
A purpose-built platform absorbs that change as part of its product cycle. A bespoke CRM absorbs that change as a backlog ticket fighting against every other request from the operational team. The Ops Manager wants the new commissioning workflow. Sales wants a new dashboard. Finance wants Xero or QuickBooks reconciliation tightened. The engineer or the agency picks two of three for next quarter.
Every one of those backlog items is a margin call against the actual business. The MD ends up being the product owner of a CRM, on top of running the installation business. We've watched MDs 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, signed proposal is the start of the project: design integration, DNO submission, MCS pack, materials bill of materials (BOM), scheduled install, commissioning, handover, service plan.
A purpose-built platform is built around the project. One record carries the customer from cold lead through year-three boiler service. 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 realisation 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 tech installs actually work. That's why the backlog never catches up. The backlog is not the problem. The model is.
We see this most clearly in the enterprise customers we work with. A UK clean energy franchise network running across more than twelve branches spent millions on internal CRM and billing platforms. An integration review in late April 2026 surfaced more than eighty distinct risks in the bespoke side, ranging from double keying to deposit invoice handling, finance approvals not modelled, and billing-system migration mid-flight. Those are not features. They are seams in the model where the bespoke build can't represent what the operational team actually does. Even at enterprise scale, with engineering teams and consultancy retainers an order of magnitude bigger than a typical UK installer can field, the bespoke layer was the failing layer. That's why we got the call.
Three patterns show up when an MD has internalised 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 team that's running purpose-built software next door pulls ahead on installs per engineer.
The second is "we'll port it onto a platform but keep our customisations." This works if the platform is genuinely extensible. Payaca's pipeline guards, custom workflows, API and webhook layer are designed for exactly this. The customisations move; the schema stops being yours to maintain. The engineer or agency 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, 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 recognised 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 new 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 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.
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.
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.