Off-the-shelf CRM or something built for you: deciding honestly

The honest default, from people who build software

We build custom systems, so the recommendation that follows costs us work: most businesses asking for a custom CRM should buy an established one instead.

An off-the-shelf product has been shaped by many companies with the same problem, it is maintained by people whose only job is maintaining it, it is available next week, and it costs a subscription rather than a project. A custom system matches your process exactly on the day it launches and then needs somebody to keep it alive while browsers change, dependencies age and the business moves on.

That maintenance commitment is the part that gets underestimated. A system nobody maintains becomes a system nobody trusts, and the usual ending is a spreadsheet appearing alongside it because somebody needed a field the system did not have and could not wait.

There is a second reason to be sceptical of building, which is that a CRM is deceptively large. The part people picture, a list of companies and contacts, is trivial. What takes the time is everything around it: deduplication, import, search that works on partial names, permissions, an audit trail, email integration, mobile access, exports, and the hundred small behaviours people expect because every other system has them. A product has all of that already and you will not notice until you have to build each one.

Most complaints about CRM are complaints about setup

When a business says its CRM does not work, it is worth asking what specifically fails. The answers are usually consistent, and they are rarely about the product.

Nobody enters anything, because entry takes too long or duplicates what is already in email. The pipeline stages do not match how deals actually progress, so the reports are meaningless. Everybody uses one login, so nothing can be attributed. Half the records are duplicates because imports were never deduplicated. There are forty fields, thirty-five of which are empty.

None of those is fixed by building something new, and all of them will recur in a custom system within a year if the underlying problem is not addressed. The underlying problem is almost always that nobody owns the data or the process. Building a new system to escape that is an expensive way to arrive at the same place with worse support.

The test for whether it is a setup problem rather than a product problem is simple. Ask who is responsible for the data being correct, and who decided what the pipeline stages mean. If both answers are vague, the system was never going to work, because a CRM is a shared agreement about how work is described and the software is only where the agreement is written down.

When building is genuinely the right call

There are real cases, and they share a characteristic: the need is specific to how your business operates rather than to how you prefer software to look.

A useful sanity check on any of these: would a competitor your size, in your trade, recognise your process as unusual? If the honest answer is that everyone in the sector works this way, there is probably a product built for the sector, and finding it is cheaper than building. Genuine novelty is rarer than it feels from inside a business.

• The process is genuinely unusual, such as a trade with its own units, stages or regulatory records that no product models.
• The system has to join data that currently lives in several places, where the value is the joining rather than the storing.
• What is needed is an operations tool that happens to hold contacts: job tracking, site visits, quotes against stock.
• The volume of a specific repeated task is high enough that removing minutes from it pays for the build.
• A product would need so much customisation that you would own the complexity anyway, with none of the control.

The test: is this a CRM, or an operations system?

A clarifying question is what the software is actually for. If the job is remembering customers, conversations and deals, that is a CRM and the market has solved it well.

If the job is running the work, which means quotes becoming jobs becoming schedules becoming invoices, with who did what and what was used, that is an operations system. It holds customers because every operations system holds customers, but calling it a CRM sends you shopping in the wrong category and produces either a product that does half of it or a product bent badly out of shape.

Most of the custom work we do, set out on the custom CRM and custom ERP pages, is the second kind. The businesses that needed the first kind were better served by buying something, and we said so.

The distinction has a practical consequence for who should be in the room. A CRM purchase is a sales decision and sales should drive it. An operations system touches everybody who does the work, and specifying it without the people who will use it daily produces something that describes how a manager imagines the work happens rather than how it does. That gap is the most reliable predictor of a system nobody uses.

The middle path most people miss

The choice is presented as build or buy, and the useful answer is often neither in its pure form. Buy the product that handles the standard parts, and build only the specific thing it cannot do, connected to it.

A business might use an established CRM for contacts, pipeline and email history, and have one purpose-built tool for the thing that is genuinely theirs: a quoting calculator with their pricing rules, or a job tracker their engineers use on site. The two exchange data.

That keeps the maintenance burden proportionate. The large, complicated, security-sensitive part is somebody else's responsibility forever, and the small specific part is yours and stays small. It is almost always cheaper over five years than either extreme, and it is the shape we propose most often.

The connection between the two parts is where this shape succeeds or fails, and it is worth settling early. A nightly export is fine for reporting and hopeless for anything anyone acts on in the moment. A live connection is better and makes each system's availability depend on the other. Deciding which you need is a five-minute conversation that prevents a design nobody is happy with.

Sign-in, and why it decides more than people expect

Whatever you choose, it should use the accounts people already have rather than introducing another password. If the business runs on Microsoft 365, the system should sign in through that, which is a decision made at the start and awkward to retrofit.

The reason is partly convenience and mostly offboarding. When somebody leaves, disabling their account should remove their access to everything. A system with its own separate logins is the one everybody forgets, and a former employee retaining access to the customer list is the quiet version of a breach that nobody notices for months.

It also means the controls you already have apply to it, including multi-factor authentication and Conditional Access rules about where sign-in is allowed from. Anything built for us starts from that assumption rather than adding it later.

Individual accounts matter for the same reason. Shared logins make an audit trail meaningless, so nobody can answer who changed a price or deleted a record, and that question always arrives eventually. Where a system supports named users, use them from day one. Microsoft documents how multi-factor authentication works for the tenant those accounts live in, and a business system signing in through it inherits that protection rather than needing its own.

There is a data residency question worth asking too, particularly for anything holding client records. Where does the product store its data, and does that matter for your clients or your sector? For most businesses it does not change the decision, but it is cheaper to ask during a trial than to discover during a client audit. The UAE government publishes an overview of data protection law as a starting point.

How to decide without a long procurement exercise

Write down the five things the system must do, as sentences describing what somebody does, not as feature names. Then take two established products and try honestly to do those five things in a trial. Not a demo run by a salesperson, an afternoon with your own data.

If four of the five work and the fifth is awkward, buy the product and either live with the awkwardness or build the one thing separately. If three or more simply cannot be done, you have a genuine case for building, and you now have a specification written in terms of what people do.

That trial costs an afternoon and it is the single most useful thing you can do before spending anything. If you want the result looked at with you, including an honest answer about whether building is justified, get in touch.

One more thing to settle in that same afternoon: how your data comes back out. It applies equally to a product and to a build, and it is the question that decides whether this decision is reversible. We set out what to ask on getting your data out of business software.

Resist one temptation during the trial, which is to evaluate on the features list. Every product in this category has a features list that covers everything, and comparing them produces a tie. What separates products is how the five things you actually do feel when you do them twenty times, and that only shows up by doing them.

Frequently asked questions

Written by Srinivasan Ramachandran, Founder, Listonics · Published Oct 11, 2026 · Last reviewed October 11, 2026 · 2,021 words