Build or Buy — A Practical Guide to Getting It Right
Develop in-house or to buy? Making the wrong decision here can drastically reduce productivity and drain both human and financial resources. So how do you get the answer right?
Over the years, and especially over the last one at Natural Intelligence, I have come across this question frequently. And in turn, I have worked out a set of guidelines that have helped us more successfully decide.
But keep in mind, context is super important. Natural Intelligence is 10 years old, has numerous successful products, and approximately 450 employees, almost half of whom belong to our product and R&D teams. We have stability, clear vision, and the resources that enable us to consider in-house development.
Startups, on the other hand, do not have the luxury to even begin considering this question. From my experience leading product at startups, external tools are pretty much always the way to go. You have limited resources, tight timelines, and the need to be extremely focused on your main product. In addition, the scale is usually still limited and available tools on the market are good enough. In other words, if you’re working at a startup don’t get sidetracked!
If, however, your company is mature, established, and has time and budget on its side, these guidelines are for you.
8 questions to ask yourself
Nowadays, the roadmap for new products and features we’re managing consists of both internal and external tools. To help us decide which route to follow, I ask myself — and the relevant stakeholders — these eight questions:
- Is this product or feature part of our core business?
This is by far the most important question you need to be asking. If the answer is yes, like in the case of A/B testing at Natural Intelligence, I tend to push for in-house development. If it’s outside our core business, like say email marketing automation in my business, my tendency is no. Because bottom line, you simply do not want to be over-investing in development initiatives outside of your core business.
Related consideration would be whether you have the technological know-how. Developing something that is far outside the core competence is a big risk — you will either build a crappy product or completely fail, and even if you succeed it would always be very hard to maintain.
2. What’s the price of vendor lock-in?
This question refers to future consistency (or inconsistency…) between the evaluated product/feature and the specific potential vendors with the company’s roadmap. A tight integration with a product that locks the company’s roadmap is very bad.
Sub-questions to ask here include how much is this solution going to be a part of a much bigger product or platform? Will we be locked-in with this vendor due to the many processes or products that will come to rely on it? And how will that affect other business processes? A product that touches multiple areas in the business or even integrated into core flow would be better developed alone.
3. Do we have a unique business case?
Sometimes a generic third-party solution is a good match, but when your company has a unique use case with commercial implications, a generic solution won’t be good enough and you should consider in-house development. Think of unique business relationships with customers or partners, or unique user onboarding funnel that is hard to be supported by generic tools.
4. Do we have special know-how?
We like to call this the “secret sauce”. And it’s a matter of determining if we have something homegrown from our own experience that we can’t find outside. For example, our experience over the years at Natural Intelligence in user acquisition, especially through search engines, is totally part of our “secret sauce”. That is why when we started to consider automating it, we chose to go in-house. Areas in which we have limited expertise are far more likely to be outsourced.
5. What’s our time to market?
If you need to meet a particular market demand ASAP due to competitors’ state, a business opportunity, or even regulation, most often a ready-made tool will win.
6. Does the external tool save on headcount?
This one can sound a little harsh, but it’s something you need to consider. Do you have extra hands available to work on development? Will you need to hire a new team? Again, is it worth it?
7. What have similar companies done in the past?
If possible, look for someone who worked in your space for guidance. Not necessarily to be like them, but to understand their decision-making process and considerations, particularly when they were at your stage of growth.
8. Vendor specifics.
Vendor pricing, ease of integration, availability, and SLAs are all things to consider. They are a significant part of the cost-benefit equation and can be the tipping point, if in your favor.
Who should be involved in the decision-making process?
With many stakeholders potentially involved, it can be confusing as to who should be involved in the decision-making process and who should generate and lead this process. It depends on the scenario.
The first scenario is when the need for the feature or product comes from the business itself. Here the Product Manager should address it during the yearly/quarterly planning, and kickoff the analysis.
The second scenario is when the need is raised by the R&D teams as part of technical debt or as a tech infrastructure need. In this case, usually, the CTO or Engineering Leader should lead the initiative.
In both cases, necessary stakeholders would be the relevant engineering leaders, the product manager, and the relevant business users (i.e. those who asked for the feature or product in the first place).
Bottom line
At the end of the day, for companies that have the resources, a combination of internally and externally developed tools is the right way.
Keep in mind, the cost of the wrong decision is very high. If you go with external and integrate, the price of going back includes costs of implementation, users’ onboarding (when relevant), integrations made with other processes and products, and learning curve. If you go with internal and don’t have the expertise, you could be wasting workers’ time across the board.
As such, making these decisions should be relied on thorough analysis and preferably had the required attention and resources during your annual or quarterly planning. Of course, sometimes needs arise in between, and you and your team should be flexible enough to address them as well. Just make sure you do so with the right questions in mind.
—
Thanks to Amichay Zer-Kavod.
