Tackling the Build Vs Buy decision
Systems fascinate me. As a product manager, finding systems that help create predictable outcomes for my entire team is paramount for long-term success. There are many systems that can have a dramatic impact on how we can build and scale software applications. This could be an analytics solution to understand user behavior in the platform, or a continuous deployment pipeline that triggers a host of custom tests before deploying new functionality into production.
And this is where we encounter the classic question — do we build such a system inhouse, or do we purchase a solution from a vendor?
This question pops up before the start of any major undertaking and depending on the criticality and urgency of the project, needs to be addressed rather quickly.
When addressing this question, it’s good to think of 3 important criteria –
1. The problem being solved
2. The cost to address the problem
3. The ROI of the path chosen to address the problem
The problem being solved
Be thoughtful about the problem you’re trying to solve when evaluating building vs buying. If the problem that you’re trying to solve is hyper-specialized and doesn’t relate to the core value proposition your business is offering, then you probably should consider buying the solution.
Examples of such hyper-specialized problems include –
1. Email marketing client
2. Payment processing portal
3. Code-editing and review tools
This way, you can focus on what makes your offering special, and outsource problems around the edges to specialized vendors.
Note that if the problem being solves directly or indirectly relates to your core value proposition, then you may want to consider building this in-house. For example, if you’re a company that helps recruiting companies better manage their clients, you probably want to build many of the core services to support this in-house.
The cost to address the problem
Understanding the problem should provide you with a gut-feeling for your build vs buy decision, but you can also quantify this by understanding the cost of your decision. Let’s consider the costs for building vs costs for building a solution.
Cost to build
Building software can be costly, especially when the problem being solved isn’t part of your businesses’ core value proposition. Engineers are one of the most expensive resources currently employed in your company, and as product manager, it’s your job to make sure their expertise is focused on the right areas.
The cost to build can be painfully hard to estimate. It’s important to establish an environment of transparency and trust so your engineering manager can work with their team and determine the estimated time to build the software.
From here, factor in maintenance costs as well. Sometimes, a solution built in house may also require a dedicated resource to fully maintain and work with the system. For example, a custom CRM built in house to support your sales and marketing teams may require a dedicated operations engineer to maintain and work with the system.
Cost to buy
When evaluating a vendor, always try to go through a long trial process. This will help you determine the overall costs required to setup and maintain the solution at scale.
On the surface, buying a solution may seem like a cheaper option. But beware. If you do not look at the finer details the vendor’s licensing, you may be treated to a loaded bill at the end of your subscription period. Read the licensing arrangement carefully. The simpler the licensing, the easier to manage and predict costs. Some vendors make it easy to work with them, like AWS has a monthly cost predictor to determine what you’ll pay based on historical usage.
You may be tempted to go with a solution that has the cheaper licensing model, but that may come at the cost of maintaining it. Depending on the complexity of the software, there may also be some setup and maintenance cost associated with the product purchased. If there is, make sure the implementation costs fall in an accepted price range, and the person helping you implement it is competent. Maintenance costs may be harder to determine, but you can get a decent picture of maintenance costs during the trial process.
The return on investment
Finally, think through the return of investment of the path you chose.
While building your own solution may take longer, it can be customized and tailored to your business needs. There may be significant ROI in the long run in this regard, for example, when building your own CI/CD pipeline by customizing existing open source solutions like Jenkins. This can also allow you to flexibly integrate with other systems you rely on to keep you business up and running.
The biggest upside when buying a solution is speed to success and lack of specialized resources. Since the vendor has a dedicated team to solving specialized problems, you and your team can potentially implement it faster, and focus on your core value proposition that brings joy to your customers. The downside of course is that no vendor can have a one size fits all solution, and if your business has a lot of complex systems working together, it may mean the solution purchased may not be as flexible as you’d like. For example, if your company has a host of products sold with different likening models like perpetual and subscription, chances that you can find a payment provider that covers all the purchasing models flexibly to your liking is slim.
Closing notes
Build vs buy decision is a mix of tactical and strategic criteria. Being thoughtful about your long term goals and outcomes, while being cognizant of your resource constraints and short term goals, can help you logically decide the best path forward for your team.
Featured image photo by Sneaky Elbow on Unsplash
