You’ve already asked yourself this question a dozen times. Build a house or buy an existing? Build a raised garden bed or buy a kit? Print your own vacation t-shirts, or order them online?
For someone with just enough development skill to be dangerous, the question is often the same. Should I build or buy?
The Question Remains Valid
There are times that you should build and times that you should buy. Let’s examine the pros of each. We won’t address the cons, because I have no desire to even accidentally insult your intelligence and we all know the downside of each option: cost. Since cost is the downside to both, they cancel each other out.
Benefits of Buying
When it comes to buying, you get a great ability to be more care free. If the product of service you’re acquiring breaks or has a minor bug, you’re not responsible. In fact, many corporate-level purchasing agreements have indemnity against such issues, but not nearly all so check your contracts accordingly.
For me, the difference between having to clear my schedule to fix anything that isn’t working, to roll out a new expected standard, or to address minor maintenance issues is a big deal. This is especially true since I often operate as a one-person shop still and can’t afford to spend a lot of time in maintenance or repair mode.
Another benefit of buying is that you know the playing field is more level than if you build. When you buy, you’re likely buying from a company that is keeping tabs on the competition and working to stay competitive even if they’re positioned slightly differently. Because of this, the playing field is much more even across your own industry or sector in the deployment of technology. While this sounds like a bad thing–because you want to have an advantage–it’s actually a great benefit as you can spend more of your development efforts on value-add activities to plus the baseline features.
Benefits of Building
Why build? Well, I place this answer second because it’s much more direct and intuitive. When you build, you get exactly what you want, as long as you’re willing to put enough time, money, and effort into it. Sure, this runs the risk of offsetting the obvious cost benefit gained from building instead of buying, but I’d like to use this time to challenge that assumption anyway.
Let’s say you build a product or service yourself. Sure, the direct capital involved may be much lower than the direct costs you take on from acquiring the solution from a market leader, but… what about the indirect costs. How many people did you have to divert, for how many hours, from their core work focus in order to create this new thing? Companies strangely forget to calculate such things in many situations (I know, you’d think we’d be past this!) because they already associate their labor costs as being set (at least as it relates to this) because the employee is already retained for another task.
But what about the time that’s diverted? Couldn’t it go into the employee further automating or otherwise improving their direct area of focus to get more and more gains (or efficiencies) in that area?
But again, I come full circle… when you build, you can custom tailor exactly what you want as long as you have the follow-through and technical ability to complete the project.
How to Solve
Start with a default position of “buy”. Then build when you outgrow available solutions or have a strong justification for something custom.
Starting with a buy-default position may not sound like the type of advice you’d expect from me, but I can’t stress enough how much a build-default position destroys resources. Even the businesses you think of as building are on a buy-default position.
Amazon may have the time and energy to create a lot of their own tooling, but they’re not out manufacturing conveyor belts, delivery trucks, and computer systems… at least not until every other way to maximize the distribution channel has been exhausted. They use leading B2B warehousing equipment, Mercedes trucks, and tons of third party computing equipment.
Ford doesn’t make its own bolts. Coke doesn’t roll its own aluminum. Automattic (WordPress) doesn’t author Integrated Development Environments. NASA doesn’t even launch all of its own missions anymore. And, if I ever become wrong on any of these issues, it’s because other opportunities have become exhausted and vertical innovation is required.
Personal Considerations
As for me, I’ve spent over two decades trying to justify a build-default approach.
I surrender to the truth: buy-default is virtually always the best foundation.
