When a kind of software isn’t available, it makes sense to build it. If it is available to buy, everyone says you should buy it. But in a surprising number of cases, building makes sense even when you can buy software.
Here's an example of a company that wasn't in the software development business decided to build what they needed, and grew an amazing business from there.
There was a little bank in Georgia that somehow got the ambition to process credit cards for their customers when that was a new thing. There was no software available to buy, so they built some primitive software. It worked well enough. Then they improved the software and sold some local banks on processing credit cards for them (not necessarily in that order). One thing led to another, and the software evolved into the second-largest credit card processing company in the US, TSYS. Particularly when software categories are new, that’s what people do – they build software.
As the software becomes available, it starts to make sense to buy it. There are always issues at the beginning (see this about developing functionality on a new platform) about the time and effort to make the software work for you, and whether it has all the features you need. Sooner or later, the surviving vendors reduce the pain of customization and implementation, and develop a rich enough set of functionality so that the needs of nearly everyone in a business segment are met. At some point on that spectrum, it becomes kind of nuts to build it when you could buy it. It might take you years to build what you need, and then you’ll have to support it, and you’ll always be behind your competitors who are using off-the-shelf software, not to mention the risk that the software you try to build doesn’t end up working or really meeting your needs. So the mantra in the corporate offices becomes “buy, buy!” And only if you really can’t buy it should you build it; and even then, you should look real hard for excuses to put it off. If nothing else, there is less risk associated with buying software, and corporate managers nearly always vote for the least-risky of alternatives.
However, as these products have been getting built, tools and components for building software have also been advancing, and the ability to make your software systems adapt to changing business conditions has becoming increasingly important as a business advantage. Meanwhile, the major products in any category tend to get bloated, as pressures from various customer groups result in feature after feature being added to the product. In the early days of a product, you are most concerned that the features you need are in the product; as the product ages, the concern shifts to the burden on the software and users from the vast majority of the features in the product that someone may need, but not you. It may be that you only need a tiny fraction of the available features. An example of this that is close to home for many people is the Microsoft Office products – who even knows what most of the menu items in Word mean, much less uses them?
The case against purchased products gets stronger when you need several of them, and they all have to work together. Then you have the problem of application integration, which is typically compounded by different release and upgrade schedules from the vendors, who, try as they might, don’t seem to be able to release a new version without screwing something up that worked in the older version. If, on top of it all, you have an ambitious and low-cost programming group at your disposal, then you’re a good candidate for the final stage in this evolution, which is, “OK, I bought it and I’m using it, now when do I get to turn it off?” “Programming” shops whose main purpose in life is baby-sitting purchased products can’t even imagine doing something like this, which is probably just as well, because they are highly unlikely to pull it off. But groups who are itching to write code, and do stealth projects to prove what they can do, are another matter.
So the evolution returns to the starting point, only typically at a much more advanced level, with more advanced tools and a knowledgeable view of the business and the required functionality. “Why pay the vendors their ransom and put up with the crap they dish out, when I can write it, own it, change it any time I need to, and control my own destiny?” If the numbers work out, why not, indeed?