The question is rarely "do I need an ERP?". In most companies that have been operating for a few years, some management system already exists. The problem is that it stopped keeping up with the business. Spotting that moment precisely avoids two common mistakes: switching systems too early (burning time and money on an unnecessary migration) or too late (piling up manual processes that should have been automated two years ago).
The signs that actually matter
The first sign isn't "the system looks outdated": it's operational. When a meaningful part of your critical process (finance, inventory, production, support) already lives outside the main system, in parallel spreadsheets, you're already paying the cost of an incomplete ERP. Every parallel spreadsheet is a point of failure: nobody guarantees it's in sync with reality, and every manual update is a chance for error.
The second sign is the customization ceiling. Every off-the-shelf platform has a limit to how far it can be personalized. Past a certain point, adapting the system to your real process becomes a reverse-engineering project, expensive and slow, trying to make generic software pretend it's yours. If your IT team (in-house or outsourced) already spends more time working around the system than using it, that ceiling has been hit.
The third sign is the cost model. Off-the-shelf ERPs often charge per user or per module. That means growing your team or expanding your operation increases licensing cost linearly, sometimes faster than the revenue that growth generates. A custom-built system flips that equation: the investment goes into development, not into a recurring fee that scales with headcount.
Customize, switch, or build custom?
Not every company in this situation needs an ERP built from scratch. Customizing an existing platform makes sense when the business process is relatively standard and the pain is concentrated in a few specific points. Switching platforms makes sense when the problem is the tool itself, not the model: a more modern platform, with a better API and more flexibility, solves it.
Building custom makes sense when the business process itself is the company's competitive edge, when "doing it the way only we do it" is exactly what generates results. In those cases, forcing that process into generic software usually means giving up part of what makes the operation efficient, just to fit the software.
The diagnostic before the decision
Before deciding which path to take, it's worth mapping three things clearly: which processes currently live outside the main system and why, how much team time is spent on manual tasks that could be automated, and what the cost (in licensing and in customization) would be to stay on the current model for the next three years, not just the next six months.
That diagnostic, done rigorously, usually points to the answer more clearly than any feature comparison between platforms.