2026-09-18
Custom CRM vs off-the-shelf: how to decide
Most articles on this question are written by someone who sells one of the two options. This one tries to be useful instead.
We build custom systems. That is our bias, and you should know it before reading. It is also why the honest version of this article spends most of its length explaining when you should not hire us.
The short answer: off-the-shelf wins far more often than the custom software industry likes to admit. The interesting part is identifying the cases where it does not.
What off-the-shelf actually gives you
Start with the strengths, because they are substantial.
It works on day one. No development time, no specification, no testing phase. You sign up and start entering data the same afternoon.
Someone else maintains it. Security patches, browser compatibility, new integrations, uptime. All of that is a line item in someone else's budget, not yours.
It has been debugged by thousands of companies. Every edge case you are about to discover has already been reported by someone else and fixed. Your custom system will find those edge cases on your time.
Documentation and training exist. New hires can watch a video. With a custom system, you are the documentation.
That is a strong list, and it is why the default answer to "should we build a CRM?" is no.
Where off-the-shelf stops working
Four situations, and they are more specific than "we're different".
Your process is genuinely non-standard and it is the reason clients choose you. Not "we do things our own way" — most companies think that and are wrong. The test is whether a competitor could copy your process and win your clients. If the answer is no, the process is an asset and forcing it into a standard pipeline destroys value.
Per-seat pricing has stopped making sense. More on the maths below, but the logic is simple: standard CRMs charge per user per month. Above a certain headcount that becomes a permanent, growing line in your budget.
You need integrations the product does not support. An industry system, a legacy database, a piece of machinery, a regional payment provider. Some of these can be bridged; some cannot.
The tool forces process changes that cost more than the tool saves. This is the one people miss. If adopting a standard CRM means three staff each spend twenty minutes a day on workarounds, that is roughly a month of salary per person per year, forever.
The per-seat maths
Do this calculation before any conversation with a vendor.
Take your realistic per-user price, multiply by users, multiply by twelve, multiply by three. That is your three-year software cost, and it excludes setup and consultancy.
Two things make it worse than it looks:
Feature tiers. The advertised price is rarely the tier that has the features you need. Reporting, automation and API access usually sit one or two levels up.
Growth. The cost scales with headcount. Doubling the team doubles the licence bill, whereas a custom system costs roughly the same for twelve users as for six.
Compare that number against custom development plus hosting plus a maintenance budget of roughly 15-20% of the build cost per year. Include the maintenance figure — a custom system with no maintenance budget becomes unusable in about two years.
Around ten to fifteen users, the two numbers often converge. Below that, off-the-shelf almost always wins. Above it, the answer starts depending on the other factors in this article rather than on price.
Vendor lock-in and data export
The risk that gets discovered at the worst possible moment.
Before you commit to any product, ask one question: can I export everything, including attachments, notes and history, in a format I can actually use?
The answers you may get:
- full export in a documented format — good
- CSV of the main tables only — acceptable, but you will lose
history, attachments and relationships
- "we can arrange a data extract on request" — treat as a no
- API-only export with rate limits that would take weeks — technically
yes, practically no
Test it. Sign up for a trial, put in twenty records, and export them. Ten minutes now can save a project later.
Custom systems have the opposite profile: the data is yours and sitting in your own database. Their lock-in is different — it is to the developer. Which is why the contract should specify that the source code and documentation belong to you.
Integration limits
Standard products integrate well with popular tools and poorly with everything else.
If your requirement is "connect to Gmail, Slack and Stripe", every product on the market does it. If it is "connect to the scheduling system our industry has used since 2009", you are in a different conversation.
Three questions worth asking a vendor:
- Is there a documented, public API, or only pre-built connectors?
- Are there rate limits, and what are they?
- Can we trigger an external action when a record changes, without
polling?
A no to all three does not disqualify the product. It does mean that any future integration will go through a third-party middleware service, with its own monthly cost and its own failure modes.
A decision table
| If this is true | Lean towards |
|---|---|
| Fewer than ten users | Off-the-shelf |
| Standard sales pipeline | Off-the-shelf |
| No unusual integrations | Off-the-shelf |
| You need it working this month | Off-the-shelf |
| Process is a competitive advantage | Custom |
| Licence cost above roughly €1,000/month | Custom |
| Core system has no public API | Custom |
| Regulatory constraint on data location | Either, check carefully |
| Staff maintain parallel spreadsheets | Investigate first |
The last row deserves attention. Shadow spreadsheets are a symptom, not a diagnosis. Sometimes they mean the tool genuinely does not fit. More often they mean nobody configured it properly or nobody was made responsible for keeping it current. Building a custom system to replace a badly configured standard one is an expensive way to make the same mistake twice.
The hybrid approach
The option that gets overlooked, and often the right one.
Keep the standard CRM for what it is good at — contacts, deals, email, calendar — and build only the piece that does not fit. That piece connects to the CRM through its API.
A concrete example: a company keeps a standard CRM for sales, and has a custom module for project costing because their pricing model is unusual. Deals sync one way; costing lives in the custom part.
Why this works: the expensive, boring, well-solved parts stay someone else's problem, and you pay for development only where it creates value.
Why it sometimes does not: it depends entirely on the CRM's API being good enough. Check that before designing anything.
Cost and timeline
| Work | Price | Timeline |
|---|---|---|
| Off-the-shelf setup and configuration | from €600 | 1-2 weeks |
| Data migration into a standard CRM | from €400 | 3-5 days |
| Custom module alongside a standard CRM | from €2,000 | 3-6 weeks |
| Full custom CRM | from €5,000 | 8-16 weeks |
Prices exclude VAT. Custom builds should also budget 15-20% of the build cost annually for maintenance.
Timelines for custom work depend almost entirely on how clearly the process is defined before development starts. An undocumented process adds weeks, because it has to be documented anyway — just later and more expensively.
How to decide in a week
- Write down your actual process. Not the ideal one. What
happens today, step by step, including the workarounds.
- Trial two standard products with real data, not the demo
dataset.
- Note every point where the tool fights you. Count how many are
genuine blockers and how many are just unfamiliar.
- Run the three-year maths for both options.
- Test the data export on the standard product.
If after that the blockers are few, take the standard product. If three or more are genuine and unavoidable, look at the hybrid approach before considering a full custom build.
In summary
Custom software is not better. It is appropriate in specific circumstances, and expensive everywhere else.
Decide with your own process written down and your own three-year numbers in front of you, not with a feature comparison table from a vendor's website.
Tell us what your process looks like and how many people would use the system. If a standard product fits, we will say so — that conversation costs you nothing and saves you more than we would have charged. Quote within one working day.
Discuss a project
Name, phone or email. No long brief needed — we will clarify on a call or by email.