A custom CRM is the wrong answer for most businesses. Pipedrive, HubSpot and the rest are cheap, mature and good at what they do, and a small team tracking deals through five stages does not need anything built.
The case for building only appears when the standard shape of a CRM stops matching the shape of your work.
What a standard CRM assumes
Almost every one of them assumes the same story: a lead arrives, a salesperson works it through named stages, and it closes won or lost. Reporting, automation and permissions are all built on that spine.
If your business runs that way, use one. The trouble starts when the real process has a survey to book before a quote can exist, or a deposit that unlocks manufacturing, or an install date that depends on parts arriving, or a job that stays open for aftercare long after the sale closed. Those do not fit stages, and the usual response is to bolt on custom fields until the thing is unrecognisable.
At that point you have already built something custom. You have just built it badly, inside somebody else's product, and you are paying a subscription for the privilege.
The tell is a field called something like Status 2, or a stage that everybody knows means three different things depending on who moved it there.
When a custom CRM is the wrong answer
Be honest about which of these you are:
Your process is unusual, or your process is undocumented. These feel identical from the inside. A process nobody has written down looks bespoke because everyone does it differently, and building software around that just makes the confusion permanent and expensive.
Write the process down first. If it fits a standard tool once written, you have saved yourself a great deal of money. If writing it down proves it genuinely does not fit, you now have the requirement document for a build, which you needed anyway.
What building actually gets you
One place where a job is a job, rather than a deal in one system, a spreadsheet of parts in another, and a fitting date in a shared calendar. That single view is usually the whole return on the project.
Fox Wardrobes had exactly that spread: quotes, contracts, payments, cut lists and install dates in different places, with the true state of a job never quite adding up. The system we built for them puts a customer's whole journey on one page, which means anybody in the office can pick up any job without ringing round to find out where it got to. It is a Laravel application, which is what we generally reach for once permissions and scheduled work are part of the requirement.
The other thing you get is a system that does not charge per seat. Once a business is paying for twenty logins on a platform where most people only need to look something up, the arithmetic starts to move. Warehouse staff, fitters and office administrators rarely need a full licence, but they do need to see the job.
The honest cost
A first version is a serious investment, and it is never the last version. Budget for hosting, support and a stream of small improvements, because a system people actually use generates requests. That is a sign of success, but it is a cost.
The failure mode is not technical. It is starting too broad, letting everyone add their favourite field, and ending up with something as unwieldy as what it replaced. Build the smallest thing that removes the worst bottleneck, then extend it once real use has told you what actually matters.
If you want a straight answer on whether your process justifies a build, our custom systems team will tell you when the answer is to buy something off the shelf instead.

