Deciding Between Build, Buy or Partner

“We have plenty of space on our roadmap” is a statement probably no one ever heard from the product team when asking for a new feature. For a long time, the alternative to “build” was “buy” (a company that does it). Today, a third option is on the table: “partner” (with a provider of that feature). Historical decisions or lack of knowledge about the pros and cons of all available options can make decision-makers biased in their preference for one option. This behavior entails the risk of not always making the best decision for the business.

Tech companies with strong product owners tend to prefer to build new features on their own, even though the roadmap is packed and the product feature is an add-on rather than a core functionality. This leads to lengthy development cycles, reduces the focus on core product development, decreases innovation power, and eventually dilutes the company’s unique selling proposition (USP). When the feature is not part of the business’s core functionality, it’s challenging to reach the quality and innovation speed of existing solution providers focusing on such a feature’s development.

With enough funding available, companies can also consider buying a provider that already offers a product including the desired feature. Buying a company comes with a post-merger integration process, where not only the product or feature but also the staff, culture, and processes need to be integrated into the buying company. The whole process of buying and integrating a company could still be faster than starting the development from scratch because the business also acquires knowledge and qualified staff. However, it can also take longer if the merger becomes complex.

Partnering with a solution provider is another option that has become very popular recently in the SaaS industry. Companies benefit from the expertise and speed-to-market of using external know-how without the financial and post-merger integration requirements of an acquisition. Technological advancement through cloud services and API standards makes integrations easier than ever before.By evaluating the following criteria, it is possible to analyze the three options methodically and choose the best option for the business.

Time-to-market: describes the time it takes from receiving a feature request until it is available.

Resources (HR / $): describes the need and availability of required staff and budget to develop the feature.

Control over development: describes the required level of control over a feature’s current and future development.

Core Business Protection: describes the need to protect the core of the business and its intellectual property, brand, and knowledge.

ROI risk: describes the readiness of owning the risk on investment to obtain a feature.

Depending on the company’s situation or objectives, it can be better to build, buy or partner.

Build is an option when time-to-market is not vital or time is less critical than owning the feature eventually. It is also the only option in case a feature is entirely new and unavailable to obtain externally.

Internal developments require staff to be available and should not be taken from more significant projects. Therefore building a feature makes sense if a business wants full control over the development because it is essential for the company and close to the core product. Protecting the core product might also prohibit sharing critical knowledge and rights with suppliers or partners.

Consequently, the business must be willing to own the entire ROI risk for the resources invested in developing the feature.

When a feature requires a lot of knowledge, specialized staff, and/or complex development, a company might consider buying a provider that has already developed the feature or product. A precondition is that there are ideally several competing providers, of which at least one signals its readiness to be acquired. The time-to-market may still take a while, but the purchase can provide some shortcuts. Buying may require a significant budget but also means the staff will come with the acquisition.

A moderate to a high level of control over the development will be achieved. The past development can’t be changed. However, future modifications and updates are under full control and should be possible if the acquired company’s staff joins the team. Equal to building a product, buying ensures complete protection of the core product because the IP and brand will go over to the buying company. The buying entity will own the entire ROI risk.

Different from building and buying, partnering is an option when time-to-market and resources are limited. Collaborating with an existing provider makes the feature available in a comparatively short period. Partnering with a company that focuses on developing a specific feature also allows consistent developments and efficiency in updates and innovation.

Neither staff nor a significant budget is required because the partner can provide both in return for a commitment. Different from transactional relationships (buyer <> supplier), in collaborative relationships (partner <> partner), money transactions between the partners often are based on revenue-shared models or do not take place. Partnering allows a certain degree of control over the feature development through joint planning and aligned objectives with the partners. In case full ownership of the feature IP is not required, or the feature or service does not touch the core product, partnering is often the most efficient way.

The ROI risk is shared in a collaboration where partners invest in creating joint value.

While the standard options often have been “build or buy”, technological advancements and market developments in the SaaS industry make partnering an increasingly attractive option and often the first choice to build a competitive advantage through co-innovation.