Start with the part that is inconvenient for us: most businesses need an off-the-shelf CRM. It is cheap, it is available today, somebody else maintains it, and for a standard sales process it is simply enough. We build custom systems, and we still say this to clients before they spend anything.
But there is a point where the arithmetic flips, and it is not a matter of feeling. It is a calculation, and it is not a complicated one.
What the difference actually is
Most comparison tables on this subject are written by somebody selling one of the two sides, which is why one column is all advantages and the other all drawbacks. That is not a comparison, it is an advert. Here is a version where both sides have a price:
| Off-the-shelf | Custom | |
|---|---|---|
| Time to start | Today | Months |
| Initial cost | Low, a monthly subscription | High, a one-off investment |
| Cost as you grow | Rises with every user added | Relatively flat, but maintenance is yours |
| Fit to your process | You adapt the work to the system | The system is built around the work |
| Maintenance, backups, security | The vendor's job, included | Yours, or whoever you hire |
| When something breaks | Vendor support, on their schedule | Depends who built it and whether they are around |
| Data ownership | With the vendor, export takes work | Yours, with full access |
Per-seat pricing, and when it starts to hurt
Paying per user makes sense at first: you pay for the people working, and there are few of them. The problem starts when the team grows and the price turns out not to distinguish between a salesperson who lives in the system and somebody in the warehouse who logs in twice a day to change a status.
What sharpens it is that the capabilities you actually need — automation, granular permissions, reporting — usually sit in a higher tier, and you pay that higher price for every seat rather than only for the people who need the capability.
The familiar result is a business paying thousands a year and starting to ration seats: a few people share a login, one person updates on another's behalf, and some of the work drifts back into a spreadsheet on the side. Once that happens, the system is no longer a source of truth.
The cost the other side does not mention
Whoever is selling you custom development will say “and then server costs are negligible”. That is not true, and it is what turns these projects into disappointments.
A system you own needs: hosting and backups somebody actually verifies, security updates to its libraries, monitoring that raises an alarm when something falls over on a Saturday, and someone available to fix it. And — the part that surprises people most — continuing development, because a growing business asks for changes.
So the comparison has to be an annual subscription against a real annual cost: maintenance, hosting, and the development hours you will need anyway. If somebody shows you that as zero, they have not finished the sum.
The arithmetic itself
The decision is financial, so it is worth making with numbers. Three figures, over three years:
What you pay now — total subscriptions, multiplied by the number of users you will need over the next three years rather than today, plus any add-ons billed separately.
What the system costs you without appearing on an invoice — how many minutes a day each person loses to an interface that does not match the process, how often a figure gets typed twice, and how many leads slip because the follow-up lives in a spreadsheet on the side. Multiply by salary. This is usually the largest number and almost always the surprising one.
And what a custom system costs — the build, plus maintenance, hosting, and ongoing development for three years.
If the first plus the second is smaller than the third, stay where you are. If they are larger by a clear margin rather than a narrow one, there is a decision here. At the margin, stay — a development project always takes longer than planned.
Three situations where the answer is obvious
A standard sales process, a team growing slowly, and a limited budget — off-the-shelf, without hesitating. In five years too. There is no value in rebuilding something that exists and works.
A process that is the core of the business and resembles nobody else's — pricing that depends on ten variables, say, or a service with stages that have no equivalent elsewhere — that is where a stock system fights you daily, and the customisation you need costs more than building would.
And the third case, the most common one and the least discussed: keep the commercial system and build only the part that does not fit. A purpose-built interface over its API, an internal tool for one team, a dashboard that pulls from it. It costs a fraction, and most of the pain goes away.
And what about AI
The claim that a closed system locks you out of AI is overstated. Most commercial CRMs have an API, and you can connect a model to one without the vendor's permission.
What is true is a matter of cost and control: when the data sits with you it is easier to run retrieval over it, build internal tools on it, and choose which model it reaches — or keep it from reaching one at all. Inside a closed system you pay for the vendor's capabilities at the vendor's price, which is sometimes very high.
But that is a secondary reason rather than a primary one. Anyone moving to a custom build for AI rather than for the process is building an entire system to solve a problem one tool would have solved.
A CRM is not a statement of intent, it is a tool, and the right tool is the one your team actually opens in the morning. For most businesses that is an off-the-shelf system, and we say so even when it means we build you nothing.
And when the arithmetic does flip, you get to see the numbers before you decide — including the maintenance nobody likes to put in them.