CRM implementation: off-the-shelf or custom-built?
Standard is not automatically cheaper and custom is not automatically more expensive. The choice depends on your processes, your willingness to maintain the system, and what you want to be able to do five years from now.
The choice you make before the implementation
Most CRM projects that stall do not stall on technology. They stall on a decision made too quickly at the start: picking a package because it is familiar, or picking custom because a package looked expensive. Neither reason addresses the question that actually matters.
That question is: how unique is the process you want to support, and how much are you willing to invest to keep it running? This article helps you answer both before you request a single quote.
The most persistent misconception
A standard package is usually presented as the safe, predictable choice, and custom development as the expensive adventure. In practice that picture is incomplete.
A Salesforce implementation also takes a great deal of time to set up. Objects, fields, permissions, flows, reporting, integrations, user adoption: that is work, and it does not stop at go-live. Every release, every new process and every new colleague requires maintenance. Those costs simply are not in the licence, so they are harder to see.
Custom development puts the same costs on a single invoice. That feels more expensive, but mainly it is more honestly visible. The real question is not which option looks cheaper, but which one costs you least in money and attention over five years.
Standard is not automatically cheaper. Custom is not automatically more expensive. The difference is where the costs become visible.
When a standard package is the right choice
A package like Salesforce hands you decades of considered product work. That is an enormous head start, and you get it on day one.
- Your processes are fundamentally similar to those of other organisations: leads, quotes, orders, customer questions.
- You need an ecosystem: integrations, apps, certified specialists and a labour market that already knows the system.
- You do not want to depend on a single vendor or a single developer for future development.
- Compliance requirements and certifications matter and you would rather not have to demonstrate them yourself.
- Your organisation is growing fast and you do not yet know exactly where you will be in two years.
The main advantage of standard is not the price. It is that you inherit a proven foundation from which thousands of organisations have already worn off the rough edges.
When custom development makes sense
Custom pays off when the process itself is your competitive advantage. Not when you are simply hoping to spend less.
- Your core process differs materially from what packages support, and that difference is precisely why customers choose you.
- You are fighting a package that constrains you more than it helps, and the workarounds have become a maintenance burden of their own.
- The centre of gravity is integrations and data processing, with the CRM acting mostly as a layer around existing systems.
- You have a small team that uses only a fraction of a package while paying for the whole thing.
- You are prepared to keep it up: reserving budget and attention for ongoing development, not just for the build.
When custom is exactly the wrong answer
If nobody in your organisation wants to own the system, do not choose custom. A package keeps running while you look away; custom software that nobody maintains becomes a millstone within two years. That is the single biggest reason custom projects fail, and the reason is organisational, not technical.
The calculation you rarely see
Licences are recurring costs and they add up fast. A team of twenty on Salesforce Enterprise pays more than €200,000 in licences over five years, before a single hour of configuration has been done.
That is not an argument against Salesforce, because you get a great deal in return. It is an argument for making the comparison fairly: put recurring licence costs next to one-off build costs plus annual maintenance, over the same period.
Work it out for your own situation:
What do Salesforce licences cost you?
List prices per user per month, projected over several years.
Published Salesforce list prices in euros, per user per month. Enterprise and above are billed annually. Actual prices are often lower after negotiation, and configuration, migration and management are not included. Prices checked on 2026-08-03.
With custom development the weight shifts to the start: you pay for the build in year one and hosting and maintenance after that. With a package you pay the same amount every year, regardless of how much of it you use. Which curve works out better depends on your user count and your horizon.
Costs both options tend to forget
- Configuration and setup, often a multiple of the licence cost in year one.
- Data migration and cleaning up existing data.
- Training and adoption: a system nobody uses only costs money.
- Ongoing management: new requirements, new colleagues, changing processes.
- Integrations with your other systems, including maintaining them.
Can you build a secure CRM application with AI?
Now that AI assistants can generate entire applications, building has become cheaper and faster. That is genuinely true, and it changes the calculation above. But it raises a fair question: is the result secure enough for customer data?
The honest answer is: it can be, but not by itself. An AI generates code that works. Working code is not the same as secure code, and to a non-specialist the difference is invisible. A form that stores data works perfectly well, even when anyone on the internet can read that data back.
Where it goes wrong in practice is strikingly consistent: the database is open to anyone holding the public key, API endpoints do not check who is asking, secrets end up in the frontend, and there is no limit on request volume. Every one of these is invisible if you simply use the application.
AI lowers the threshold for building, not the requirement to secure it properly. Anyone who misses that distinction ships an application that works right up until somebody looks at it.
What secure custom development actually requires
These are the measures we apply as standard to what we build, including our own training platform. None of them is exotic, but together they are the difference between a demo and a production system.
Authorisation in the database itself
Row Level Security makes the database enforce, row by row, who may see what. Access is decided by the database, not the application. Nothing leaks, even if the frontend has a bug.
Secured API endpoints
Every endpoint checks who is making the request and whether that person may access this specific record. Authentication without per-record authorisation is a common mistake.
Rate limiting
A cap on requests per user and per IP address. Prevents form abuse and bulk extraction of data through repeated requests.
Secrets outside the frontend
Keys and tokens live in environment variables on the server and never reach code that runs in the browser. A key in the frontend is a key everyone has.
Encryption of sensitive data
Data such as access tokens is stored encrypted with AES-256-GCM, using a derived key per customer. In the event of a breach the contents are unusable.
Secure integrations
Connections to external systems use OAuth with PKCE and state validation, so an intercepted request cannot be replayed.
These measures are not an extra at the end of a project. They shape how you build from day one; retrofitting them costs more than doing it right immediately.
How to make the call
Work through these questions. They predict the outcome better than a list of functional requirements.
- Is our core process genuinely different, or does it just feel that way because we are used to it?
- Who will own this system, with time and authority, two years from now?
- What happens if the builder or consultant disappears tomorrow?
- How much of a standard package would we actually use?
- Can we live with a package's constraints, or will we spend our time fighting them?
- What is our horizon: three years, or fifteen?
If you are still unsure after these questions, that is an answer in itself. When in doubt a standard package is usually the wiser choice, because it leaves the door open to add custom later. The reverse is considerably harder.
What we do differently from other Salesforce implementation partners
Most implementation partners sell one answer, because they know one product. We do both Salesforce implementations and custom development, which makes the advice up front more honest: we have no stake in a particular outcome.
More often than you might expect, the advice is not to build custom at all. A well-configured package beats custom software that nobody maintains.
When we do build custom, we build on Next.js, Supabase, Vercel and Resend: mature technology that plenty of developers can work with. That is a deliberate choice, because it limits how dependent you are on us.
Frequently asked questions
Is custom cheaper than Salesforce?+
Sometimes, but not by definition. With few users and an unusual process, custom can work out better over five years because you pay no per-user licences. With many users on standard processes a package almost always wins, because you share the development cost with every other customer of that vendor.
How long does a CRM implementation take?+
For a standard package with a defined scope, expect several weeks to several months, depending on data migration and integrations. Custom usually starts delivering later but then delivers exactly your process. In both cases the timeline depends mostly on how quickly your organisation makes decisions.
What happens if the builder of our custom system disappears?+
That is the main risk of custom software and the reason to insist on mainstream technology, readable code and documentation. We build on a stack many developers know, and you receive the source code. Ask any custom supplier about this; a vague answer is a warning sign.
Is a custom application secure enough for customer data?+
That depends entirely on how it was built. Authorisation in the database, secured endpoints, rate limiting, secrets on the server and encryption of sensitive data are the minimum. A package ships this by default; with custom you have to demand it explicitly and have it demonstrated.
Can we move from custom to a package later?+
Yes, but expect a migration project: moving data, reconfiguring processes, bringing users along again. The other way round, package to custom, is usually easier because your data is already structured. That is one reason to start with a package when in doubt.
Can we combine the two?+
Often that is the best outcome. Salesforce for sales and service, where it is strong, and a custom layer for the process that makes you distinctive, connected through APIs. You then pay licences only for the people who genuinely use the package.
Help with the choice or the build?
Unsure between standard and custom?
In a no-obligation 30-minute call we look at your processes and give you honest advice, even if that means you do not need us.