Most businesses should not start by commissioning a new system. They should start by knowing how they work. If that is still unclear, a website, an ERP, or any other build will only freeze the confusion in place.
The useful question is narrower: is the way this company operates different enough, and valuable enough, that a generic product will keep forcing the business to adapt?
A custom system rewards clarity. It cannot invent the thinking.
Signals that a generic tool will not hold
The process has exceptions that are not rare — they are the work. Revenue depends on a sequence the packaged CRM cannot represent without extra ceremony. Several teams share a workflow, and each tool only sees a slice. People maintain a parallel system because the official one does not match.
Those are not 'nice to have' customisations. They are the shape of the business. Forcing them into a standard product is a cost paid every day in time, error, and quiet workarounds.
When not to build
If a well-chosen product covers the process with little distortion, buy it. If the company cannot describe the process without arguing, do not put it in software yet.
Build when the system must follow the business — and when the cost of not doing so is already visible in the way people work.
What 'custom' is not
It is not a personality. It is not a preference for writing software. It is not a refusal to buy anything. Custom is the decision that how the company works is worth building around: the way this company sells, decides, and finishes work is valuable enough to be held on purpose.
If that is true, the brief is already there. It is usually sitting in a spreadsheet, a chat thread, or the head of the person everyone asks.
A useful first conversation is therefore not 'what software do you want'. It is: show us the unofficial process. If that process is valuable, and a generic product keeps taxing it, a custom system is in play. If not, buying the closer product — or waiting until the path is clear — is the better work.