Custom CRM or an existing solution?

01

Start with the sales cycle and observed difficulties

Before comparing tools, describe how an opportunity moves from first contact to a sale and subsequent customer follow-up. Identify the people involved, the information handed over and the decisions that move the case forward. Existing files, screens and exchanges help make the process concrete.

Then classify the difficulties: scattered information, missed follow-ups, repeated entry, difficult approvals or incomplete reporting. Some stem from an unsuitable tool; others from an unclear working rule. A step unique to your organisation does not automatically justify rebuilding it unchanged: first understand its value and the constraints behind it.

02

When an existing solution is a strong starting point

First test what the tool can do through its standard functionality, then examine important gaps. This distinction between available features and required adaptations is formalised, for example, in Microsoft’s fit-to-standard and fit-gap approaches for Dynamics 365.

An existing solution is a strong candidate if priority journeys, permissions and information can be covered through understandable configuration. Check the actual plan being considered: included features, administration options and usage conditions need confirmation when making the choice.

Implementation work still needs planning: organising data, defining shared rules, preparing connections and supporting users. An available tool does not automatically become an adopted tool. A demonstration using your own scenarios is more useful than a checklist of advertised features.

03

When a custom CRM becomes a relevant option

A custom solution deserves investigation when essential product rules, data relationships or journeys remain difficult to support after a serious review of available tools. One example might be a sales case linking several sites, contributors and approvals under business-specific rules.

The question is whether building these capabilities provides enough value to justify designing and operating them. Define permissions, case states, connections, tests and data migration. The initial scope can focus on a complete use case and evolve from users’ experience.

Custom software requires a product owner, technical monitoring and maintenance decisions. Code, environment access and documentation should be specified as deliverables. Security, quality and team autonomy need preparation and verification; choosing custom development does not provide them automatically.

04

Consider a hybrid solution and verify integrations

You can keep contacts and opportunities in an existing CRM while building a dedicated calculation, approval flow or portal. This option is worth comparing when the sales foundation works but part of the business needs specific functionality.

Decide where each piece of information is authoritative, how identifiers are linked and what happens when an exchange fails. Plan for duplicates, concurrent changes and recovery. The existence of a connector or API does not demonstrate that a synchronisation covers your journey.

Also check the selected service’s technical limits. Microsoft documents, for example, protection limits on Dataverse APIs and the need to manage retries for integrations that place heavy demands on the service. Examine volumes, peaks and handling rules for the tool actually being considered.

05

Compare costs across the full period of use

Comparing a subscription with a development quote gives an incomplete picture. For each option, distinguish setup, data migration, connections, training and operations. Also identify the work the team will still perform outside the CRM.

For an existing solution, examine users, required features, possible modules and configuration services. For a custom product, examine delivery, hosting, monitoring, updates and improvements. The proposal should explain what is included, what remains variable and who monitors it.

Use the same comparison period and several activity scenarios: the current team, expected growth and new integrations. Avoid assuming that one option will always become cheaper at a particular number of users. The outcome depends on scope, selected plans, volumes and actual responsibilities.

06

Test data migration and your ability to leave

Request a trial export before deciding. HubSpot’s documentation distinguishes, for example, record exports containing properties and associations from exports of activities such as calls and notes. This illustrates why an export button alone does not guarantee recovery of everything you will need.

Check what you need to recover: contacts, companies, cases, record relationships, history, documents and important rules. Identify the output format, required permissions and mapping work for the future system. Examine an export and test a sample rather than accepting exportability as an unverified claim.

For a custom CRM, continuity also requires usable access, current documentation and a way to operate the service again. A code repository is insufficient if nobody can prepare the environment or interpret the data. For either approach, describe handover and exit responsibilities during discovery.

07

Use a common decision framework

For each criterion below, record what is demonstrated, what needs configuration, what requires an extension and what remains blocking. Support each point with a tested scenario, a documented limit or a question to resolve. Define essential criteria before comparing options.

An overall score can support discussion but should not conceal an essential blocker. A tool covering many secondary needs can still fail a critical rule. Conversely, a presentation difference or a changeable habit does not necessarily justify custom development.

08

Decide through a pilot and prepare adoption

Choose a complete journey, a suitable data sample and a few representative users. Have them perform the same tasks in the options being considered or the prototypes planned during discovery. Observe required actions, errors, corrections and the information actually available to support a decision.

Separate verified results from assumptions. If an option requires development or an untested migration, record that uncertainty in the comparison. The pilot should lead to a scope decision and next steps, not merely a successful demonstration.

Finally, prepare data owners, administration, training and feedback monitoring. After launch, measure actual use and remaining difficulties. The CRM’s success also depends on how the organisation runs it, whatever architecture is chosen.