Ask a software vendor whether you should buy their product, and you can guess the answer. Ask a development agency whether you should build, and you can guess that one too. Since we do both, building bespoke systems and implementing the Microsoft platform, we end up giving advice that occasionally costs us work. Here is the test we use.
The question is not the software, it is the process
Start with the process the software will run. Is it something your organisation does the same way as everyone else, or is it something you do differently on purpose?
Payroll, email, document storage, accounting: you gain nothing by being unusual here. Buy the standard tool, adopt its way of working, spend your energy elsewhere. Bending a product into a custom shape, or worse building your own, spends money to make these harder.
But some processes are the reason customers choose you. The way you handle repairs, or productions, or member services, or the shop floor. Forcing those into an off-the-shelf product means sanding off exactly the edges that make you better than the next firm. That is where bespoke earns its keep.
The hidden third option
Most decisions are not a clean buy or build. The platforms you already pay for, Microsoft 365 in particular, contain more than most organisations ever switch on. Sometimes the right answer is configuration: a Power Platform app, a SharePoint process, a Dynamics workflow, built in days on licences you already own.
We check this first because it is the cheapest option to be wrong about. If a configured tool turns out too small, you have lost weeks, not a budget.
The costs people forget
Buying looks cheaper because the price is on a website. Add the licence growth as you add users, the consultancy to make it fit, the workarounds where it does not, and the subscription you will still be paying in year ten. Building looks expensive because the cost arrives upfront. Add the fact that you own it, it fits exactly, and nobody can raise the price or retire the product underneath you.
Neither list settles the argument on its own. What settles it is the first question: is this process generic or is it yours?
A rule of thumb
Buy for the processes where you want to be normal. Build for the processes where being different is the point. Configure what you already own before doing either. And be suspicious of anyone who answers before asking how your business actually works.
If you are weighing a decision like this, we will give you the honest version for your specific case, including when the answer is a product and not us.