When a custom CRM is the wrong answer

I build CRMs for a living, so this post is mostly an argument against hiring me. The unified CRM I built at CustomGlide exists because a small number of teams have a reason to own their customer system. Most of the people who ask me for one do not have that reason. They have a spreadsheet with a vendor's price on it, and the spreadsheet is answering the wrong question.

Price is the wrong spreadsheet

The price is real and it is high. Salesforce's Sales Cloud pricing page lists five editions in 2026: Starter Suite at 25 dollars per user per month, Pro Suite at 100, Enterprise at 175, Unlimited at 350, and Agentforce 1 Sales at 550, with everything above Starter billed annually. Zoho prices in rupees for Indian customers: Zoho CRM's pricing runs 800, 1,400, 2,400 and 2,600 rupees per user per month on annual billing for Standard, Professional, Enterprise and Ultimate, before GST.

Put twenty seats on Salesforce Enterprise and the line reads 42,000 dollars a year. Against that, a build quote for a few months of engineering looks like a bargain, and the spreadsheet says build.

The spreadsheet is wrong because it compares a subscription with a project, and a custom CRM is not a project. It is a second product your company now owns, with its own migrations, security patches, exports, backups, and the one engineer who understands the schema. That ownership runs for as long as the sales team exists, and the sales team outlives every engineer. The subscription is expensive because it is priced to include the ownership you are trying to avoid.

There is a second thing the spreadsheet leaves out, which is everything the subscription includes that nobody thinks to list. A mobile app that works. Field-level permissions that have been audited by people whose job is auditing. An activity log that satisfies a compliance reviewer without a meeting. Two thousand integrations that already exist. Email deliverability someone else worries about. A team building a custom CRM rebuilds a thin version of each of these, one support ticket at a time, and none of that work is on the quote because none of it was in the original idea.

So the decision cannot rest on price. It has to rest on something the vendor cannot sell you, and there is exactly one such thing.

Write down ten verbs

Here is the test I run before I quote anything. Write the ten verbs your team performs on a customer record in an ordinary week. Not the nouns, not the reports, the verbs.

For most teams the list reads: create, assign, move stage, log a call, send a sequence, attach a file, set a reminder, close won, close lost, report. Every vendor on the market has those verbs. They have had them for twenty years, and their implementation of each one is better tested than anything I will write in a quarter. A team whose list looks like that should buy, and should spend the engineering money on the integrations around the edges.

Now look for a verb the vendor cannot express without a workaround. Scan a visitor in at a gate and refuse the second scan. Hold funds in escrow until both sides confirm. Dispatch a field team and require a photo before the job closes. Recheck a compliance document every ninety days and block the deal while it is expired. These are verbs that touch revenue directly and that a stock CRM can only fake with a custom object, a flag field and a workflow rule nobody trusts. That verb is the reason to build, and it is the only reason.

Take the attraction in the table. Booking, issuing, refunding, assigning and reporting are ordinary CRM verbs. One verb is not: admit a visitor exactly once, at a gate, in under a second, and refuse every later scan of the same code. That verb is the business, because every failed refusal is a free entry. When I built the QR ticketing system it was this verb that needed real engineering, and it is a small, sharp piece of software. The rest of that attraction's customer data belongs in a system somebody else maintains.

The four answers

Two questions sort every case I have seen. Does the vendor have all ten verbs, or is one missing. And does the team need to own the data model outright, for regulatory, contractual or integration reasons, or does it just want the data to be exportable. Each pair of answers has one honest response.

The bottom-left quadrant is where most teams live, and the right answer there is to buy the cheapest edition that has the verbs and stop. The bottom-right quadrant is the attraction: buy the CRM, build the gate, and connect them with one integration that writes a scan event back to the contact. That is a fraction of a custom CRM and it keeps the sharp piece sharp.

The seam between the two systems is where that option succeeds or fails, so it deserves a rule of its own: the built system owns exactly one kind of record, and the CRM owns everything else. The gate owns tickets and scans. It never stores a customer's email, because the CRM already does, and it never decides who a customer is, because that is the CRM's verb. When a scan succeeds, the gate writes one activity back through the vendor's API, keyed by the CRM's own contact id, and that is the entire integration. Two systems that each own one kind of truth stay simple for years. Two systems that both keep a copy of the customer spend those years arguing. The top-left quadrant is a team with a contractual or regulatory need to hold its own copy of the data; it buys, exports on a schedule, and owns a warehouse rather than a CRM. Only the top-right quadrant builds, and it builds because a missing verb and an ownership requirement arrive together.

What building actually buys

I should say what the top-right quadrant gets for its money, because it is real. A schema you can query directly. Exports that are never a support ticket. A stage history you can replay. Integrations that do not fight an API rate limit. A system that does one unusual thing well because it was designed around that thing.

The CRM I built lives in that quadrant for a specific reason: it is a migration target for teams leaving Salesforce, HubSpot and Zoho, and the thing those teams have in common is that they arrived with a verb the vendor had been faking for years. Usually it was a pipeline whose stages meant something the vendor's stage model could not hold, or a ticketing flow that had to share a contact with sales without a sync job. They did not leave because of the price. They left because the workaround had become the process, and the process was the business.

And the price, stated plainly: you are now the vendor. When the ticketing verb changes, you change it. When a browser drops an API your scanner used, you fix it. When the engineer who built the schema leaves, you hire someone to read it. That is a fair trade for a business whose revenue runs through a verb nobody sells. It is a bad trade for everyone else, and the way to know which you are is to write the ten verbs down before you write to me.