A practical way of building your first Uber-like app

Hrishikesh Pardeshi

Co-founder, Product & Dev at Flexiple ($700,000 revenue) & Remote Tools.

Last updated on20 Feb 2024

Table of Contents

We glanced through Uber’s engineering and deliberated on using tech to solve a business problem. Let’s now actually delve into writing down how exactly the first version of our Uber-like app will look like.

Listing down the requirements for our Uber-like app

By now, you would agree that a matching engine or a dynamic pricing module shouldn’t even figure in the tech discussions of our first product. Given we want to build a simple app to onboard drivers and riders and then connect them for a ride, here’s a probable set of tech you would need:

1. Intuitive, robust forms to onboard drivers and riders
2. A reliable way of storing, viewing, updating and processing information from (1)
3. A way for riders to book rides in real-time
4. Communication channels to convey information about rides (example, sharing pickup location with drivers, driver details with rider etc.)
5. Some form of facilitating money transactions

In line with this, you can probably build a simple hybrid mobile app and a web app that tackles fetching (forms) and storing data. But is there a simpler/ smarter way to achieve this?

Using existing solutions (products) to solve our business problems

For (1) and (2),

I can use a service like AirTable, which gives me a great way to store and view data (just like Excel or Google spreadsheets). It also provides an intuitive way to create and share forms, and connect them directly with the data stored in sheets.

If I am keen on giving my users a superior experience, I would probably opt for Typeform and connect them (Typeform and AirTable) using Zapier.

For (3),

I would skip it entirely and have riders fill up a form to book rides, at least an hour before departure.

For (4),

I can have automated triggers (easily available in Typeform and AirTable) on form submissions and successful payments.

Finally, for (5),

I can use a payment gateway that gives me an out-of-the-box solution and helps me generate a unique payment link for each ride. Even simpler, I would be happy to opt for cash transactions or wallet payments.

At such an early stage, your worry shouldn’t be about securing your financial transactions. That will probably never happen given you would know each of your drivers by name. And even if it does happen, it will be a good problem to solve then!

As the number of users grow, I would begin by automating manual processes and probably work on building an app in line with point 3.

Building solutions that don’t scale

The approach we have taken so far, surprisingly or unsurprisingly, works for organizations and teams of all sizes. Whether you are an individual entrepreneur building your first product or a PM at a large corporation rolling out a new, major feature/ workflow. The choice of tools/ products will surely differ, however, the fundamental approach remains the same.

I remember chatting with one of my friends over coffee about her experience at the YC program. I asked her what was the one thing of great value she learnt there. She said we were told in the first few days itself to think and build solutions that don’t scale. Once you establish and figure the real business need and how to satisfy it, you can then quite easily focus on scaling such solutions.

It seemed quite counterintuitive immediately to her then and to me when she first mentioned it. But giving it just another thought and looking back at my past few years, I realize this in fact is the golden rule of entrepreneurship.

Closing thoughts and way forward

Having said all of this, it is also important to have a good understanding of building products. Because at some point, you will be building apps and complex features.

In the posts that follow, we will touch upon the below-mentioned nuances:

1. Tech decisions/ choices you need to make and how will those shape your final product
2. Does software last forever? OR How frequently to expect updations?
3. Timeline/ estimates when building features
4. Hiring vs. contracting
5. Your involvement (and depth in terms of tech) needed at every stage
6. Ideal time to go to market/ test with real users etc.

Stay tuned!

Do reach out to me on Twitter if you would like to discuss anything.

I also write regularly about products, startups and tech. If you would like to hear from me more often, you can subscribe to my newsletter here.