How we built a better food delivery app in less than 9 months.

“Hey, How much does it take to build an app like DoorDash?”

As a full-service app development agency, we get approached by a lot of founders about a lot of different ideas.

The common questions are always, “How much? How long will it take? What’s the process? Why is it so expensive to build an app?”

We get it…

The process is confusing and the industry is full of tech people who talk in big tech words.

So we want to set the record straight the best way we know how — by walking you through the entire process of building an app from start to finish.

We cover the process at a high level on our podcast, “How To Build An App” where we talk about different stages of the build process, and speak with founders of different apps so you can hear their stories… now let’s put all that together with a nice bow around it and gro from A-Z.

Here’s a disclaimer:

This process isn’t for the faint of heart… this isn’t for the founder who just made $6,500 on Crypto and they want to launch the next billion-dollar tech start-up from scratch with less than $10k.

This process isn’t for founders looking to take a shortcut by building an app with no code.

The process that we’ve documented here is a REAL look at what it takes. This project ultimately was built to scale as an enterprise-level system with MULTIPLE apps on different platforms and it cost hundreds of thousands of dollars.

I’m not saying YOUR app has to cost that much, but if you want your app to be successful, you’re gonna have to follow the format that other successful apps and tech companies have followed — this case study will show you the exact process to follow.

Lots of strategy, lots of creative problem solving, but no shortcuts.

Sound good?

Let’s dive in.

Oh… And if you prefer to listen, you can walk through a good chunk of this in episode 13 of How to Build An App. You can listen to that episode here.

The client and the big idea.‍

Hey everyone, meet Jay Eichelberger, the founder of FlipFlops Delivery.

Jay approached us through a friend of a friend who referred us because the idea was… BIG.

This wasn’t just an app, Jay needed an entire system to make his big idea work.

The big idea: Food delivery RIGHT to your chair or cabana on the beach.

‍

The target customer and build requirements. 

The first thing we tackle together when we take on ANY project is a thought-out feature list.

When we’re building this feature list, we’re building with the target customer in mind. We cannot stress enough how important this is… In most cases, this is the difference between success and failure.

(We won’t cover this in detail in this case study, but if you want to know more about knowing your customer, listen to Episode 04 and Episode 11 of the How To Build An App podcast.)

Solving problems for the right customer.

One of the things that made us really excited about this project is how well Jay and his team knew who they were serving.

• Jay grew up traveling to Seaside for summer vacations since he was a kid. 
• His family AND his wife’s family both own residences in Seaside. 
• Jay and his wife own two, successful restaurants in Seaside. 
• They know all of the other business owners by name.
  

This wasn’t just a dude who has a crazy idea and said, “Let’s build it!”

This is a founder who knows the market, knows the people, already operates a successful business in the target market, and knows all of the restrictions, guidelines, etc that would be hurdles for anyone else trying to serve that area.

These hurdles are SO BIG, in fact, that Uber, UberEats, and DoorDash don’t even operate in this stretch of beach.

(Seriously… we sat at the airport for 2.5 hours trying to catch an Uber…)

The coolest part? Jay had actually dreamed about launching this app since he was a teenager. This app concept was even his college project.

Takeaway number 1: Know who you are serving, know your market, know the players, and have a CLEAR understanding of the roadblocks you’ll face when you’re launching your big idea.

Mapping our build requirements.

Jay and his team gave us pretty specific build requirements. Here are some of the highlights:

• The app needs to show EXACTLY where the user is located — even if it’s in a park or on the beach — so our runner can bring the order right to them, wherever they are. 
• Seaside is a big family vacation destination, and it’s rare that an entire family wants food from the same place. The app needs to allow users to order from multiple restaurants in ONE single order. 
• The app needs to split payouts based on items ordered, and from which restaurant they are ordered. 
• The app needs to integrate with EVERY possible restaurant’s point of sale (POS) system. 
• The app needs to have a flexible ordering process because each restaurant is going to have a different type of menu. It’s important that a restaurant can sell its ENTIRE menu on the app.
  

Big Idea #1: Allow users to order food from multiple locations in one order.

The goal was specific: Allow families to order food to them at their cottage or beach chair.

Here’s the thing… how often does EVERYONE in a group or family want food from the same place?

So if we really wanted to make this an easy, seamless, and enjoyable experience, we knew early on we had to crack a very important feature:

A food delivery app that allows the user to order from MULTIPLE restaurants in ONE, SINGLE order.

This is a pretty breakthrough kind of feature — in fact, this is one of the things that made us really excited about taking on this project.

The problem: How does one order communicate to multiple restaurants?

As we started getting under the hood on this particular feature, we realized why no one had tackled a build like this…

To put it lightly, this is COMPLICATED.

On the user’s side, it’s pretty simple: Pick food from more than one place, add it to your cart, checkout at the same time.

What’s the big deal?

On the back-end, this is a nightmare…‍

When an order comes through, we have to split the following to each location:

• Food items
• Fees
• Taxes
• Tips 
• Which restaurant pays the runner?
  

And on top of that, the app needed to do all of this in reverse as well in case an order was refunded.

The ah-ha moment: Rethinking how menu items are grouped.

When we got down to it, this became a data structure problem at its core.

The problem with the typical ordering structure, and the thing that wouldn’t allow this feature to work as intended, was the way the orders were structured in the first place.

Typically, when an order is placed, everything is grouped under a parent category — the restaurant.

Think about when you’re in a big group eating dinner and it comes time to split the check — everything is grouped under one TABLE or party with multiple items in that order… 

The breakthrough: Modular data structure.

We figured out that we could make each order item a self-contained piece of data.

Every item on the order would have its attributes… (more on this later) but that individual item would be floating in the overall order and not NESTED under a restaurant.

The restaurant and location would simply be an ATTRIBUTE of the order so we could trace payouts, etc. 

Insights and Takeaways: Your app is like an iceberg. 

If we work together building your app, keep in mind that there is a LOT going on behind the surface.

This is where app budgets can get out of control quickly… If big features like this aren’t mapped out in advance — imagine if we had the app 90% complete before we realized that the data would have to be structured in a completely new way?

This would be like building a house, getting your permits, drawing up plans, pouring your foundation, putting up walls, and when you’re getting ready to paint going to the general contractor and saying, “Hey I’d actually like to extend my basement out another 25 feet! Can you just make that happen?”

Way too late…

Proper planning and working with a pro is the best way to maximize your budget.

Big Idea #2: Allowing any restaurant out there to upload their entire menu to the app.

The goal: Allowing any restaurant to have their entire menu available for purchase — no matter how complicated.

The town of Seaside has AMAZING food — there aren’t any chains and the city doesn’t even allow COMPETING restaurant concepts — every restaurant has a monopoly on their specific type of food.

And so each restaurant has AMAZING food…

With LOTS of options when it comes to ordering.

Think about ordering a crepe for example:

• What toppings do you want? 
• Do you want EXTRA of anything? 
• Is there anything you DON’T want on there?

The problem: Building a content management system that allowed for lots of customization… without making the data scale exponentially. 

It’s one thing to HARD CODE a complex menu in the back-end of an app — meaning that a single location could just give us their entire menu with every possible variation and we would make all of those options available to buy. 

But we weren’t trying to solve a problem for just ONE location… 

We needed to build a dynamic solution that would allow for any restaurant to come on board and not be forced to offer a limited menu. And if each restaurant had a complicated menu with lots of options, the overall options in the backend would grow exponentially.

And on top of it, we needed to give restaurants the option to upload their own menu items. 

That meant we had to create a CONTENT MANAGEMENT SYSTEM (or CMS) where the menu items and all possible variations could be managed.

The ah-ha moment: Products, Variants, Options & Add-ons.

The solution came when we broke down how menu items and options were organized.

We allowed each menu item to have various customizations in the form of variants, options, and add-ons.

• Products: The actual item on the menu (IE: A bowl, sandwich, fries, etc.)
• Variants: The TYPE of item you are choosing (Size, flavor, meat, etc)
• Options: Which ingredients get added to the product (Add bananas, only gluten-free, etc)
• Add-Ons: What ELSE do you want? (Do you want fries with that?)
  

This solved our data problem as well because this meant that the order was BUILT with pre-set options rather than SELECTED from a pre-made list of options.

The breakthrough: Hot dogs with lots of options. 

This is one feature that could have blown up this entire project if we hadn’t started using REAL data right away…

In fact, when we had the VERY first version of this feature up and rolling, we used a simple item off the menu — sandwiches.

We had the process down and it worked flawlessly. So we asked Jay and his team to try and break it.

“I’ve already broken it… we have bowls.”

Their bowls were a big part of their menu and they were VERY customizable.

So many devs will build their features with sample or “Lorem Ipsum” data and everything works great…

This makes for great “Dribbble Candy” but so often it falls apart in the real world with real data.

After we solved this for one restaurant, we asked Jay to look at other menus.

The other menu options were a BREEZE because we had already solved the problem with the MOST COMPLICATED, fringe case out there.

Insights and Takeaways: Know upfront if you’re building an enterprise app or a single-user app.

When you’re building your app, you gotta know RIGHT from the start if you are solving a problem for one location and one customer, or if you have to create a platform that works for lots of people.

This one distinction will have a huge impact on your budget and your timeline.

According to Forbes, this is one of the attributes of an Enterprise Application:

“Agility is key for an enterprise app. Enterprise software should be able to connect easily to the rest of the business, its customers, and ecosystems.”

Source: Forbes.com

Big Idea #3: Integrating a food delivery app with every restaurant’s current point of sale system. 

The goal: Rolling out FlipFlips to LOTS of restaurants.

The big idea with FlipFlops is to serve lots of restaurants and eventually serve lots of small communities with similar needs.

So we knew that we had to build with scalability in mind.

The problem: Communicating orders to the restaurant staff.

Something that came up very early on in the process was connecting the FlipFlops orders directly to the restaurant in a way that would be seamless for everyone and where no orders or tickets would be missed.

So how do you integrate with the restaurant?

The first path we tried was integrating directly with the point of sale (POS) system at each location.

After some initial discovery on this process, we realized that this would be a complicated and expensive option. There are LOTS of POS systems out there, each restaurant uses something different, and these systems aren’t super open and friendly.

In some cases, we not only would have to APPLY for the privilege of integrating with their system, but they would be the ones to build the integration, and then they would charge us for their time.

We realized pretty quickly that this feature would cost $100,000 — $500,000+ to build properly.

The ah-ha moment: What do all restaurants have in common?

This solution required us to stand back from the keyboard and think about the problem from the restaurant’s point of view… What would be an easy way to integrate with restaurants in a way that DIDN’T involve tying into their POS system?

The breakthrough: A $179 solution to a $500,000 problem. 

Almost every restaurant out there still uses paper tickets for their orders.

We found an open-source thermal printer that we could easily buy and place in each restaurant and location. The orders come in through FlipFlops and get printed out right on location.

Insights and Takeaways: More code isn’t always the answer.

Some problems can only be solved with code. Other problems have much simpler solutions.

As you’re building your app it’s important to remember that the whole goal is to solve problems — not to write code.

Your code and your features should solve the bigger problem. Sometimes there are simple answers that can save you time, money, and energy.

Delivery to the beach. ‍

This writeup is just scratching the surface of everything we had to tackle and all the problems we had to solve to make it possible to deliver food right to someone sitting on the beach. 

In the end, this project turned into 7 total apps, and an incredible system that is robust enough to not only serve the city of Seaside but serve other beach towns as FlipFlips scales up and expands its target markets. 

The project was a whole lot of fun… but the most exciting part? In April of 2021 we took a small team down to Seaside to see FlipFlips in action. 

We ordered food right to our beach cottage and it was delivered by none other than Jay Eichelberger, the founder of FlipFlips Delivery. 

This was a huge blast to see this project come together and working in real life.

How much does it cost to build an app like DoorDash?‍

So how much did the project cost? We don’t want to share exact budgets, but you could expect an app of this size and scale, with multiple iOS and Android apps, and a powerful web app for administrational use to cost between $500,000 and $1,000,000 when it’s all said and done.

How long does it take to build an app like DoorDash?‍

This type of app could take years to build. We are proud of the fact that we had it up and running in less than 9 months from idea to launch.

Conclusion.‍

There is not a one-size-fits all solution for building an app with enterprise-level scalability. The process is a journey. If you’re going to bite off an ambitious project like this, make sure you have a great team in place and you have the capital in place. 

That being said, not all apps need to be as ambitious as FlipFlops in order to find success. There are a lot of ways to start smaller, more streamlined, and more focused to get an initial user base and THEN scale up your build from there. 

Whichever route you choose, you’re going to need a great team on your side. If you have a brilliant app idea and you need to assemble your brilliant team, schedule a strategy call with us. Maybe we can build something really great together. :)