Want to develop an Uber like app? Know the cost

How much does it cost to develop an Uber like app? We come across this question almost always when we think about app development for building uber like the app. The answer always is – It depends!

Uber’s business model has given rise to a large number of On-Demand Platforms being adapted for different verticals. The demand for taxi apps like uber and uber clone app has grown eminently in recent times. Many entrenched industry value chains stand to be disrupted. The online-offline nature and involvement of multiple stakeholders make these platforms difficult to design, master and scale for uber like app development for your business.

Related Reading – The Uber Business Model

Entrepreneurs and enterprises looking to build uber-like apps for different verticals often find this analogy easiest to articulate and hence the genesis of the question. There are several variables associated with getting to a correct estimate to make an app like Uber. Let’s have a quick look at these variables to understand what goes into designing an Uber for X platform. I am confident this will also lead to a better appreciation of why we as JungleWorks took a modular approach and designed an MBaaS (Mobile Backend as a Service) architecture to create a winning value proposition for entrepreneurs/enterprises looking at making an uber like app / uber clone for their business.

Generally the cost for the initial MVP for an app like uber is upwards of $100k-$300k, however, while taking the JungleWorks approach it can be as low as $40k – $80k.

A) Is your business model exactly like Uber? If not, how does it differ from Uber?

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 uber like the app:

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 a 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 app like uber 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 application development 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 24 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.

The underlying premise is that the front end needs to be custom developed. Leveraging the proven backend architecture ensures that we are not reinventing the wheel when it comes to deeper customizations/corner cases.

Uber-like app development

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. The 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.

How to make an uber like app?

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 it is 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 a lot of focus on building analytics capabilities.

The total cost of developing an on-demand Uber like app:

By now it should be clear that the cost of making an app like Uber depends on numerous factors. But here’s an attempt at the estimate. Building an MVP for an On Demand Platform involves creating web/mobile interfaces for both supply and demand. Add to this the fact that native experiences are the expected norm leading to parallel development efforts if we chose to build both for iOS and Android. The other important component is the nerve centre/admin panel that doubles up as a CRM and a Dashboard to control some of the critical operations. Everything is glued together by the APIs that operate on top of central databases and control logic – part of the backend framework that runs in the cloud.

Assuming the platform architecture is scalable and is able to handle 500-1000 transactions a day right away we are looking at an upwards of $100k-$300k effort for an initial MVP. Variations in the ballpark primarily are on 3 accounts

Number of stakeholders
Number of platforms that are part of the initial launch
Complexities in the business model
Geography/ Region out of which your development team operates or engineers the product.

Per hour rates vary from $20 -$60 (parts of India/Eastern Europe/South East Asia) to $80 -$150 (parts of Western Europe/US).

With a modular approach that takes advantage of pre-built IP, we at JungleWorks are able to reduce the time and cost involved by around 30%. In addition, since JungleWork’s engineering teams are based out of India we bring a huge cost arbitrage to the table while still ensuring smoothness in communication generally associated with in-house teams. The engagement processes have evolved over more than 5 years of distributed product development. All in all the costs for an MVP while taking the JungleWork approach can be as low as USD 40k to USD 80k. But more than the cost advantage the bigger value proposition that we bring to the table is experience drawn from doing more than 50+ On-Demand Platform in different geographies and domains. This makes the approach consultative wherein at every step, we draw from the playbook of many successful implementations that we have been associated with directly and indirectly.