Custom business system or an existing CRM: how to choose

The choice is usually framed as "buy or build", but in practice there are three routes. You can buy a standard product and adapt to it. You can connect what you already use so that data stops being retyped by hand. Or you can build, custom, the part a standard product does not do. What decides it is not technology fashion but a few specific things: how far your process really differs from the typical one, how many systems have to talk to each other, and what it will cost to walk away if you change your mind in two years.

In short

• First answer honestly whether your process is genuinely atypical. If only the names differ, a standard product usually wins.
• Integration is a separate and routinely underrated route: sometimes the problem is not the system but that two systems do not talk.
• Build custom for the part that is your competitive difference, not the part that is the same for everyone.
• Work out the cost of leaving before you start. It is almost never just a data export.
• The GDPR right to data portability is narrower than commonly assumed — it does not cover everything in your system.

First question: is the process really atypical

This is worth asking honestly, because the answer is often no. A useful test: describe your process in neutral words, without your company's internal vocabulary. If the description starts to look like an ordinary sales or order process, a standard product probably does it and the difference is terminology. If steps remain that you have not seen elsewhere — say a multi-country approval with different rights and deadlines — then the atypicality is real.

The same criteria across three routes

Illustrative scenario, not a description of a client project. Imagine a company whose orders arrive through several channels while invoices are prepared in accounting software. Today the data is retyped by hand twice. The same need is now assessed across three routes on the same axes: process fit, integrations, data ownership, speed of change, and the cost of leaving.

Route one: buy a standard product

• Process fit: good for typical processes; atypical ones have to bend to the product rather than the reverse.
• Integrations: ready-made connectors often exist, but only for the systems the vendor chose to support.
• Data ownership: the data is yours, but the vendor defines its structure and the shape of the export.
• Speed of change: new features arrive without work from you, but your request is not the vendor's priority.
• Cost of leaving: moderate. An export usually exists, but settings, permissions and history travel far less well.

Route two: connect what you already use

• Process fit: the process does not change, so nobody has to relearn it — often this route's biggest advantage.
• Integrations: this is where all the work is. Every boundary between systems has its own failure cases.
• Data ownership: unchanged, because the systems stay the same.
• Speed of change: fast if only the data path changes; limited if you want a different process.
• Cost of leaving: the lowest, because you are not moving your operation into a new system.

Route three: build custom

• Process fit: complete, because the system is built around your process rather than the other way round.
• Integrations: exactly the ones you need, but each is built and maintained at your expense.
• Data ownership: complete, including the structure and the shape of the export.
• Speed of change: governed only by your own priorities — which is both the advantage and the responsibility.
• Cost of leaving: different in kind. The risk is not vendor lock-in but maintenance dependency: somebody has to understand and keep the code.

In this scenario the second route looks justified: the process is not atypical, and the real pain is data being retyped twice. Building custom would solve it but would also take on maintaining an entire system for what is essentially a question about a data path. Change one condition — if the approval process really were atypical — and the answer changes with it.

The cost of leaving: what you can actually take with you

This is the point most often skipped, and later the most expensive. It helps to separate three things that are not the same: the data, the structure, and the process. You will usually get a data export. The structure — the fields, their permitted values, the relationships between records — travels less well. And the process, meaning approvals, permissions and automated actions, usually does not travel at all and gets rebuilt.

There is also a common misunderstanding here worth correcting. GDPR Article 20 provides a right to data portability, but it is narrower than usually assumed: it applies to personal data the data subject themselves provided to a controller, where processing is automated and based on consent or a contract, and it must be supplied in a structured, commonly used and machine-readable format. That is an individual's right, not an entitlement for a company to extract everything in a system — your configuration, internal processes and inferred data are outside it. In practice your exit options are set by your contract with the vendor rather than by the general right. This is information rather than legal advice; specific terms are worth checking with your own lawyer.

• Does the export include the relationships between records, or only separate tables?
• Are attachments and files exported, or only links to them?
• Can you export whenever you like yourself, or only by asking the vendor?
• How long is the data available after the contract ends, and in what form?
• What happens to the integrations the vendor built for you?

A practical worksheet

• Describe the process in neutral words and mark the steps a standard product genuinely does not do.
• Count how many times the same data is entered by hand more than once. That is often the real problem.
• List the systems that have to talk, and what happens when one of them does not answer.
• Decide which part is your competitive difference. That is the only part worth building custom.
• Assess the cost of leaving at three levels: data, structure, process.
• Pick a first stage that is worth having on its own, even if you did nothing after it.

What this guide does not tell you

It contains no totals and no product-by-name comparison. Cost follows the number of integrations and the state of your existing systems, so a general figure here would be an assumption rather than an estimate. Nor does it rate specific vendors: their terms change, and the only place to check them is your own contract. Its purpose is to let you choose against criteria you can verify before signing.

If you prepare just two things before the conversation — the process described in neutral words, and a list of where data is entered twice — it will be clear which of the three routes you actually need.