The build-versus-buy conversation usually starts with two numbers: what a product licence costs annually, and what a custom build would cost once. Whichever number is smaller wins. This is a comfortable way to make the decision and a poor one, because it compares a recurring cost to a one-time cost and ignores most of what actually gets spent.
What the licence quote leaves out
A licence figure is the beginning of the commitment, not the whole of it. Implementation typically costs one to three times the first year licence. Customisation to fit your process adds more, and in the products where customisation is easiest, it is also where the cost grows fastest. Integration with your existing systems is rarely included. Per-seat pricing means the cost grows as you grow, which is precisely when you can least tolerate a surprise.
There is also the cost of process change. Buying a product means adapting how you work to how the product assumes you work. Sometimes that adaptation is an improvement. Often it is a tax paid by every employee every day, and it never appears on any quotation.
What the build quote leaves out
Custom development quotes are equally incomplete, usually in the other direction. The build figure covers getting to launch. It rarely covers the ongoing costs that follow: security patching, dependency updates, platform changes, hosting, monitoring, and the enhancement work that any system in active use will require.
A reasonable planning figure is fifteen to twenty five percent of the original build cost per year for maintenance and evolution. A build quoted at forty lakh should be modelled with six to ten lakh of annual running cost. Anyone who tells you a custom system needs no ongoing investment is either inexperienced or selling.
The comparison that is actually useful
Model both options over five years, including implementation, customisation, integration, training, hosting, support, and the growth in users you actually expect. Then add the one factor most models omit: the cost of being wrong.
If you buy and the product turns out to be a poor fit, your options are limited and expensive. If you build and the requirement changes, you change the software. That optionality has real value, and it is worth the most in exactly the domains where your process is unusual.
A reasonable default
Buy for anything that is not a source of competitive advantage. Accounting, payroll, email, helpdesk: these are solved problems and a good product will beat a custom build comfortably.
Build where your process is genuinely different from your competitors, where that difference is why customers choose you, or where per-seat licensing at your projected scale becomes punitive. In practice this points at the operational core of the business and away from everything supporting it.
The honest answer for most organisations is a mix, and the useful work is deciding which systems fall on which side.