Buying software is often the answer for busy engineering teams in search of a quick solution with minimum aftercare. But while your team may be sure of the problem, how do you go about searching for a product to fix it?
Far from being the 'easy option', there is a lot you need to consider before you invest in a bought solution – user experience, cost comparisons, and support features to name a few. Let’s explore some of the considerations when making a good decision.
What do you and your organization need to get out of this solution?
Discuss and define the problem you need to solve clearly and its scope so that you don’t over or under shoot with your solution. It’s worthwhile to put in the time to make sure that you don’t get a solution that is not going to scale or adapt as your needs grow or change. Make sure the codebases, APIs, frameworks, and tools that the solution will need to work with are defined so that you have your bases covered. Sound out the wider team in case others are also looking for the same or a similar solution so that their requirements get included.
How do you approach the topic with your team and the relevant engineering stakeholders?
Ask your engineers on the team for their feedback and their experience with the problem and how they have dealt with it in the past. Ask what tools they’ve used or in what other creative ways have they solved the issue. If anyone has direct and strong experience solving the same problem in the past, consider their experience heavily in your decision.
What are the fundamental costs associated with both solutions?
Some factors to consider around costs are also whether your team has the necessary skills to build a solution. If not, the costs are going to go way up. Building a solution usually means building some form of expertise in the problem area. In startups, you typically don’t have time for that. You want your engineering and product teams to focus on the company’s core competencies and build those out. Buying is almost always the right choice. Someone else has already put a lot of thought into this problem and has come up with a solution.
However, if you do run into a problem where there isn’t a clear solution for your specific case or you have additional requirements that have become specific to your organization (i.e. scaling usage to hundreds of teams and thousands of users like Netflix, Google, Amazon), then it either makes sense to build, or you may be forced to build – even if you’d prefer not to.
Which factors do we need to keep front-of-mind as we move through the decision-making process?
One important factor for the team is whether we can go through a free trial, or even better, if there is a free tier that can get the team started to get a feel for what the tool is like in practice. That will give you insight into whether the solution is going to work out in practice. However, free trials often aren’t going to work for a production scenario because it’s hard to get a new solution integrated in a few days when you have a lot of other fires that you are fighting. It’s important to use whatever low-cost ability you have to try a solution before committing to it in full if you can.
Do you have the budget to buy?
This is another important consideration but since the alternative, building, is often more costly, it may not matter. And if you have no budget to buy, you will need to find open source alternatives. Fortunately, the majority of the time there will be open source solutions for the problem you encounter. You and your team will have to put in some effort to stand up these solutions and customize them to your needs. This will still almost certainly be more cost-effective than building a solution yourself from scratch.
Understanding the impact on the wider organization
Which decision (build/buy) has historically proved most successful?
In the past, from just working at startups of different sizes, Series A to pre-IPO, what’s worked best for my team and organization has been to outsource the problem to others to solve. This involves either configuring them for our use case or compromising a little bit by changing some of our processes to get value out of the tool.
What is the need for scalability across teams?
This one is important. When you are building just for your own team, then it might seem trivial. But when other teams also find themselves encountering this problem, then you gain more stakeholders and have even more people to please. Suddenly, scaling the in-house solution to cater to multiple teams or an entire org will become a full-time job and you’ll need to spin up a team just to maintain the system. This is why it’s a good idea to put in the time to lay out the scope you need for the solution before you jump in.
How does resource intensity differ for maintaining both solutions?
The time and effort needed to maintain in-house built solutions are, oftentimes, vastly underestimated. Not only do you have to build and maintain the code, but you also have to manage the infrastructure needed to serve that code. What looks like a one engineer job could easily turn into three or four engineers with different skillsets needed to work across the stack. Couple that with writing even decent documentation for others to be able to use it productively, and you can easily be looking at a full engineering team working on it full-time.
What can we do to accelerate adoption of the software across teams?
Have more in the way of developer evangelism. Encourage the engineering teams in your organization to talk through the problems that they or other organizations have solved, how they solved them, what challenges they ran into and, ultimately, which tools they ended investing in.
Conclusion
Build vs. buy remains a discussion for every organization to have for itself. Every circumstance is different and there is no single answer that is the best for everyone. Organizations must do the analysis for themselves. However, there are a few generalizations that can be made. If buying a solution is relatively straightforward, has no real obstacles, and solves the problem adequately, then it is usually the right choice. Conversely, if no off-the-shelf solution solves the problem adequately then building a solution is the only answer, no matter how difficult or costly. The cost differential in financial and time terms is so wide that it is worth putting in the time to properly research potential solutions to find the best fit – since the cost of doing so is dwarfed by the potential costs of making a poor choice. Socialize the issue in your organization, do your research, evaluate thoroughly, and decide wisely.
