Turn your app idea into a reality with our Ultimate Starters' Guide.
Learn how you can turn your app idea into a reality with our Ultimate Starters' Guide.
Note: The examples provided come from our interview with Colin Bielen, VP of Engineering at CBS Media Ventures.
To build or to buy? That is the question.
It's the eternal conundrum that engineering teams face when they embark on the quest for new tools and product solutions. It's like choosing between creating a custom suit that fits you like a glove or grabbing a stylish off-the-rack ensemble. Decisions, decisions!
Building a software solution from scratch allows you to customize it to your organization's needs. You can adjust every little detail to make it just right for you. This approach lets you create a solution that works perfectly with your unique requirements and how you work. On the other hand, buying a software solution has its own bag of tricks that can outshine the challenges of building from scratch. The market is rich with pre-built solutions catering to various business needs, from project management to customer relationship management. By buying a ready-made software solution, you can save yourself time and effort.
To help shed some light on this topic, we sat down with Colin Bielen, VP of Engineering at CBS Media Ventures, on the new episode of the Product Builders podcast. Follow along as we explore the key points from our conversation.
Deciding on whether to build or buy a tool depends on several factors. Every engineering team has specific skills, varying levels of bandwidth, and unique business objectives they're aligning their work with. The right choice is the one that fits the needs of YOUR team and the wider organization.
If an off-the-shelf solution meets your needs and integrates seamlessly with your current tech stack, that's a great option. It offers benefits like saving time, rapid implementation, and access to a wide range of features and functionalities. However, there are instances where the problem you're trying to solve is specific to your internal workflows, necessitating a more tailored approach. Having your team create a custom tool might be better in these cases. This lets you precisely address your unique requirements and ensure they fit seamlessly with your existing systems.
If the problem you're dealing with is relatively small in scope, using a temporary solution, also called a stop-gap, can be a good option. A stop-gap solution allows you to quickly address bottlenecks or pain points without committing to a full-scale development project. It gives you time to consider long-term solutions carefully or allocate resources to more critical projects. However, it's essential to remember that a stop-gap solution is typically intended as a temporary fix. It may not offer the same functionality, scalability, or long-term sustainability as a fully developed tool. Careful consideration should be given to the trade-offs and limitations of implementing a stop-gap solution.
According to Colin Bielen, "When you choose to build a stop-gap, it's important to limit your scope to what you're doing. Otherwise, I've seen it happen, where a stop-gap becomes the thing that occupies the entire engineering team for a year. You have to manage the scope as you would with any other project. If you throw an engineer on it blindly, they might go down a rabbit hole, and you might never see them for a year or two."
Before choosing to build an internal tool or solution, it's essential to reflect on the core competency of your team and its goals. Ask yourself:
By honestly answering these questions, you'll be much better informed about the right path forward for your team. If a project is sizable and outside the core competency of your team, it's pretty clear that you should buy a third-party tool that fits your needs. No real competitive advantage can be gained by using your resources to build this tool or product solution.
However, if a tool will deliver significant value and align with your team's core competency, it's worth building it.
Colin says, "If the project involves secret sauce type stuff that brings you a competitive advantage, then it's probably best to keep it internal." That said, sometimes, the secret sauce projects may require more resources than you currently have. In that case, it's worth speaking with your senior manager and explaining why this tool or solution is worth investing in."
Another part of the equation when figuring out what tool is best for your team is the tech stack. From an integration standpoint, the tool should be able to integrate as seamlessly as possible with your current tech stack. Sometimes a tool may fit your needs, but if it's problematic from an integration standpoint, it may cause more trouble than good. There are ways to make different tech stacks work together. However, the added costs and time to integrate them properly need to be addressed.
Additionally, it would help if you considered your team's expertise and whether or not the new tech stack is one they will understand. You may be able to buy a solution and integrate it, but if your team doesn't know how to maintain or iterate on it, it will cause unneeded friction.
According to Colin:
"For many of our core systems, there will be a time when we need a new feature or component built. We then have to figure out if it's something our team will actually be able to handle. Sometimes the answer is no, and then we have to see if we can train our team to understand it. Or, we have to accept that we may need to work closely with the product vendor for future changes. In this case, you need to be very clear about how your vendor relationship works. Will they be able to provide the support you need? Will they always be your vendor for that tool? Addressing these concerns on the front end is vital for any successful use of a vendor's tool."
Before buying or building a solution, you need to make sure your team will be able to maintain and support it.
Ultimately, when building or buying a tool, all internal stakeholders need to be onboard. Defining the problem you aim to solve right from the start is essential to ensure alignment and foster a shared understanding. This shared understanding creates a common vision and facilitates more productive discussions, as stakeholders can provide valuable insights and input from the outset. By clearly stating the problem, its impact on the organization, and the benefits the tool will bring, you can engage stakeholders and generate enthusiasm for the project.
Defining what you are not solving is equally important. It helps manage expectations and prevents scope creep by explicitly identifying the boundaries and limitations of the tool. Communicating what falls outside the project scope saves stakeholders from investing time and effort in areas not part of the immediate solution.
This proactive approach reduces confusion and prevents potential tense meetings or disagreements later on, as a well-defined vision and scope have already been established. By clearly articulating the specific problem and delineating what you intend to address AND what you do not, you can bring your stakeholders onto the same page early in the process.
Implementing any product, platform, or tool is about solving problems. As we all know, problems change as time goes on. That's why it's always important to critically evaluate your reasons for building or buying a tool and be willing to adjust when necessary. As Colin says, "What's true today may not be true tomorrow." So don't be afraid to pivot when necessary as the needs of your organization change. If you align your efforts with the core competency of your team, understand the scope and tech stack, and make an effort to gain internal stakeholder buy-in, you'll be well on your way to implementing the tools you need for ongoing success.
If you have any questions or comments about this topic, please reach out and get in touch!
Stay in the loop! Join our newsletter for monthly updates on industry news, company updates, recent work and job openings.
