Most businesses ask this question the wrong way round. They compare the price of a packaged system against a quote for a custom build, pick the cheaper number, and discover eighteen months later that the number they compared was not the cost.
Start with the workaround, not the licence
The question that matters is not what the software costs. It is what you are already paying to work around the software you have.
That cost is almost always invisible because nobody invoices for it. It looks like two people re-keying orders from one system into another. It looks like a spreadsheet that one person maintains and nobody else understands. It looks like a monthly report that takes a day and a half to assemble. None of that appears in a budget line, and all of it compounds as you grow.
Put a number on it before you compare anything. Hours per week, multiplied by the loaded cost of the people doing it, multiplied by fifty. That figure is what you are comparing against, and it is usually larger than people expect.
When off-the-shelf genuinely wins
Buy when your process is close to standard, and be honest about whether it is.
Accounting is standard. Payroll is mostly standard within a jurisdiction. Email marketing is standard. In these areas a packaged product carries years of other people's edge cases, compliance updates and bug fixes that you get for free, and no custom build will ever catch up. If you are describing a requirement and a salesperson can demo it in ten minutes, you should probably buy it.
We tell clients this regularly, including when it means we do not get the project. A business running a standard process on custom software has bought itself a permanent maintenance obligation for no advantage.
When building is the cheaper answer
Build when the difference is the point.
If the way you handle pricing, or scheduling, or quality control is part of why customers choose you, forcing that into a packaged system does not save money. It erodes the thing you compete on, and it usually generates exactly the manual workaround described above.
Build also wins on a simple arithmetic case that people miss: per-user licensing against a growing headcount. A system at a few hundred rupees or dollars per user per month is cheap at ten users and a significant annual cost at a hundred and fifty. If you can see that growth coming, do the five-year sum rather than the first-year one.
The option most people skip
There is a third answer, and it is the right one more often than either of the other two: keep the packaged system and build only the part that does not fit.
Most business software exposes an API. The integration or the one custom module is a fraction of a full build, carries a fraction of the risk, and leaves you on a supported product for everything that is genuinely standard. We do a lot of this work, and it is usually the recommendation when a client arrives convinced they need a full replacement.
A question worth asking any developer
Ask whoever is quoting you what they would advise if you did not hire them.
If the answer is always "build it", you are talking to someone whose incentive is not aligned with yours. A good technical partner should be willing to lose a project by telling you the software you need already exists.