Build or buy: a more useful question
The choice is rarely between a product and a custom system. It is between which parts of your process you are willing to change, and which parts are the reason customers come to you.
Most organisations frame the decision as a budget question: a subscription is cheap, custom development is expensive. That framing hides the actual trade-off, which is about process ownership.
What a product asks of you
An off-the-shelf product encodes someone else’s idea of how the work should be done. That is usually a good thing — it is the accumulated experience of hundreds of organisations, and adopting it can be an upgrade. Accounting, payroll, email and calendars are solved problems, and building your own is almost always a mistake.
The difficulty starts when the product covers eighty per cent of a process and the remaining twenty per cent is the part that makes your organisation distinctive. That is where the workarounds appear: an export to a spreadsheet, a naming convention people are asked to remember, a status field used for something it was not designed for.
A better question
Instead of “build or buy”, ask: which parts of this process are we willing to change to match a product, and which parts are the reason clients choose us?
The parts you are willing to change should be bought. The parts that are your actual value should usually be built — not because custom software is superior, but because those parts are unlikely to have been productised, and because bending them to fit a product slowly erodes what made them work.
The maintenance question nobody asks early
Custom software has a real cost that arrives after launch. Before deciding to build, it is worth asking who will maintain the system in three years, whether the technology choice is boring enough to still be supportable, and whether the documentation would let another developer take over. If those answers are uncomfortable, that is an argument for a smaller custom system rather than no custom system.
A pragmatic middle
In practice the useful answer is often both: buy the commodity systems, build the part that is genuinely yours, and integrate them. That requires being honest about which is which — which is exactly the conversation the budget framing avoids.