Build vs. Buy — Costs and Quality
The classic build vs. buy decision for commodity software in the enterprise is often posed as a case where you take the negotiated cost (or better, the total cost of ownership, or TCO) of vendor software and the cost of in-house engineering, apply a bit of fifth-grade math, and obtain a binary build-buy answer. But as with most things in life as well as in software engineering, it’s not really that simple.
Case Study: A Chicken Sandwich
Who doesn’t like a chicken sandwich? I’d go so far as to say that eating a chicken sandwich is at least a weekly occurrence for a lot of people. So they may find themselves confronting the question of whether to “build” (cook at home) or buy their chicken sandwich. What’s the right decision here? Let’s walk through my possible thought process.
Build?
I can cook a pretty good chicken sandwich. And I can walk to the grocery store (or take the SUV for those of you in the U.S.), buy some raw materials, and calculate exactly what it costs me to do so, modulo using or amortizing some leftover ingredients. Then I could total those up to determine what it costs me to obtain my lunch. You can do this for all kinds of different meals, but spoiler alert: It’s almost always cheaper to cook at home — “build” — across a wide variety of dishes.
There’s also a sense of personal satisfaction that comes from cooking at home. You get to try new things, experiment, and perfect your chicken sandwich craft. Given the choice, in-house IT engineers will always choose to build. Like cooking, software engineering is a craft, and that reward that comes with seeing a system you build come together is why most engineers got into software in the first place.
Buy?
But there are a few flaws in jumping to the conclusion that you should almost always build. After all, without those flaws, restaurants might not exist.
The first flaw is time. I could buy a chicken sandwich or even get it delivered (delivery fees and tips blissfully not being a huge incremental cost here in Taiwan) for faster than I can make one myself. Time is valuable — please value it if you aren’t already. And more to the point, in business, time is money. When choosing to ”build”, money is not only spent on engineering resources, but also in opportunity costs. Why pay in-house IT engineers to build yet another HR system when you can buy that (or more likely these days, subscribe to some SaaS) and have your engineers work on the core business — the things people actually PAY you for?
The second pitfall in my chicken sandwich build vs. buy logic, and the most often overlooked or written off, is quality and functionality. Although I’d like to think my home-cooked chicken sandwich is pretty good, nobody is going to line up around the block for it Chick-Fil-A-style. There is something to be said for eating better food — or having your employees use better software.
Those food artists at Chick-Fil-A have literally spent years doing absolutely nothing but perfecting their chicken sandwich, and naturally the result is pretty tasty. I’ve spent at most hours in my entire life working on my chicken sandwich recipe, and how can my product compete with the chicken sandwich domain experts?
Another thing that the Chick-Fil-A sandwich has going for it is reliability. Every sandwich you order from Chick-Fil-A, you can count on it tasting just like every other one you’ve ever ordered. Not many cooks can achieve that kind of consistency in quality.
In Practice
In enterprise software and IT, even if you have a large number of freakishly inexpensive and/or fast engineers, if you set them off on almost any non-line-of-business software project, they will never be able to produce as high-quality and high-functionality a product as a dedicated vendor and get it into your users’. hands in a timely way. Your in-house engineers are either generalists or specialists in your business domain. But when you purchase or subscribe to a vendor’s software product, that’s the vendor’s line of business, and they live and breathe their product and domain. Your engineers can’t match up, and your business and your users will notice the difference.
To be fair, when going with a vendor solution, you are typically paying a premium for the immediate satisfaction of a high-quality, highly functional system. Understanding that balance between time efficiency and financial investment is the crux of the build vs. buy decision.
Open-Source Software To The Rescue?
There’s a possible way out of the build vs. buy dilemma when it comes to costs and quality in the form of open-source software. Maybe your in-house engineering team can download some open-source system, make a few customizations, and hook it into your existing IT system and achieve a high-quality result with money and time to spare. I suppose in the chicken sandwich example, this would be analogous to purchasing a huge bag of frozen pre-cooked chicken breasts at Costco.
There are a lot of problems with thinking of open source as a compromise solution for build vs. buy, not the least of which is that most non-infrastructure-layer (and a lot of infrastructure-layer as well) OSS really just isn’t very good, with a total cost of ownership that ends up rivaling a vendor package. And much OSS that does break through and get good these days gets commercialized behind some sort of “freemium” or “open-core” model, and those can be incredibly frustrating to engineer around and integrate.
Resolution
If the straightforward and classic build vs. buy calculation for software products is too simplistic and doesn’t account for all the factors of time, quality, and functionality, how should we proceed? I would suggest that we need to use better cost models — beyond what’s usually considered part of TCO — that include things like:
Time-to-benefit from a new system.
Opportunity cost for business and engineering.
Cost-of-quality (such as bugs from in-house vs. vendor software).
In the landscape of software decisions, the build vs. buy dilemma demands a nuanced approach. As you navigate through the intricacies of time, quality, and functionality, share your experiences with us. What challenges have you faced in deciding whether to build or buy? Join the conversation and let's explore the diverse perspectives that shape this crucial decision in the realm of enterprise software.
