CRM implementation without a pre-cooked answer
Most suppliers sell one solution, because they know one. We do both Salesforce implementations and custom development. That lets us tell you honestly, up front, which route suits your processes.
Two routes, one honest assessment
Which route fits depends on how unique your process is and how much you want to invest in maintenance. Not on what we would rather build.
Implementing Salesforce
A proven foundation with a large ecosystem, certified specialists and a labour market that knows it. The right choice when your processes are fundamentally similar to others' and you do not want to depend on a single supplier.
Go to Salesforce implementationHaving custom built
An application that follows your process exactly, built on Next.js, Supabase, Vercel and Resend. Worthwhile when your core process is your competitive advantage and you are prepared to maintain it. You receive the source code.
See the custom CRM subscriptionWhat we often advise
More often than you might expect, our advice is not to build custom. A well-configured package beats custom software that nobody maintains. The key question is not which technology is better, but who will own the system two years from now.
The reverse happens too: organisations that spend years fighting a package while paying tens of thousands a year in licences for functionality they barely use. We will say that just as plainly.
In each of these projects a standard package was part of the assessment. Each time the numbers or the process tipped the balance: logins for people outside the organisation, a core process no package covers, or manual work a package did not remove.
Custom builds in practice
Read how the custom CRM subscription works
Custom CRMA custom CRM for De Leasebaas, including a customer login
One request goes out word for word identical to every leasing company. What comes back is read out and put side by side, so comparing is no longer a reading exercise.
Read the story
Custom CRMAn internal CRM for Next Win, with permissions in the database
An internal CRM that external callers work in too. Who may see what sits in the database rather than in the screen, and that can be verified.
Read the story
Custom CRM + webshopOne system for RoPa Workwear, with clothing management at its core
Clothing management for business customers sits at the core of the system: a budget per employee, sizes per person, and a request that goes past the manager.
Read the story
Custom CRM + webshopA custom CRM and webshop for IT'S PAWSOME
One paid order writes off stock, files the invoice in the bookkeeping and registers the shipment. A repeated message from the payment provider changes nothing.
Read the story
Custom CRM + webshop, under constructionOne environment for Hartog Outdoor Living, from webshop to customer portal
Webshop, configurator, customer portal and CRM are being built as one environment, with a single go live. This story describes a project in progress, not a result.
Read the storyThe calculation you rarely see
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.
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.
When does which route fit?
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.
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.
How we approach it
- 1
Walk through your processes
We look at what you do today and where it chafes, before saying anything about systems.
- 2
Compare the routes
Standard, custom or a combination, with multi-year costs side by side.
- 3
Build or configure
In short steps with working deliveries, so you can adjust along the way.
- 4
Hand over
Documentation, source code and training, so you can continue without us.
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.
We build custom software together with Next Win
CRM Force specialises in Salesforce. For custom work beyond that, such as client portals, webshops and internal business applications, we work closely with Next Win, the agency of developer Gerwin Morren.
That combination means the build side and the Salesforce knowledge sit in one team. A portal or webshop that needs to connect to Salesforce is built and integrated by us, without a third party in between.
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.
Curious which route fits you?
A no-obligation 30-minute call. We think along and give honest advice, even if that means you do not need us.
Schedule an intro call