Custom CRM, configured CRM or off the shelf: how to choose
A custom CRM is a customer relationship management system built for one business, around the records and rules it actually works with, rather than a product set up from everyone else's template. You will also hear it called a bespoke CRM. If you are thinking of building your own, there are three routes, not two, and the middle one is often the right answer.
We do bespoke software development, CRMs included, and we will say plainly when you shouldn't build one.
Three routes to a CRM
Off the shelf, used as it comes
You sign up, import your contacts and start work. Most CRMs are built around people, their companies and the deals you are trying to win. If your sales work is a pipeline of deals moving through stages, this is the cheapest and quickest route, and improvements arrive without you commissioning them.
A CRM platform, configured and extended
The bigger platforms let you change the data model itself, not just add fields.
- HubSpot lets you define custom objects for data its standard objects don't fit, linked to contacts, companies, deals and tickets and usable in workflows and reports. They need one of HubSpot's Enterprise subscriptions, each with a limit on how many.
- Salesforce ships standard objects such as Account, Contact, Lead and Opportunity, and lets you create custom objects to store information specific to your company or industry.
- Dynamics 365 keeps its standard tables in Microsoft Dataverse, where you can create custom tables beside them, link tables with relationships, switch on auditing of changes and set duplicate detection rules.
You keep the platform's email integration, permissions and reporting, and add your own records on top. The costs are often a higher licence tier, someone who knows the platform well, and lock-in: the more you build on a platform, the harder it is to leave.
A custom CRM built for you
A custom CRM starts from your records and rules instead of someone else's. A letting agent works with properties, landlords, tenants and tenancies; a recruitment agency with candidates, clients, vacancies and placements. Neither is a deal moving through stages, and both sectors have specialist CRMs built around those records, worth trying before you build. You own the code and the data, and no subscription tier limits what you can model. You also pay for everything a product would have given you, from permissions to security updates.
What each route costs to run
These are list prices from each vendor's own pricing page, as of October 2026.
| Plan | Listed price | Billing |
|---|---|---|
| Salesforce Starter Suite | £20 per user per month | Monthly or annually |
| Salesforce Pro Suite | £80 per user per month | Annually |
| Dynamics 365 Sales Professional | £50.00 per user per month, excluding VAT | Yearly |
| Dynamics 365 Sales Enterprise | £80.70 per user per month, excluding VAT | Yearly |
| HubSpot Sales Hub Enterprise | From $150 per seat per month, plus a required one-time onboarding fee of $3,500 | Not stated; the page shows US dollars, plus tax |
Twenty users on Salesforce Pro Suite come to £1,600 a month, or £19,200 a year. Twenty on Dynamics 365 Sales Enterprise come to £1,614 a month before VAT, or £19,368 a year. Twenty seats on HubSpot Sales Hub Enterprise, the Sales Hub tier with custom objects, start at $3,000 a month, plus the $3,500 onboarding fee. Add-ons and configuration come on top.
A custom CRM turns that around. There is no licence per user, so giving the warehouse, field staff or customers access doesn't add seats. The big cost is the build, paid up front or in stages; after that, hosting, backups, monitoring, security updates, fixes and changes. The server is rarely the large part; people who can change the system safely are. Make sure another developer could take it on.
So the sums usually favour a platform for a small sales team with a standard pipeline, and a build when many people need access, when the tier you'd need is the expensive one, or when you'd pay for a platform and still run half the work from spreadsheets.
Signs a custom CRM is the right answer
- The work doesn't fit contacts, companies and deals. If you manage things with a life of their own, such as properties, placements, contracts or sites, a deal is the wrong shape, and the real records end up in notes fields or a spreadsheet.
- Heavy rekeying between systems. The same customer is typed into the CRM, the job system and the accounts package, and each copy drifts. A process map of how a customer moves through the business shows where.
- Rules the CRM can't hold. Pricing that depends on several factors, checks before a step, approvals, or steps a regulator expects you to record. A rule that lives in someone's head gets missed.
- Many light users. People who need to see or update one or two things, each priced as a full seat.
The signs it isn't: your process is a standard sales pipeline; people don't use the CRM you have, which a new one won't fix; or you haven't tried configuring your current plan. Our bespoke software examples include a CRM for an unusual sales process, alongside the cases where buying is better.
The parts every CRM needs
Every route needs these. A platform includes them, which is much of what the licence pays for; in a custom build, each is work to specify, build and test.
A data model that matches the business
The records and how they link. Even people and companies are harder than they look. We built and run Add to CRM, a Chrome extension that adds people from LinkedIn, Gmail and Outlook to any of 29 CRMs (as of 28 October 2026), each with its own sign-in, field types, limits and quirks. Some separate leads from contacts, so teams choose which a new person arrives as. A few ask which board, base or workspace a person belongs in. The company is created or linked as a record of its own. Because field types differ, we match each value to an existing field by name and type, never map text to a picklist, and create a field only when one is really missing. Agree what a person, a company and the link between them mean for you before anyone writes code.
Permissions
Who can see and change which records: by role, by team, or by who owns the record. Decide early, because permissions shape the data model. In Dataverse, for example, a table's rows can be owned by a user or team, or by the organisation.
Audit history
Who changed what, and when, so you can settle disputes and trace a person's data. Dataverse captures changes to records once auditing is switched on. In a custom build, plan the history from the first table. Writes need care too: in Add to CRM, an edit replaces only the values the user was shown, so anything a colleague added meanwhile is kept.
Imports and duplicates
Duplicates creep in through imports, web forms and two people adding the same contact. Matching rules decide when two records are one person, and doubtful cases need a human. In Add to CRM a shared name is a question, not a match: someone must approve it, because one wrong link would let a later update overwrite another person's record.
Email and calendar
The CRM needs to log emails and meetings against the right records. Connecting to Microsoft 365 or Google Workspace means handling sign-ins that expire and renew, so in a custom build, scope and price this piece on its own.
Reporting
Build reports around the questions people ask every week, such as which renewals are due or which jobs are overdue, and keep an export for the questions nobody predicted.
UK GDPR basics for customer data
A CRM is mostly personal data, so UK GDPR applies whichever route you take. Three basics from the Information Commissioner's Office (ICO) shape the design. This summarises the ICO's guidance and is not legal advice.
- Lawful basis. The ICO's guide to lawful basis, updated in April 2026 for the Data (Use and Access) Act, lists seven and says you must decide your basis before you start using the information and document it. A CRM can record where each person's details came from.
- Retention. UK GDPR sets no fixed time limits, but the ICO's storage limitation guidance says you must not keep personal data longer than you need it, should set standard retention periods wherever possible, and should periodically review what you hold and erase or anonymise what you no longer need. Build retention dates, and a way to delete or anonymise, into the CRM.
- Subject access. People can ask for a copy of their data. The ICO says you must respond without undue delay and at the latest within one month, extendable by two further months if the request is complex or you have had several from the same person. So you need to find everything about one person quickly, notes and emails included.
Moving your data out of the old system
- Export everything. Notes, activities, emails, attachments, owners and dates as well as contacts, plus each record's old ID to keep on the new one, so anything can be traced back. Check what the vendor's exports include before you give notice.
- Map old to new. Field by field, and decide what not to bring: records you no longer need are a retention question.
- Clean and de-duplicate before import. It is far easier than doing it afterwards.
- Run a trial import. Import into a copy, compare record counts, and have the people who use the data check a sample.
- Cut over on a set date. Freeze changes in the old system, run the final import, and keep a full export for as long as your retention policy says.
If you want a hand
If a platform fits, configure it; we will tell you so. If it doesn't, start a project and tell us how your customers and jobs move through the business.