How to Make an App like Uber: A Million Dollar Guide

Do you want to build an app like Uber? If yes, you may have been advised against building it as there are 2000+ such applications. Do you know that in 2015 Rob Sadow saw a huge problem with the **on-demand car pooling industry**: 1. 85% working professionals were driving themselves to work each day 2. And, they contributed 6.2 tonnes of CO2 Rob wanted to fill this gap and launched his own mobile app. Shortly, after 4 months of launching the application, Rob saw a whopping 20,000 plus rides and received $5.2 Million in funding. > Now, most people may have never heard about Scoop before, and there are similar gaps that on demand applications can fill. Unfortunately, many entrepreneurs do not know how such apps are built, and unknowingly ignore the benefits of building such applications. ### What will you learn here: **1\. Features and technology required to build an MVP** **2\. How to implement those features** **3\. Building the perfect backend for your application** **4\. Selecting the marketing tech stack for your MVP** ![](https://upscri.be/media/form.jpg) An app like Uber, even in it’s most basic form should be able to allow users to request rides and make cashless payments. The entire ecosystem should provide real-time interactions between the server and application and process payments automatically upon completion of rides. On top of that, refunding and rating drivers is another crucial factor to build an economically viable marketplace. **Let’s look at these important features for MVP and how you can build them.** ● The first feature that comes to everyone’s mind is, real time tracking and notifications. Building which requires optimising the code for performance, socket programming and communicating with various Google Maps APIs. ● The app should also allows users to register using the mobile. Backed with the proper security setup, the details a user enters will then be stored on the database designed for this application. ● To request a cab, the app utilizes Google Maps to allow users to drop a pin upon the map. As the passenger confirms a cab request, a notification is sent out to the closest drivers. The distance, ETA can be easily returned using Google Map APIs. ● When a cab is booked, a push notification needs to be sent out. The app’s server component can either be custom created or can be implemented using 3rd party providers. For an app MVP we prefer Amazon’s SNS, as it is lightweight and costs little to nothing to the startup. ● Sending Push notification also requires SSL connection, which may feel be the hardest part of implementation. ● In order to facilitates payments via application, Braintree provides SDKs for both iOS and Android. Integrating those SDKs allows you to auto-deduct payments, invoicing and make refunds. To start billing of a ride, the app can leverage motion detection. > In short, your first MVP product should be able to let users request a service(ride), send push notifications, process real-time payments and use Google map API to pin a location. This all can be possible on a scalable and reliable backend architecture. Of course! This was just an overview… it takes a lot more to build an app . Unless you are a Polymath, you need to hire developers with the following skills: 1. Mobile Apps: Objective-C, Java, Swift 2. Backend services for the apps: Node.js and PHP 3. App databases: MongoDB and MySQL **Now, what if…** Let’s assume you’ve built the app with the best possible technologies available, and your app is so great that it is built on top of recommender algorithms to completely automate your tasks. But.. you later discover that the you need to pivot the product to survive. But now that you’ve exhausted your budget, you can’t pivot to reach the product market fit. **Truth to be told…** > You don’t need an exact Uber technology to test the hot waters and acquire users. You need a minimum feature based product to test if you are heading in the right direction, and then build more as you progress. During it’s initial phases Uber didn’t had a state of art architecture, they used to build as they progressed. **So.. what tech stack fits well for an MVP?** A simple app built on top of the following will easily be able to handle thousands of users and permits scalability during sudden surge: 1. High performance natively built consumer facing apps on programming languages like Objective-C and Java, one can also use Swift here. 2. Well optimized stack of web services on PHP and/or node.js 3. Well designed database storage on MySQL + MongoDB will be able to handle the loads easily. Back in 2011, Twitter used to rely on a simple stack of MySQL to process 250 million tweets. In this case MySQL and MongoDB can easily handle any sudden surge. **But software development is risky…** That’s why we go for MVPs and proper project management methodologies. Here’s what you should do for proper planning and execution of app development plans: 1. Divide your projects and tasks into priority order. 2. Ensures tasks have been assigned properly to the designers, developers and project managers. 3. Creates deadlines for each tasks 4. Lists the top 5 priority tasks for each of your team member. 5. Remain up-to date with the project progress, problems and iterations 6. Talk to your development team and be an active part of the development process ### Building the perfect backend for your application People learn from mistakes, but you haven’t made one. So, how would you learn? > We have built hundreds of applications, some of which made it to millions of users within a month. The teams working with us often panicked, we spent nights fixing the architecture which was supposed to handle massive users. That was back in 2011, startups rarely cared for scalability of backend and features when they were into MVP phase. During those days even Uber was struggling to cope with surges. **Post 2011, Node.Js happened…** **Building real time location, display and tracking** To build so functionality, you need to focus more on data extraction and optimization. 1. **Do you know that an Uber like app communicates with the server after every 4 seconds to provide real time information?** _Depending on how accurately or loosely you wish to track the cab’s location, you can change the frequency of communication._ 2. **In case if you are wondering, the app frequently needs to communicate ETAs, GPS location, calculate the shortest distances, and other information that may be required.** _The app utilizes following APIs to collect information: Google maps direction API, Distance matrix API, Geo-fencing, Google Place API, Google Maps Geo encoding API._ 3. **This is going to be the most important part of building a real time experiences. A half-duplex-socket that could push real time information between your servers and mobile apps.** The reason why these protocols are so important is because they help reduce the communication overhead. In absence of sockets, a port has to be opened and closed whenever server receives a request. Also, HTTP protocols were built to pull data, and if a server wants to push data it has to poll. Unlike these HTTP protocols, a socket connected to a server always keeps a port open to allow easy exchange of information. 4. **Concluding this, you should have Nginx as your web server. Apache is another popular server, but it doesn’t performs well with real time, dynamic information.** ### **Processing Payments through the app** ![](https://hackernoon.com/hn-images/1*bc5kBUfy5JWRug2L6w9gnQ.jpeg) Braintree is a preferred payment gateway for such application, in the next 2 minutes we’ll show you why: 1. Do you know that up to $50,000 total in transactions, Braintree won’t charge you anything? How awesome is that? 2. Another reason for using Braintree is that it facilitates auto-payments, refunds, monthly/weekly/bi-weekly recurring payments. And in case, if you are looking to add a split payment feature, Braintree also helps you integrate this functionality. 3. “_But I want to build my own Payment gateway…_” Wait, before you even think of that idea, kill that thought! It is not feasible to build your own payment gateway while being a startup. There are many compliance, complicated technologies and high costs involved. We would advise using an existing Payment Gateway. 4. _But what about data security?_ _That PCI Compliance thing_…Most app developers will tell you not to worry about it because most of the Payment Gateways are PCI compliant. While registering your account with a Payment gateway, most of them ask you to fill and submit a PCI SAQ\_A-EP form. This is a part of self auditing your data security and declaration that you’ve followed compliance. Even if you don’t know tech, please talk to your developer and make sure that you fill the right details. > **A word of caution** you still need to make sure that you are doing your part of data security and self auditing. The moment your app completes 20,000 transactions, you will be under VISA’s radar. 1. If it seems like a lot, don’t worry there’s little left. Ask your developer and make sure that he integrates the SDK properly with your app. Developers often integrate PG’s API rather than integrating the SDK with Mobile app. > This is a poor implementation and leaves sensitive information flow through vulnerable networks. **Other than that, you need to:** 1\. Make sure to use SSL encryption 2. Never store any credit card information locally 3. Use Braintree iFrames whenever possible ### **Scheduling and booking rides** ![](https://hackernoon.com/hn-images/1*KLIKWuTm2716ph-2vg2cOg.gif) Lyft The ride booking or scheduling mechanism can work in two ways: 1\. When an user requests a ride, the request goes out to the nearest highest rated driver. The driver then receives a notification upon which he can choose to respond or ignore. If he chooses to ignore, the request will go to the next nearest driver. OR 2\. When an user requests a ride, the request will go out to all the drivers in the proximity. Whoever accept first will be awarded the ride. A simple scheduling algorithm that has been well optimized for such an app looks something like this: F**ormula: 0.7\*driver’s proximity + 0.9\*driver’s rating + 0.7\*UPR + 0.4\* route traffic** ### **Building backend services using PHP and Javascript** ![](https://hackernoon.com/hn-images/1*EMvZ96oQx1qJnw4ps1okBA.png) What’s ideal is not always right. You can always build the entire stack on node.Js, but such an implementation will bring in additional costs that could be daunting for a startup business. > A perfect backend for such app would have web services built on top of PHP and Javascript. A complete node.Js backend would involve using two or three MongoDB servers, which may increase the operating cost significantly. By building some of the web services on PHP, you reduce operating cost by including MySQL. Also, PHP works way better with MySQL than Node.js. > So, Two or three MongoDB servers along with MySQL and PHP/Node.Js would make a perfect backend to test your MVP. **Node.Js is really really important for building real time applications. The usefulness of node.Js is best described below:** 1\. In terms of handling real time features, it does so by sending an asynchronous task to the event loop, with a callback function and then executes the rest of the program. 2\. It again speeds up the work using realtime websocket running over TCP, reducing the any delay caused by HTTP. Next, you need to have two separate PHP-Laravel based implementations to build the web app and a REST API. With such an implementation, any future upgrade is easy to push, without the need to need to upgrade the web application. ### **Building a scalable architecture** ![](https://hackernoon.com/hn-images/1*EW7BA8uF7ghJ4sDLyhYHeQ.jpeg) Uber started with a simple LAMP(Linux, Apache, MySQL and PHP) stack when they started. **The result…** LAMP stack couldn’t deliver due to performance issues and double dispatching, Or, in words of Curtis Chambers of Uber LAMP stack > Leads to issues with double dispatching > — Curtis Chambers, Uber They had to quickly change and build something new, as they further faced the issue of scaling. Put simply, this is where we need node.Js. A simple highly scalable backend architecture looks something like this ![](https://hackernoon.com/hn-images/1*iB60SN_O963CxWDpJOri2w.png) Understanding this architecture is really easy. We are separating three components from each other: 1\. Services to store and handle real time location based data 2\. The real time logic 3\. The business logic Let us explain what we mean by real time logic and business logic. Anything that has to do with payments, invoicing, sms, and other business related stuff is usually deployed on a server which we will call business logic. This portion also handles the third party SDKs and APIs. Anything that has to do with real time data and tracking, notification will then be taken care by our “Real time logic” which has its own server and operates independently of the business logic. _90% of all incoming data in such apps is location based information._ This data should be stored on MongoDB servers, so that web services can request the information only when the need it. This architecture also prevent total system failures. Imagine a scenario, where you third party payment provider has failed. Your system currently loops around to get a response. The ride has already been finished, and the driver can’t be assured of the payment as the system is unresponsive, neither can he pick up another ride. With logic separation, both systems can operate independently. And failure of one won’t bring in a total system failure. A user will find a system slow if the response rate is below 500ms. The proposed architecture has the potential to deliver as low as ~200ms as response times. The app at a glance now: 1\. Developed with Minimum viable features 2\. Optimized for performance 3\. Optimized for scalability Your future growth now depends on the type of users you acquire and the KPIs you’ll set for them. It’s highly unlikely that you’ll be able to see your users use the application. Then, how will you understand what they are doing inside of your app? How will you make sure that you are acquiring the right users? How will you know why that user uninstalled your application? In the next question, we hope to answer some of your questions. Marketing tech stack for an app like Uber To build a high performing market economy most of the decisions that app developers take should be based on user behavior. The first step in understanding your user’s behaviour is to… ### **Segment your app users and monitor KPIs** Dividing your app’s users into different segments allows you to discover differences in their behaviours. For example, you may observe a 100% increase in rides, but what if this increase is coming from only two out of four segments. > Upsight SDK allows you to discover your users, understand their attributes and build segmentations. After creating segmentations, you can perform targeted marketing and check the results. Upsight provides metrics explorer which helps developers understand how different variables affect their core KPIs. Upsight allows you to build KPIs specific to each user segment. Some of the common growth KPIs that you can extract using Upsight are: 1. Monthly average users 2. Daily average users 3. Average revenue per users 4. Total number rides by segments/users **Crash reporting** Crashlytics is one of the most preferred and used crash reporting tool being used by startups. Whenever your app crashes, you can get the crash analytics real time with a beautiful insightful reporting. We recently did a research on top performing apps on Playstore, Crashlytics was one the most used tools for 90% of the category defining applications. **Providing in-app customer support** App stores do terrific in terms of distributing your apps to billions of users, but they often bring in a huge disconnect between app developers and users. Most of the time, a user frustrated by an app would end up leaving one star review to reflect the dissatisfaction. This reduces an app’s discoverability in the app store. **Providing ZenDesk based in-app customer servicing helps reducing this gap by directly putting user in touch with the app’s developer. Some other benefits of using ZenDesk are:** 1\. ZenDesk automatically collects the device information, which otherwise would require frequent back and forth emails, that often ends up frustrating customers. 2\. ZenDesk also has a companion mobile app for support teams, which provides an easy to use micro blogging like website experience. The only thing many have against ZenDesk is the involvement of support tickets. And, that’s why the rest prefer using Intercom. This is completely subjective. **Growth hacking — Getting more app reviews and ratings** Asking for ratings and reviews is important. A common bad practice that we see is to prompt a user after completion of some number of events. This often feels intrusive and frustrating to most app users. By now, you should know that happy users are less likely to put a review, an angry user is most likely too. The only thing we suggest you to change is “The way of asking”. Use Apptentive… Apptentive utilizes a proprietary algorithm to identify user sentiments and prompt users at the right time to get desired ratings **Reduce app uninstalls** Uninstall.io is an analytics tool that helps app developers understand important signals which leads to high uninstall. It helps you reducing app uninstall by: 1. Identifying problems that users face within the app, or frustrating features/experiences that are causing these uninstalls. 2. Identifying advertising campaigns that do not retain users and are extremely expensive. 3. Finding users who uninstalled your app and provides a channel to re-target the lost customers. **A/B Testing** You may have done your research well and have narrowed down to the features to reach product-market fit. But what if you couldn’t decide between two features closely and want to test them as quickly as possible, without frustrating your entire user base? Using Optimizely SDK, you can divide your app’s user based into different parts. These parts will then see different features. You can collect information on what features are performing the best, what don’t work and take your product development strategy forward using these insights. **Adding the element of virality** Remember when you got that text/Whatsapp from someone you know about a free ride for using Uber for the first time. To influence the buying decisions based on trust, we recommend using Appvirality for Referral marketing. The best part of using such tools to market your app lies that it takes the referrer’s authority not just to the contact, but also to their social networks. Appvirality analytics dashboard provides a data driven approach for target marketing by using invites, clicks, install and revenue to channel efforts. **Drip emails** We consider using drip campaigns as a vital part of building a ride sharing marketplace. As a marketplace never remains stagnant, it grows and requires the customers and users to grow with it. Drip email marketing software makes it very easy to schedule drip email campaigns. Depending on your target audience, you can push re-engagement emails, email about new updates and features within the application, keep them training with growth hacks/good practices concerning your marketplace and share customer stories to keep them motivated. Still struggling with your MVP, Say hello on [Twitter](https://twitter.com/mihir_simform).

How to Make an App like Uber: A Million Dollar Guide

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

@mihirshah_

RELATED STORIES