A software company writing about whether you need custom software has an obvious conflict of interest, so let us start where the conflict is sharpest: most organisations asking this question should buy something off the shelf. Existing products have absorbed thousands of hours of development, have been tested by thousands of users, and are available on Thursday.

That said, the cases where building is right are real, recognisable, and expensive to get wrong in either direction. Here is how to tell them apart.

Buy when the process is not your advantage

Accounting, payroll, email, CRM, helpdesk, project tracking — these are solved problems where your requirements are, whether you like it or not, ordinary. A packaged product will do more than you need for less than a build would cost, and somebody else maintains it.

The test is whether the way you do this thing is a competitive advantage. If your invoicing is unusual, that is usually a habit rather than an edge, and adapting to the product is cheaper than encoding the habit in software you will then maintain forever.

Build when the process is your advantage

The clearest case for custom software is a process that is central to how you make money and genuinely different from how others do it. Off-the-shelf products encode the average way of working; if your value is in not being average, the product will fight you.

This is why bespoke systems cluster in operations, logistics, pricing, scheduling and anything customer-facing that differentiates the offer. Nobody builds their own accounting package. Plenty of companies build the system that decides what to make and when.

The four situations that decide it in practice

  • Nothing on the market fits, and you have checked properly. Not "we looked at two and did not like them" — an actual evaluation of the serious options against a written list of requirements.
  • The product fits, but only after heavy customisation. Deep configuration of a packaged system regularly costs more than a focused custom build and leaves you unable to upgrade. When the quote for customisation approaches the quote for building, the calculation has changed.
  • Integration is the requirement. If the real job is making six existing systems work as one, no vendor sells that. Custom integration is often a much smaller project than replacing anything.
  • The licence maths has turned. Per-seat pricing that was sensible at twenty users can be indefensible at four hundred, and at that point a build with a fixed cost and no per-seat fee starts to pay back within a couple of years.

What building actually commits you to

You are not buying an artefact; you are taking on a responsibility. The system will need maintenance, the dependencies will need updating, and somebody must own it after the people who built it move on.

That is manageable and entirely normal, but it should be a decision rather than a surprise. Budget for support, insist on documentation and a proper handover, and keep the source code and the infrastructure in your own accounts rather than your supplier's.

The corresponding risk on the other side is worth naming too: a packaged product can be discontinued, repriced, or acquired by someone with different plans, and you have no recourse. Neither option is risk-free; they are different risks.

The middle path most projects end up on

The best answer is frequently both. Buy the commodity systems — accounting, mail, CRM — and build the thin layer that connects them and encodes the part that is yours.

These integration projects are the most reliably profitable software work we do, precisely because they are small. They do not replace anything, they remove the manual re-entry between systems that already work, and they can be delivered in weeks rather than quarters.

A short decision procedure

Write down what the system must do, in a page, in your own words. Evaluate the two or three most credible products against it honestly, including the cost of configuring them and the cost of the compromises. Then ask what it would cost to build only the part none of them do.

If the answer is "most of it", buy. If the answer is "a small part, and that part is where our money is made", build that part and buy the rest. Projects go wrong when this question is answered by preference rather than by comparison.