Build or Buy? How Dineout scaled its B2B offering

Operating a restaurant entails several processes across its different systems: order management, kitchen/recipe management, customer reservation and feedback management, etc. Inability to streamline and optimise any of these processes can become a source of pain for a restaurant owner.

Restaurant owners and managers seek solutions that can be adopted by the restaurant staff with minimal hand-holding or extensive training. inresto by Dineout offers a do-it-yourself (DIY) platform where restaurant staff can easily enable or disable the different features. The product management team at Dineout works round the clock to ensure that the inresto product suite stays updated with all the trending features the market has to offer.

Before scoping for a feature to be developed on the product, the product team at inresto analyses and deliberates on a number of factors to ascertain whether to develop the functionality in-house or to buy the solution from the market by integrating with a partner offering the solution.

Following are the 3 prominent factors with illustrations of how the Product team at inresto has dealt with the ‘Build vs Buy’ choice:

1. Utility of the feature
2. Speed to Market
3. Cost to build vs Cost to buy

Factor 1: Utility of the feature

The principal factor in the ‘Build vs Buy’ decision-making process is to identify the relative utility and importance of the functionality for the core product offering. This requires an in-depth understanding of the product’s core competency and its value proposition which in turn contributes to the company’s long term strategy.

Utility framework to determine if the use case should be built in-house

Case in Point: One project where utility of the functionality for the core product offering played a critical role in the decision making process was while weighing the options to have a Third Party Logistics (3PL) Delivery partner assignment capability on the inresto platform. This capability could either have been built entirely in-house or be bought from different solution providers in the market.

One of the primary objectives of the partner assignment capability was to provide a seamless do-it-yourself (DIY) experience to the user. None of the offerings from the identified solution providers enabled the user to access the partner assignment capability directly from the inresto platform, forcing the user to switch between inresto’s and partner’s ecosystem to complete the operation of assigning a partner against an order. Unable to attain the desired DIY experience for the user across any of the partner’s solutions, we decided to build the 3PL partner assignment platform in-house.

Factor 2: Speed to Market

The second most important factor in the ‘Build vs Buy’ decision making is the time in which the company intends to make the feature available for its users. The majority of the SAAS companies today have direct or indirect competitors which try to pitch their products with similar solutions. An elongated go-live timeline provides a direct opportunity for such competitors to step ahead and become the first mover in an under-penetrated market if they can provide the same features to the same set of users sooner.

Since B2B SAAS solutions tend to exhibit stickiness among their customers because of high switching costs involved in training, onboarding and setup of a new product, the first-mover typically enjoys a long successful run in an under-penetrated market.

Thus, with a strong emphasis on going live with the identified use case at the earliest, the decision of ‘Build vs Buy’ depends heavily on the estimated timeline of building the feature in-house vs integrating with an external vendor.

Case In Point: Speed to Market was the principal consideration for inresto product team while deciding the best way to integrate with different food ordering marketplace aggregators in the Middle East. The push to expand in the Middle East market at the time when Covid-19 was at its peak further enhanced the time-sensitivity of the decision. With Covid-19 restricting diners to the confines of their homes, online delivery proved to be the hunger saviour for a significant number of people. inresto’s Point of Sale product was therefore required to build support to accept orders that are placed by customers across different online food ordering platforms.

With an aggressive expansion push across restaurants in the Middle East, the product team at inresto had two choices to build the use case of accepting orders from major online food ordering aggregators: Either to integrate with each food ordering marketplace aggregator individually or to partner once with a centralised platform which can facilitate a plug and play integration capability with the different individual marketplace aggregators. Since it was crucial to swiftly activate the food delivery use case for the restaurants in the Middle East using our Point of Sale solution, we decided to have a one-time integration with an external partner rather than having to integrate with each marketplace individually.

Factor 3: Cost to build vs Cost to buy

The third most important factor that the inresto product team values while deciding whether to Build or Buy is the estimated cost difference between the two options. Before the target, functionality is picked up in the development roadmap, either to be built in-house or by integrating with a solution provider, the product team works closely with business and support teams to arrive at the potential cost of the two options.

Breakdown of the 2 costs into their components

Building in-house: Following are some questions that should ideally be answered before taking up the discussion to build the product in-house:

• Relative priority of the feature in the near term product roadmap
• Experience level of the in-house development team, to work on similar problems
• Estimated development effort needed to get the feature built on product
• Development bandwidth is available to build the functionality, once the feature gets picked in the upcoming sprints

Following are the tasks that the Product team performs to estimate the potential cost in the scenario that the solution will be built in-house:

1. Prepare an exhaustive list of user stories to be catered to, as part of the desired feature and get a sign off on the expected behaviour from business stakeholders
2. Work with product designers to come up with UI/UX flows that best represent the feature, as it would be experienced by the user on the product
3. Provide a brief on the different feature components to the engineering team and address their clarifications/concerns
4. Coordinate with Engineering Managers to chart out the development life cycle and estimate the total development effort

Buying an existing solution from the market: Following are the tasks that the Product team performs to estimate the potential cost in the scenario that the solution will be built by integrating with an external partner:

1. Research and identify the different players who can offer a solution fitting the use case to be catered
2. Perform competitive analysis to understand if any direct or indirect competitors are already availing services from existing solution providers to cater to a similar use case
3. Reach out to partners to obtain their list of offerings and map their offerings to the identified user stories required to be catered
4. Rank the partners by weighing them on the parameters suggested in the image below.
5. Shortlist the partner based on the above ranking and coordinate with stakeholders from internal Business and Procurement teams to initiate the onboarding process, which can be executed in parallel to solution development.

Steps to rank the different solution providers

Case In Point: Cost to Build vs Cost to Buy became the most crucial factor when we took up to onboard restaurants housed within hotels and resorts. Almost all restaurant managers across these hotel properties that we spoke to, wanted a common solution to manage both their restaurant and hotel operations. Since restaurants housed within hotels and restaurants occupy a significant share of the restaurant hospitality market, the opportunity wasn’t too small to be ignored.

The problem statement was to display the combined sales of the restaurant for the food items consumed by a customer during the hotel stay along with the hospitality charges which are billed to the customer by the hotel and subsequently paid by the customer while checking out of the hotel. To solve this problem, we could either diversify into property management by developing a hotel management software and club it with its existing offering restaurant management software. Or, we could identify a partner which has an already existing offering to manage hotel and property operations.

Since inresto’s core competency is around solutions offered to restaurants, it was relatively a straightforward decision to lean towards integrating with a partner who has an expertise in hotel and property operations for the following reasons:

- It is one of the most widely used hospitality management software employed by hotels and resorts around the world

- It offers one of the most exhaustive feature set which hotel managers, cashiers and property staff need for their operations

- It provides a RESTful interface with JSON-formatted responses to use many of its data: guest, reservation, transactions, rooms etc., thereby making it efficient for the Engineering team to integrate with the partner

- It has a dedicated Support channel for addressing any concerns faced by the Engineering team during or after the integration phase

Opportunity Cost

An essential component in the Cost to Buy vs Cost to Build analysis that often gets missed is the Opportunity Cost. This cost can be loosely defined as the cost of missing out on building the functionalities which the team would have otherwise built, had they not spent their bandwidth building this feature. Identifying and justifying the opportunity cost of building the feature — either in-house or by partnering with a solutions provider — is one of the most important roles that the Product team plays while arriving at the final decision post-analysis.

More often than not, significant time elapses between the item getting prioritised in the product roadmap and it getting picked up in a development sprint. In this elapsed time, the dynamics governing the decision around which features are worth spending resources on right now get considerably altered. Hence, it is important and wise to carry out an opportunity cost analysis once again after arriving at the estimates for Cost to build vs Cost to buy.

The factors listed above (Utility of the feature for product’s core competency, speed to market and Cost to Build vs Cost to Buy) are not the only ones that should be considered while making a Build vs Buy decision. There can be other contextual factors specific to the company or business which can play a pivotal role in this decision making for the product team — Opportunity Cost being one of them. It is therefore important for the Product Manager to align the decision with business and Engineering stakeholders before taking up its development in-house or by integrating with an existing solution offered by a partner.