One very common question that you run into when building enterprise software is customers who ask: why should we buy this stuff at all? Can’t we just build it ourselves?
The build-versus-buy debate is remarkably common. Companies of all sizes wrestle with it, albeit in different ways, in almost every industry when they start adopting new software tools into their operations. Obviously, there is no blanket rule that can apply to everyone’s situation. But after being directly involved in a bunch of these discussions, across a couple of different software markets, I thought I would write down some things that I wish decisionmakers looking at this issue understood better.
First of all, putting my cards on the table: my tech career has wholly been with software vendors, and this surely colors my perspective. Indeed, more often than not, I do believe it makes more sense to buy off-the-shelf software rather than build in-house. But it’s important to explain why. We run into the same questions, objections and arguments over and over, and I’ve seen remarkably little written publicly about them.
At a high level, the decision about whether to buy or custom-build usually comes down to a cost analysis that involves a lot of wishful thinking, guesstimates and stakeholder promises that are hard to keep. Almost every in-house software development project has the same goal: to ultimately save the company money in the long run by investing a lot of time (and thus money) up-front to build something. “We’ll spend three/six months on this,” says Bill from IT, “and then we can run it for free in perpetuity!”
Spoiler alert: this dream almost never materializes, and most people who have built enterprise-grade software immediately know why. It’s because while it’s one thing to build a working prototype of a product, it is quite another to make it work with high availability for lots of users, indefinitely. As an example, there are many dozens of “build a Twitter/Slack clone” coding tutorials on the internet. Any of them can teach you to build something that looks and acts like Twitter/Slack; but of course, the program you code in an hour and these massively available software infrastructures are not even remotely comparable.
The opportunity and other hidden costs of software development are rarely present in these kinds of cost calculations. Assuming that in-house estimates for building X in the first place are correct (which is a big assumption), predicting support needed for upkeep, upgrades, new features and security are really only knowable by doing it. The further out those predictions go, of course, the less reliable they become. Headcount and person-hours necessary for development and support is often a total guess unless you’re working in an organization that has done this sort of work before; and once that headcount cost structure has been established, it becomes something of a sunk-cost assumption for company leaders. I’ve seen this result in a self-defeating spiral into which a company convinces itself it doesn’t really need vendors for anything. Good luck with that.
Security is related to this, but really deserves its own separate treatment. Software security is one of the top concerns of any meaningful company today. It’s one of the big reasons so many companies are moving their critical systems to SaaS vendors – we’re more secure. Software vendors are directly and heavily incentivized to invest in high security. Building and maintaining high-quality software is literally all we’re paid to do, and software companies are able to attract and invest in the best talent and infrastructure systems available to do this. Generally speaking, retailers, airlines, banks and other non-software firms are not. Building software is just not what these companies do – it’s something they typically invest in only insofar as it allows them to do the thing that keeps them in business. The cost of software needs tends to scale non-linearly, meaning that beyond a certain point, it’s hard for any one company (especially a non-MegaCo) to justify the additional spend necessary for top-of-the-line systems. SaaS vendors can and do, because we rely on those systems to make our software scale.
For all of these reasons, I think it almost never makes sense for small-ish companies to “roll their own” software tools. Indeed, the only such companies who I routinely see go for custom development over buying off-the-shelf tend to be VC-backed startups, particularly those serving the “tech” field (broadly writ). I think there are two reasons for this. These companies tend to be filled with people who know how to build technology, so they are immediately attracted to the idea of doing that instead of buying someone else’s. There is often a level of cultural resistance to buying off-the-shelf, too, in lieu of doing everything in-house. They also, frankly, have someone else’s money to burn on custom development.
At big companies, many of these reasons hold as well. Bigger firms tend to have larger dedicated IT/software teams that have long maintained (or even built) legacy systems. Many of those older systems are quickly being made obsolete, or worse, dangerously insecure. Leaders of those companies often find it tempting to kick the can down the road, but after the series of giant data breaches (and resulting lawsuits) in the last few years, we’re seeing increased demand for replacing them. (I touched on this in Enterprise Software and the Deployment Age.) The VC community loudly pleads with industry to start spending on M&A to solve this problem, but I think that’s misdiagnosing the problem (in a particularly self-serving way). I don’t see most companies becoming “tech companies” – rather, I see them relying on tech vendors to solve non-core problems for them.
The big exception to all of this is when it comes to fundamental, “transformational” organizational change. There are, sometimes, companies that decide they need to dramatically change something core to how their business operates and what markets they serve. I wrote about Adobe doing this before, and the point is that these situations are exceedingly rare. Yet this is one lens through which Walmart’s acquisition of Jet should be understood. I think it’s entirely plausible for Jet to grow into a big, if distinctly second-tier, competitor for Amazon, but it remains to be seen if Walmart will make that growth possible within the Walmart universe.
Ultimately, great software is like anything else. You can have it done cheap, fast or well, but you can only pick two. I rarely see companies that invest in good software wind up regretting it.
Related Posts:
[mc4wp_form id=”185″]
Blair Reeves 