Navigating Build vs Buy Decisions in Software Engineering
Written on
Chapter 1: Understanding Software Engineering's Challenges
Once you accumulate around five years of experience in software engineering, the field reveals itself to be much more than mere coding. Coding serves as a craftsman's hammer—an essential tool for addressing various challenges. As a software engineer with over fifteen years of experience, and a decade spent in professional environments, I still find joy in coding. However, it represents just one aspect of software engineering.
After roughly four years, I recognized that diving into coding is often one of the final steps in addressing a software engineering challenge or developing a product. Importantly, I differentiate between these two concepts, which is a crucial lesson for every programmer. Often, they are not synonymous. This perspective has granted me greater clarity, improved cost-benefit analysis, and a less stressful professional life.
The Software Engineering Dilemma
To me, software engineering problems are those that lack direct relevance to the product's end-user. These issues usually spark intense discussions among engineers—debates over whether to adopt a functional programming approach versus object-oriented, or which front-end framework to utilize: React, Angular, or Vue? Questions also arise about the extent of reliance on automated testing versus manual methods, and whether utilizing Cypress testing still warrants writing tests with the React Testing Library. Additionally, should we leverage AWS's full capabilities, including Amplify, or merely use its infrastructure for our needs?
These inquiries, along with others about team dynamics, Agile methodologies, and fostering transferable skills within an organization while creating testable products, comprise the complex landscape of software engineering challenges. While some are straightforward, others prove more difficult than writing the actual software. What ties them all together is that many small to medium-sized tech firms often unconsciously lean towards the buy versus build dilemma.
The Concept of Buy vs Build
The buy versus build question is straightforward: Should you opt for an off-the-shelf solution or develop one from the ground up? Despite the allure of creating something entirely new, this has not been the reality for quite some time. In both web and native development, we frequently depend on solutions crafted by others. Open-source software and MIT-licensed products are ubiquitous, embedded in our daily applications. Most contemporary software engineers seldom create anything entirely from scratch. Even I observe that fewer individuals are well-versed in just vanilla JavaScript or the DOM API. My intention is not to debate the merits of this trend, but rather to highlight that even when we claim to build from “scratch,” we essentially “buy” (even if at no monetary cost) software solutions that we then tailor to our specific needs.
Even free software solutions come with hidden costs related to adoption, buy-in, and knowledge fragmentation.
The Product Dilemma
Interestingly, the instinct to utilize off-the-shelf engineering solutions often diminishes when we shift the conversation to product development. Engineers frequently feel compelled to create custom solutions. This inclination is understandable; many take pride in engineering unique solutions to product challenges. However, this can lead to significant issues, potentially draining both talent and resources to the point of jeopardizing the organization or even the company.
When we focus on solving product challenges with engineering solutions, we may lose sight of our ultimate aim—business success. A modern application consists of numerous components, including user management, payment systems, security, gated features, onboarding, and support, among others. Software engineers often feel the urge to construct these elements from scratch instead of integrating existing solutions that others have already developed. This inclination is fueled by a mix of ego and the genuine excitement of coding, yet from a product and business perspective, the original goal was never just to write code.
The Fundamental Question
This brings us to the pivotal question that every tech company eventually grapples with: the build versus buy dilemma. Introduced to me in 2017, this question is often challenging to answer. However, my experiences—along with observations of some of our industry's giants—reveal that buying often prevails.
Consider Firebase: not widely known is the fact that this product, now seamlessly integrated into Google Cloud, was initially an independent company founded in 2011, acquired by Google in 2014. Why build a solution from scratch when you can leverage one that has already proven successful? Google further expanded Firebase by acquiring Divshot in 2015 and integrating it into the platform. This trend continues with other acquisitions like LaunchKit, Fabric, and Crashlytics.
It's a common misconception that large tech companies develop everything in-house; this belief often serves as justification for funding software engineering projects that become exorbitantly expensive. The stark reality is that even tech giants like Google and Apple—armed with vast teams of software engineers—opt to buy when it makes practical sense. Why invest time in creating a weather app when acquiring DarkSky provides a quicker solution? This approach accelerates time-to-market and utilizes engineering talent more effectively.
The buy versus build decision can also apply to subscriptions for third-party services that applications may rely on, such as AWS, Firebase, SSO providers like OKTA, payment platforms like Stripe, or communication services like Twilio.
Choosing to buy rather than build often increases a product's chances of success by integrating already successful solutions, allowing the organization to concentrate on delivering unique and reliable customer experiences.
So, what are your thoughts? Do you lean towards building your solutions, or do you prefer integrating with existing third-party services and moving forward?
Chapter 2: Addressing Job Hopping in Tech
The False Dichotomy Of Frequent Job Hopping In Tech
It's not outdated to remain in a software engineering role for over two years, nor is job hopping the only alternative...
Things I’ve Learnt As A Staff Software Engineer
Having served as a staff software engineer for a year, I've gathered some insights worth sharing...
Hang On To Your Laptops, Remote Development Isn’t The Future Just Yet
Is remote development truly the future? A pragmatic assessment of its viability in the software industry...
Want to read many more stories about LEGO, tech, coding and accessibility? Read unlimited stories from me, and…
Attila Vago — Software Engineer improving the world one line of code at a time. A lifelong geek, writer of code and blogs, advocate for web accessibility, LEGO enthusiast, vinyl record collector, and craft beer lover! For more insights, check out my stories on LEGO, tech, coding, and accessibility!