My colleague Erik Doernenburg has written a couple of articles recently discussing the reasons why people buy and build IT solutions and one part in particular resonated with me:

I feel like there’s a mindset change once you start thinking which package you could buy to solve your problem whereby you stop solving the problem you actually have and focus instead on what features the package offers.

Package software almost by definition tends to be written for a generic case of a problem and as Erik points out might not solve the problem that a business has. In addition it will probably solve problems which they don’t have.

This leads to a tendency to believe that the alternative to buying a package is to match that package feature for feature with a custom built solution.

If you look at things from that perspective it’s easy to see why buying would be preferred since the build approach is going to cost at least as much and you’d have to wait for it to be built as opposed to having it straight away.

However, when you start from the mindset of solving the problem in front of you - which is the mindset that building something leads you towards - then you may actually find that you can get away with a much simpler implementation than previously seemed possible.

By making use of prioritised iterative delivery we can then ensure that the most important/highest priority features are built first and if at any stage it doesn’t make sense to build the next feature you can stop.

I’m curious whether there’s some middle ground where you could still drive your solution from the problem and then pick and choose buy/build wherever it made sense.

We do actually take a variation of that approach in most applications I’ve worked on where we make use of open source libraries rather than writing everything from scratch.

In order for that approach to work with package software the package would need to be written more as a library that solves a specific problem rather than a framework which you need to use to solve every possible problem you have.

I don’t really have a good conclusion to this but Erik covers this point and more in his two posts so go and read those if you find it interesting!