Loading
CRM9 min read
Spreadsheets and subscription CRMs work until they do not. Here is how to tell which side of the line you are on.
Most businesses do not decide to buy a CRM. They notice, gradually, that they have lost track of things. A quote nobody followed up. A customer who called twice about the same problem. A month where nobody could say how many enquiries came in.
The question is not whether you need a CRM — you almost certainly do. It is whether you need one built for you. These are the signals that point to yes.
Website form goes to email. Phone enquiries go in a notebook. WhatsApp stays on someone's phone. Walk-ins get remembered, mostly. Nobody can produce one list of who is currently interested in buying from you.
The deals you lose are rarely the ones you were rejected for. They are the ones where nobody called back. If your follow-up system is a person's memory, you are losing revenue you cannot even measure.
Someone rings, and answering means asking three colleagues and searching a chat history. A CRM's real value is not the pipeline chart — it is that anyone can pick up any customer's history in ten seconds.
You are using a field called "Deal Value" to store something that is not a deal value. Half your stages are named things the software calls something else. Your team maintains a private spreadsheet because the real process does not fit.
Subscription CRMs are excellent value at five users. At thirty, particularly when twenty of them need read access for ten minutes a week, the maths changes. At some point an owned system pays for itself and keeps paying.
The CRM needs to know what the POS sold, or the accounts system needs to know what the CRM closed. When integration is a core requirement rather than a nice-to-have, building the thing that sits in the middle is often simpler than forcing two products to cooperate.
If every management question ends with someone downloading a CSV and building a pivot table, the reporting layer is being done by a human. That is expensive, slow, and out of date the moment it is finished.
This deserves saying plainly. If a subscription CRM does most of what you need, use it. It is available today, it costs less up front, and someone else maintains it. Custom development is the right answer when the gap between your process and the product is large enough to cost real time — not when the product is merely imperfect.
A good test: list the five things your team does most often. If a product handles four of them well, buy it and live with the fifth. If it handles two, building is worth pricing.
Subscription pricing is per user, per month, forever. Do the arithmetic for your own team rather than trusting anyone's example: seats times monthly fee times the tier you will actually need — the tier question matters, because automation, permissions and decent reporting usually live above the entry plan.
Then look at the shape of your users. A sales team of five where everyone lives in the CRM is the product's best case. Thirty staff where twenty need ten minutes of read access a week is its worst — you are paying full seats for people who barely touch it. A custom system has the opposite shape: the build costs real money once, and additional users cost approximately nothing.
Neither shape is universally better. The point is to run your numbers over three to five years, because that is the horizon on which an owned system either pays for itself or does not.
Every serious CRM product is customisable — fields, stages, workflows, sometimes scripting. The ceiling is real, though: you can rename what the product already believes in, but you cannot easily make it believe in something else. A pipeline that branches, an approval that depends on who the customer is, pricing rules with genuine exceptions — this is where configuration ends and consultants begin.
The warning sign is when customisation fees and consultant days start being quoted in the same order of magnitude as a build. At that point you are paying custom prices for a rented system, and the comparison deserves to be reopened.
With a subscription, your customer history lives in someone else's product, structured their way. Export is usually possible; a clean landing in the next system is harder — automations, history and attachments rarely travel intact. The switching cost quietly becomes an argument for staying, whether or not staying is right.
An owned CRM inverts this. The database is yours, on infrastructure you control, exportable because you designed the export. What you give up is the vendor's roadmap: new features arrive when you commission them, not free with the next release. Both facts belong in the decision.
Everything beyond that list is worth questioning. The most common reason a CRM project fails is not missing features. It is that the system asked people to do more work than the one it replaced.
If the signals in this article sound familiar, our custom CRM development service page covers what a build actually involves — scope, migration, integrations and the questions we ask before quoting. And if the conclusion is that a subscription fits you, that is a good outcome too: it is the cheaper one.
Get in touch
Tell us what you need. We will come back with questions, an approach and a price.