When off-the-shelf CRMs stop fitting, build one that does.

When Off-the-Shelf CRMs Stop Working

SaaS CRMs are brilliant tools. HubSpot, Salesforce, Pipedrive: they work well for thousands of businesses. The issue is not the software itself. The issue is what happens when your processes diverge from the assumptions the software was built around. At that point, the tool starts fighting you rather than helping you.

These are the patterns we see repeatedly in businesses that have hit the wall with their existing CRM:

None of these are failures of discipline. They are symptoms of a process mismatch. The CRM was designed for a generic sales process; your business has a specific one. The gap between the two widens as you grow.

The question is not whether your CRM is bad software. It is whether the total cost (licence fees, add-ons, workaround time, data re-entry, lost visibility) has crossed the point where a purpose-built system would cost less and do more. That is when custom software makes sense.

The Middle Ground: Before You Build from Scratch

Custom does not always mean starting from a blank screen. There is a spectrum between staying on your current SaaS CRM and commissioning a ground-up build. Knowing where you sit on that spectrum saves money and time.

Option 1: Extend what you have. If the CRM itself is mostly right but the integrations are the pain point, an API integration layer can bridge the gaps. Connect the CRM to your quoting tool, your accounting package, your project system. Eliminate the manual re-entry without replacing the CRM. This works when the core data model (contacts, companies, deals) still fits your world. Read more about connecting existing systems through APIs.

Option 2: Adopt and customise an open-source CRM. Platforms like SuiteCRM, EspoCRM, and Krayin CRM give you a working CRM out of the box with the ability to modify the source code. You own the installation, host it yourself, and can extend it. The trade-off: customisation beyond the platform's intended extension points gets expensive, upgrades become harder, and you inherit the platform's architectural opinions whether they suit you or not. For businesses that need 80% of a standard CRM with 20% custom, this is a viable middle path.

Option 3: Build from scratch. When your processes are genuinely different from what any off-the-shelf or open-source platform assumes, a ground-up build gives you software that models your business rather than forcing your business into someone else's model. This is what the rest of this page covers.

The honest answer is that most businesses should try Options 1 or 2 first, unless it is already clear that the fundamental data model (not just the integrations) does not fit. If you have spent more than six months adapting a CRM and the workarounds keep multiplying, you are probably past the middle-ground stage.

What a Custom CRM Actually Contains

Most "custom CRM" pages produce a feature checklist: contact management, deal tracking, reporting. That tells you nothing useful. Every CRM has those features. The difference with a custom build is that each module models your actual process rather than a generic one.

Here is what a CRM for a typical 20 to 50 person UK business actually does, framed around the business outcomes rather than the feature names:

The specific modules depend entirely on how your business operates. A recruitment firm's CRM looks nothing like a manufacturing company's. A professional services firm needs time tracking and project links; a distributor needs stock levels and order history. This is precisely why process mapping comes first.

Process Mapping: The Step Most People Skip

Most CRM projects that go wrong do so before a single line of code is written. They fail because nobody mapped the existing process first. The business described what they wanted in broad terms ("we need a CRM"), the developer built to those broad terms, and then reality arrived: the exceptions, the workarounds, the tribal knowledge that lives in people's heads but was never documented.

Process mapping is the exercise of making the implicit explicit. It produces documented workflows, decision trees, exception paths, and business rules. It captures the stuff that your team does instinctively but has never written down.

The process mapping phase for a mid-size CRM project typically takes two to four weeks. It involves structured sessions with the people who actually do the work (not just the people who manage them), observation of current workflows, and documentation of every decision point, handoff, and exception.

Here is what the exercise produces:

This is the single most important step in a CRM project. Skip it, and you are building software based on assumptions. Do it properly, and the build itself becomes considerably simpler because everyone (developers, business owners, end users) agrees on what the system should do before construction begins.

The Build Process: Discovery to Go-Live

A custom CRM for a 20 to 50 person business typically takes three to six months from first conversation to go-live. The timeline depends on scope: a focused CRM replacing a single SaaS tool sits at the shorter end; a CRM integrated with accounting, project management, and document generation sits at the longer end.

Here are the phases:

Discovery establishes scope, goals, and constraints. It typically takes one to two weeks and produces a project brief that both sides sign off on. This is where cost and timeline are estimated.

Process mapping (covered in the previous section) runs for two to four weeks. It produces the workflow documentation and business rules that drive the build.

Data modelling translates those business rules into a database schema: the tables, relationships, and constraints that underpin the system. This is the structural foundation. Getting it right means the system can evolve without costly rework. Read more about designing the database schema.

Iterative build runs in two-week cycles, delivering working software at each iteration. You see and use the system as it develops, providing feedback that shapes subsequent cycles. This is not a six-month disappearing act followed by a reveal. You are involved throughout.

Data migration is the phase people worry about most, and rightly so. Your existing CRM contains years of customer history, deal records, notes, and documents. The migration process extracts this data, cleans it (fixing duplicates, filling gaps, standardising formats), maps it to the new schema, and loads it. Every migration is tested against a copy of the live data before touching the real thing. Nothing is lost.

Parallel running is the safety net. For two to four weeks, both the old system and the new system run side by side. The team uses the new CRM for daily work while the old one remains available as a reference. This catches edge cases that testing missed and gives the team confidence before the old system is retired.

Go-live is the switch. By this point, the team has been using the new system for weeks. It is not a cliff edge; it is the removal of the safety net after everyone has confirmed they do not need it.

The technology stack is Laravel (PHP framework) and PostgreSQL (database). Both are open-source, well-documented, and supported by large developer communities. We cover modelling approval chains and business rules in code in detail elsewhere.

Data Ownership and GDPR

With a SaaS CRM, your data lives on someone else's servers, governed by their terms of service, in a jurisdiction they choose. You are the data controller; they are the data processor. If they change their terms, raise their prices, or shut down, your data moves on their timeline, not yours. With a custom CRM, you own the data outright. It sits on servers you choose, in a location you choose, under your direct control. That is the practical meaning of the case for owning your critical business data.

For UK businesses, GDPR compliance is not optional, and a CRM is where most personal data lives. A custom CRM can be built with compliance baked into the architecture rather than bolted on as an afterthought.

SaaS CRMs offer GDPR features, but they are generic. A custom build lets you model consent, retention periods, and erasure rules around your specific data categories and processing activities. The compliance is precise rather than approximate.

What It Costs

A custom CRM for a UK business with 10 to 100 employees typically costs between £15,000 and £60,000 for the initial build. The range is wide because scope varies enormously. A focused contact-and-pipeline system with email integration sits at the lower end. A CRM with workflow automation, document generation, multi-system integrations, and complex role-based access sits at the upper end.

Here is what drives the number up or down:

• Number of integrations: Each connection to an external system (Xero, Mailchimp, a quoting tool) adds development time.
• Data migration complexity: Clean data in a single system migrates quickly. Messy data spread across three systems with duplicate records takes longer.
• Workflow complexity: Simple linear processes are fast to build. Multi-branch approval chains with exceptions and escalations take more time.
• Number of user roles: More roles with distinct permissions means more access control logic and more testing paths.

Monthly ongoing costs after launch run between £200 and £500, covering hosting, security patches, backups, monitoring, and minor adjustments. This is not a retainer for future development; it is the cost of keeping the system running, secure, and up to date.

The relevant comparison is total cost of ownership over three to five years:

These figures assume a mid-range build (£30,000) and £400/month ongoing. Your numbers will vary. The pattern holds: SaaS costs are linear and rising; custom costs are front-loaded and then flatten. The breakeven point for most mid-range builds falls between 18 and 24 months.

A discovery phase (£2,000 to £5,000) gives you accurate costing before committing to a full build. It produces a scoped specification and a fixed-price quote. Read a detailed breakdown of custom software costs for the full picture.

Risks and How to Mitigate Them

The fear most people have about custom software is straightforward: what happens if the developer disappears? It is a legitimate concern. A bespoke system built by one agency, with no documentation, using a proprietary framework, is a genuine risk. Here is how that risk is eliminated.

• ✓
  You own the code outright The source code is yours from day one. It sits in your repository. There is no licence, no lock-in, no "you can have it when the contract ends" clause.
• ✓
  Laravel is open-source with a vast developer community The framework is not proprietary. There are thousands of Laravel developers in the UK alone. If the relationship ends, any competent Laravel shop can pick up the codebase and continue.
• ✓
  The codebase is documented and follows standard conventions Code is written to Laravel's conventions with inline documentation, a README, and architecture notes. A new developer can orient themselves without an archaeology exercise.
• ✓
  A maintenance contract covers the ongoing essentials Hosting, security patches, backups, monitoring, and minor changes are covered by a monthly retainer. The system does not degrade through neglect.
• ✓
  Handover documentation is part of every project If you ever need to move to a different developer, the handover pack includes architecture diagrams, database schema documentation, deployment procedures, and environment configuration. The bus factor is addressed by design.

IGC has been operating since 2005. That is two decades of continuous operation, which is itself a risk mitigator. But the safeguards above exist precisely so that your system's longevity does not depend on any single relationship. Read more about what ongoing software maintenance actually involves.

The Practical Next Step

The decision to build a custom CRM is not abstract. It comes down to arithmetic. If your current CRM is costing you more in per-seat fees, add-on subscriptions, workaround time, and lost visibility than a purpose-built system would cost, the numbers make the argument for you.

The critical points: process mapping before building is the single most important step. Data migration is manageable with a structured approach and parallel running as a safety net. The code is yours, built on open-source technology, and any Laravel developer can maintain it. Costs are predictable: £15,000 to £60,000 for the build, £200 to £500 per month ongoing.