Buy vs. Build: Guiding Developers Through the Age-Old Dilemma
Software development has always been about solving problems.
But the variation in HOW we solve the problems can be immense!
Making this more complex is the one particular angle that our friends outside of development love to throw into the mix: "Buy vs. Build."
Should we develop a solution in-house or purchase an existing one off the shelf?
Understanding the Debate
The buy vs. build decision is a simple one in essence: Do you create a solution yourself (build) or leverage an existing one (buy)? While the question may be straightforward, the answer is often intricate and relies on a myriad of factors -- some of which we in engineering aren't as sensitive to.
Competitive Advantage: The Heart of the Matter
A core concept to grasp in this discussion is the idea of competitive advantage. At its most basic, a competitive advantage is something a company can do uniquely well in comparison to its competitors, with a view to delivering better value to customers or outperforming its rivals.
But why should developers care about competitive advantage?
Every line of code written costs time and resources now and in the future. When you're developing something that isn't central to your competitive advantage, you're diverting those resources away from areas where they could be better spent to drive the underlying business forward.
Consider these questions:
Is it Core? Does this component provide a distinctive advantage over competitors?
Is it Common? Is this a component found in most applications and doesn't distinguish our product?
If something is core and not common, it's more likely something you should build. Anything that is generic and doesn't set your product or company apart—like user authentication or payment gateways—usually better to buy.
Factors to Consider: Going Deeper
1. Time to Market
Buying often accelerates your time to market. When you purchase a solution, especially well-established ones, you are essentially leveraging years of development, refinement, and testing that has already taken place.
2. Cost Implications
Building usually has a higher initial AND ongoing cost than buying. However, it's essential to consider the total cost of ownership. With buying, licensing fees, subscription costs, and potential customization needs might add up over time. Weigh this carefully against the people and equipment that must be maintained to support a build decision. A $5/mo monthly fee plus $150k/annual build decision might not balance against a $5k/mo buy decision.
3. Customization & Flexibility
Building provides more customization and flexibility, as you're creating a solution tailored to your exact requirements. However, with this flexibility comes the responsibility of maintenance. Of course, even if you find the exact functionality you're looking for in a buy decision, the lack of control may mean your desired use case shifts out of focus in the external organization forcing you to change providers (or urgently build replacement functionality).
4. Integration with Existing Systems
Off-the-shelf solutions might not integrate seamlessly with your existing infrastructure or tools. Building in-house ensures that the solution fits like a glove with your current systems.
This is a very common defense that tends to work well in conversations with folks outside of technology. Trouble is, while it might win the negotiation, this typically wins low-value low-leverage work for technology that can bogs down the group and may slow down the organization's broader pace of innovation.
Be careful what you wish for.
5. Skill Set & Resources
Does your team have the skills required to build the solution? If not, it might be more cost-effective to buy, rather than invest in training or hiring new talent.
6. Risk Assessment
There's always a potential danger of vendor lock-in, where you become heavily dependent on an external solution that might not evolve as per your future needs or could become expensive down the line. While developing in-house might seem control-centric, there's the lurking risk of accumulating technical debt if not executed properly, which can become costly in terms of future maintenance and scalability.
7. Scalability Considerations
Off-the-shelf solutions might cater to your current scale but might not adapt well when you expand or evolve, leading to potential inefficiencies.
That said, constructing a bespoke solution allows you to keep scalability (and the other -ilities) in mind from the start, ensuring that the software grows with your business needs. However, unforeseen growth can sometimes challenge even the best in-house designs.
8. Support & Documentation
A significant benefit is the availability of dedicated support teams and comprehensive documentation. Yet, the quality can vary, and relying on external support can sometimes introduce delays. But, an in-house solution gives you the onus of documenting the process and training developers. While this ensures tailored support and documentation, it requires regular updates and a dedicated onboarding process for new team members.
In Conclusion: A Balancing Act
The buy vs. build debate is not about finding a one-size-fits-all answer, but about understanding the nuances of your situation. For developers, it's about aligning technical capabilities with business strategy. We need to be wary of our biases.
The ultimate goal is not just to solve a problem, but to solve it in a way that positions us and the company for success.
