Uber for X can be best described as a platform looking to deliver a product or provide a service On-demand with demand being aggregated online and serviced offline. But there are so many variations that can come up when we start analyzing different implementations in this field.
When we talk about an app like Uber:
- We can assume – supply is loosely bound to the platform and we are merely aggregating the supply.
- Demand is not scheduling the product/service for a time in the future and everything is instantaneous.
- Demand is not choosing the service provider and he is being allocated the one based on his choice and other variables.
- Service/product that we are talking about has a standardized flow and doesn’t involve customer making a selection across lot of different variables.
Clearly, for most of the entrepreneurs their business model will have many stark differences from Uber’s business model cited above. These considerations have a direct impact on how you deal with decisions related to identity, scheduling, matching, payment, etc. while designing the product and thus the cost associated with defining the MVP.
If you are in the process of defining the contours of your business model and making these design choices and are looking for a more exhaustive take on the topic – download this free eBook that talks about how to finalize the business model for your On Demand Startup – Ebook: Understanding the On Demand Business Model
B) What is the business vertical you are trying to target?
Is it a taxi/limo business or an On-Demand platform designed for some other vertical? When you are trying to find a solution to help your existing taxi/limo business with an Uber like experience, there are many companies providing white label solutions. When you start going broader to say, ground transportation (shuttle/event/hailing solutions directed at children/senior citizens/corporates etc.) or beauty or home services or delivery and so on, things start becoming more complicated and it is difficult to find a script based approach that works.
We have been grappling with this problem for the last 15 months and have come up with a top down approach as a solution. The basis is that there are certain modules – matching, scheduling, tracking, payments, reviews, notifications, aggregation and signup that form the backbone of any such platform. So we have created backend code blocks or an MBaaS based architecture structured to take care of most of the use cases that can be thrown by an On Demand Business Model. For more information on functional choices that go in defining each of those modules – download this eBook that talks about the Building Blocks for On-Demand Technology
C) Evolution of On-Demand Platforms
When we talk about an app similar to Uber, it is helpful to keep the general evolutionary framework associated with all startups in mind. It is a fact that all business apps like or unlike Uber have to go through the 4 stages mentioned below. But the fact that most On Demand platforms are associated with network effects/playbook evolution/solving the initial chicken and egg hurdles, etc. the case for a clear understanding of these stages is much more important. Question then becomes are we looking to validate the business model that is doing less than 1000 transactions a day or are we talking about a system that has already scaled to multiple geographies built on top of a highly optimized logistics framework.
Focus areas during different stages of platform evolution are different. The first hurdle is getting a functioning product to the market that aces the core interaction. Once the MVP is launched its often a race towards achieving that product-market fit which in itself might span multiple sprints. Once the product market fit is in sight, the next hurdle is getting the unit economics (Customer Acquisition Costs/Lifetime Values) right while constantly improving cohort data. This phase generally involves lot of focus on building the analytics capabilities.
Total cost of developing an on-demand app like Uber: