Solution
A custom CRM, when the big ones are the wrong shape
Most businesses should buy a CRM off the shelf. This page is about the minority whose process genuinely does not fit one, and how to tell which you are.
Start with the workflow that costs you the most
Tell us what the process is and what it currently runs on. A senior engineer reads it and replies with either questions or a straight answer that we are not the right fit.
What is actually going wrong
Start with the honest position: most businesses should buy a CRM rather than build one. The established products are mature, well supported, and cost a fraction of custom development. If your sales process looks broadly like leads, opportunities, stages and deals, you should be using one of them and this page is not for you.
A minority of businesses genuinely do not fit. Usually because what they track is not a sales pipeline at all: a lettings agency managing properties, tenants, landlords and compliance dates; a recruiter with candidates and vacancies on both sides of a match; a wholesaler where the relationship is really an account with pricing tiers and credit terms. Forcing those into an opportunity pipeline produces a system where half the fields are misused and everyone keeps a private spreadsheet alongside it.
The other case is cost shape. Per-seat pricing works well until you need thirty occasional users, at which point you are paying a substantial annual sum so that people can update a status twice a week. There is a crossover point where owning something focused is cheaper, and it is worth calculating rather than assuming.
This is deliberately not an AI pitch. It is a database with the right shape, the right screens and the right rules, which is what the problem actually is.
You will recognise some of these
- Your CRM has fields renamed to mean something else entirely, and everyone knows the translation
- Half your team keeps a private spreadsheet alongside the CRM because it does not do what they need
- You pay per seat for people who log in twice a week
- What you track is not really a pipeline, but the software insists that it is
- Reporting requires exporting to a spreadsheet because the built-in reports cannot express your question
- Configuring the product further now requires a specialist consultant
- You use a small fraction of what you pay for, and the part you need is missing
Tell us which workflow it is
A short description of the process and what it runs on now is enough to get a straight answer on whether this fits.
How to tell whether you should build
The test is not whether the off-the-shelf product annoys you. All software annoys its users. The test is whether the misfit is in something central to how you operate, and whether the workarounds are costing more than a build would.
A concrete way to check: list the things your team does in a spreadsheet alongside the CRM, because that list is the requirement the product is not meeting. If it is small and peripheral, keep the product. If it contains the core of how you actually work, you are paying for a CRM and running your business next to it.
Then do the arithmetic on cost. Per-seat licensing across a few years, plus the consultant time spent configuring it, plus the hours lost to double entry, against a one-off build and modest hosting. Frequently the product still wins, and we will tell you when it does.
What a focused CRM actually needs
Far less than the products offer, which is the point. The records that matter to you with the fields you genuinely use, the stages your process actually has, a clear view of what needs attention today, a history of every interaction, and reporting that answers your real questions rather than generic ones.
What it does not need is marketing automation, lead scoring, territory management, forecasting models and the several hundred other features that make the enterprise products complex to configure and expensive to own. You are not buying a smaller version of Salesforce. You are building the twenty per cent you use.
Email and calendar integration is usually the exception worth keeping, because a CRM disconnected from where the conversation happens becomes a data entry chore, and data entry chores get skipped.
The risk worth stating plainly
A custom CRM is yours to maintain. There is no vendor shipping features while you sleep and no ecosystem of integrations built by other people. When a tax rule changes or a new channel appears, someone has to build it.
That is a genuine ongoing cost and you should price it in rather than discover it. For a focused system it is modest, and the care plan exists for exactly this, but a business that expects a custom system to be maintenance-free will be unhappy in year two.
The trade is control and fit against convenience and shared cost. Being clear-eyed about which side you are choosing is more useful than any feature comparison.
Common questions
Should we really build instead of using Salesforce or HubSpot?
Probably not, and we will say so where that is the answer. Those products are mature, well supported and far cheaper than custom development, and if your process fits a standard pipeline you should use one. Building makes sense when what you track is genuinely not a sales pipeline, or when per-seat cost across many occasional users has passed the cost of owning something focused.
What about the CRM data we already have?
It gets imported, and that is part of the build. Contacts, accounts, history and notes come across from an export. The usual complication is that years of data in a system with fields repurposed to mean other things needs a mapping decision, which is a conversation at scoping rather than a surprise later.
Will it integrate with our email and calendar?
Yes, and it is normally worth it. A CRM that is not connected to where the conversation actually happens turns into a data entry task, and data entry tasks get skipped until the record is worthless. Both major mail platforms have solid APIs for this, so it is well-trodden ground rather than a risk.
Who maintains it afterwards?
Either us on the care plan, your own developers, or another firm. This is a real cost to plan for: unlike a product, nobody is shipping improvements to your system while you sleep, and changes have to be built. For a focused system that cost is modest, but it should be budgeted rather than discovered.
Is this an AI CRM?
No. This is a database with the right shape, the right screens and the right rules, which is what the problem genuinely is. Adding a language model to a system whose real failing is that the fields do not match your process solves nothing and adds cost and unpredictability. If a specific automation is worth having later, it can be added to a system that already works.
Related
The capability pages behind this work, and the other offers in this set.
Which spreadsheet would you kill first?
Describe the workflow and what it runs on today. If it is not a fit for a fixed-scope build, we will tell you that rather than sell you one.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.