Deciding Between Build, Buy or Partner

A Practical Guide for SaaS Business Leaders to Choose the Right Option Each Time

“We have plen­ty of space on our roadmap” is a state­ment prob­a­bly no one ever heard from the prod­uct team when ask­ing for a new fea­ture. For a long time, the alter­na­tive to “build” was “buy” (a com­pa­ny that does it). Today, a third option is on the table: “part­ner” (with a provider of that fea­ture). His­tor­i­cal deci­sions or lack of knowl­edge about the pros and cons of all avail­able options can make deci­sion-mak­ers biased in their pref­er­ence for one option. This behav­ior entails the risk of not always mak­ing the best deci­sion for the business.

Tech com­pa­nies with strong prod­uct own­ers tend to pre­fer to build new fea­tures on their own, even though the roadmap is packed and the prod­uct fea­ture is an add-on rather than a core func­tion­al­i­ty. This leads to lengthy devel­op­ment cycles, reduces the focus on core prod­uct devel­op­ment, decreas­es inno­va­tion pow­er, and even­tu­al­ly dilutes the com­pa­ny’s unique sell­ing propo­si­tion (USP). When the fea­ture is not part of the busi­ness’s core func­tion­al­i­ty, it’s chal­leng­ing to reach the qual­i­ty and inno­va­tion speed of exist­ing solu­tion providers focus­ing on such a fea­ture’s development.

With enough fund­ing avail­able, com­pa­nies can also con­sid­er buy­ing a provider that already offers a prod­uct includ­ing the desired fea­ture. Buy­ing a com­pa­ny comes with a post-merg­er inte­gra­tion process, where not only the prod­uct or fea­ture but also the staff, cul­ture, and process­es need to be inte­grat­ed into the buy­ing com­pa­ny. The whole process of buy­ing and inte­grat­ing a com­pa­ny could still be faster than start­ing the devel­op­ment from scratch because the busi­ness also acquires knowl­edge and qual­i­fied staff. How­ev­er, it can also take longer if the merg­er becomes complex.

Part­ner­ing with a solu­tion provider is anoth­er option that has become very pop­u­lar recent­ly in the SaaS indus­try. Com­pa­nies ben­e­fit from the exper­tise and speed-to-mar­ket of using exter­nal know-how with­out the finan­cial and post-merg­er inte­gra­tion require­ments of an acqui­si­tion. Tech­no­log­i­cal advance­ment through cloud ser­vices and API stan­dards makes inte­gra­tions eas­i­er than ever before.
By eval­u­at­ing the fol­low­ing cri­te­ria, it is pos­si­ble to ana­lyze the three options method­i­cal­ly and choose the best option for the business.

Deci­sion Criteria: 

Time-to-mar­ket: describes the time it takes from receiv­ing a fea­ture request until it is available. 

Resources (HR / $): describes the need and avail­abil­i­ty of required staff and bud­get to devel­op the feature.

Con­trol over devel­op­ment: describes the required lev­el of con­trol over a fea­ture’s cur­rent and future development. 

Core Busi­ness Pro­tec­tion: describes the need to pro­tect the core of the busi­ness and its intel­lec­tu­al prop­er­ty, brand, and knowledge. 

ROI risk: describes the readi­ness of own­ing the risk on invest­ment to obtain a feature. 

Depend­ing on the com­pa­ny’s sit­u­a­tion or objec­tives, it can be bet­ter to build, buy or partner.

When to build?

Build is an option when time-to-mar­ket is not vital or time is less crit­i­cal than own­ing the fea­ture even­tu­al­ly. It is also the only option in case a fea­ture is entire­ly new and unavail­able to obtain externally.

Inter­nal devel­op­ments require staff to be avail­able and should not be tak­en from more sig­nif­i­cant projects. There­fore build­ing a fea­ture makes sense if a busi­ness wants full con­trol over the devel­op­ment because it is essen­tial for the com­pa­ny and close to the core prod­uct. Pro­tect­ing the core prod­uct might also pro­hib­it shar­ing crit­i­cal knowl­edge and rights with sup­pli­ers or partners.

Con­se­quent­ly, the busi­ness must be will­ing to own the entire ROI risk for the resources invest­ed in devel­op­ing the feature.

When to buy?

When a fea­ture requires a lot of knowl­edge, spe­cial­ized staff, and/or com­plex devel­op­ment, a com­pa­ny might con­sid­er buy­ing a provider that has already devel­oped the fea­ture or prod­uct. A pre­con­di­tion is that there are ide­al­ly sev­er­al com­pet­ing providers, of which at least one sig­nals its readi­ness to be acquired. The time-to-mar­ket may still take a while, but the pur­chase can pro­vide some short­cuts. Buy­ing may require a sig­nif­i­cant bud­get but also means the staff will come with the acquisition.

A mod­er­ate to a high lev­el of con­trol over the devel­op­ment will be achieved. The past devel­op­ment can’t be changed. How­ev­er, future mod­i­fi­ca­tions and updates are under full con­trol and should be pos­si­ble if the acquired com­pa­ny’s staff joins the team. Equal to build­ing a prod­uct, buy­ing ensures com­plete pro­tec­tion of the core prod­uct because the IP and brand will go over to the buy­ing com­pa­ny. The buy­ing enti­ty will own the entire ROI risk.

When to partner?

Dif­fer­ent from build­ing and buy­ing, part­ner­ing is an option when time-to-mar­ket and resources are lim­it­ed. Col­lab­o­rat­ing with an exist­ing provider makes the fea­ture avail­able in a com­par­a­tive­ly short peri­od. Part­ner­ing with a com­pa­ny that focus­es on devel­op­ing a spe­cif­ic fea­ture also allows con­sis­tent devel­op­ments and effi­cien­cy in updates and innovation.

Nei­ther staff nor a sig­nif­i­cant bud­get is required because the part­ner can pro­vide both in return for a com­mit­ment. Dif­fer­ent from trans­ac­tion­al rela­tion­ships (buy­er <> sup­pli­er), in col­lab­o­ra­tive rela­tion­ships (part­ner <> part­ner), mon­ey trans­ac­tions between the part­ners often are based on rev­enue-shared mod­els or do not take place. Part­ner­ing allows a cer­tain degree of con­trol over the fea­ture devel­op­ment through joint plan­ning and aligned objec­tives with the part­ners. In case full own­er­ship of the fea­ture IP is not required, or the fea­ture or ser­vice does not touch the core prod­uct, part­ner­ing is often the most effi­cient way.

The ROI risk is shared in a col­lab­o­ra­tion where part­ners invest in cre­at­ing joint value.

While the stan­dard options often have been “build or buy”, tech­no­log­i­cal advance­ments and mar­ket devel­op­ments in the SaaS indus­try make part­ner­ing an increas­ing­ly attrac­tive option and often the first choice to build a com­pet­i­tive advan­tage through co-innovation.