The false binary
Most ERP buying decisions are made under a false binary: SAP-shaped on one side, custom-from-scratch on the other. Both options are expensive, both take a year, and the comparison sheet that decides between them usually has forty rows of features and none about the business.
The actual question is narrower. Which two or three workflows give your business its margin, and would owning them in software make those workflows faster, cheaper, or harder for a competitor to copy? If the answer is no, an off-the-shelf product wins on every dimension: price, delivery, documentation, the pool of people who already know it. If the answer is yes, anything you do not own in those workflows becomes a tax on the rest of your operations, paid every day in workarounds.
A filter you can run this afternoon
Count the screens your operations team has to move between to close a typical case: a sale, a file, a session, an order. Below four, you do not have an ERP problem; you have a training or a discipline problem, and software will not fix it. Above eight, you probably do have one, and the symptoms will already be visible: private spreadsheets next to the official tool, a person whose job title is really 'the one who knows where things are', and a monthly close that takes a week.
Then look at the spreadsheets themselves. A spreadsheet that survives next to an ERP is a specification: it holds the fields, the rules and the exceptions the tool could not express. Read three of them and you have the first draft of what custom would need to model.
What custom actually means
Custom does not mean rebuilding accounting, payroll or invoicing. Those are commodities, they are regulated, and the market does them better than any single company will. It means owning the two or three workflows that are yours, the ones where your way of working is the product, and connecting them to commodity tools for everything else.
That is what we built for Actinuum, a vocational-training group: the sessions, the trainers, the learners and the paperwork that follows each of them were the business; invoicing was not. The custom part covered the loop; the rest was integration. Revenue tripled inside two years without a hiring cycle, because the volume that could pass through the same team went up, not because the team did different work.
When to say no
Say no to custom when the workflow you want to own is one the whole sector shares: the regulator, the funder or the standard already decides its shape, and a vendor has encoded it for hundreds of clients. Say no when the person who knows the workflow cannot spend two hours a week with the team building it. And say no when the budget only covers the build: a custom system that nobody maintains is a spreadsheet with a login page.
Say yes when you can name the workflow, name the person, and name what would be different in a year. Then start with that one workflow, not with the platform.