Build versus buy is usually presented as a cost question. It is more useful as a control question: how much does it matter that you decide what this software does next?
Start with what the software is
Divide the systems in your organisation into two piles. In the first go the things every business of your type has to do, where being different offers no advantage: filing accounts, running payroll, storing files, sending email. In the second go the things that are actually how your business works.
The first pile should usually be bought. The second pile is where the conversation is worth having, and it is often smaller than people expect because only the systems that shape how the organisation competes or operates belong there.
The costs both sides leave out
Missing from the buy case
- Staff time spent on workarounds, which is a real recurring cost and rarely counted
- Licence growth as headcount or volume increases
- Integration work to make the product talk to everything else
- The features you will not get, and what not having them costs each year
- Migration cost if you ever need to leave
Missing from the build case
- Maintenance, which is ongoing and non-negotiable
- The compliance and security work a vendor would have absorbed
- Key-person risk if only one person understands it
- The internal time required to specify it properly, which is substantial
- The second version, because the first is never the last
Combining bought and custom software
Buy the platform, build the difference. A commercial product handling the commodity work, with a bespoke layer doing the part that is specific to you, is very often better than either extreme and rarely appears on the shortlist.
This is what most of our integration work is. The organisation keeps the systems that work, and we build the connections and the missing piece that makes them behave as one thing.
When to revisit the decision
Building too early is the classic failure. You commit to a shape before you understand the problem, and end up maintaining an expensive answer to the wrong question. Buying first, living with the friction, and learning precisely where the product does not fit is usually the cheaper route to a good bespoke specification.
Building too late has a quieter cost. By then the workarounds are institutional, several people’s jobs are defined by them, and the migration is harder than it would have been two years earlier.
How dependent is the business on the product?
If the vendor announced tomorrow that they were discontinuing the product, would that be an inconvenience or an emergency?
If it is an inconvenience, keep buying. If it is an emergency, you have already established that this system is core to how the business operates, and the conversation about owning it is worth having properly.