A development company recommending custom software is not a neutral opinion, so it is worth stating the test we actually apply. Buy when your process is genuinely standard. Build when the process is how you compete, or when no available product fits without changing how your business works.
Accounting is the clearest example of buy. Your ledger is not a competitive advantage, the requirements are well understood, and mature products exist at a fraction of what a build would cost. The same is usually true of email, payroll, and document storage. Building any of these is spending money to arrive at where you could have started.
The argument flips when a product would force you to change something that is working. We have seen businesses reorganise a functioning warehouse process to match imported software, then spend the following year working around the mismatch. If adopting a product means rewriting how you actually operate, the licence fee is not the real cost.
The third answer is the one people forget: do nothing yet. Some problems are process problems wearing a software costume. If a task is painful because responsibilities are unclear, no system will fix it — automating an unclear process just produces confusion faster. We have told clients this and lost the project, which is the correct outcome when it is true.