5: What Goes into an On-Demand App Tech Stack?

On-demand apps like Uber and Postmates are among the more technically complex apps you can build. In this episode, Tim and Rob explain how these apps work in an easy-to-understand way.

In this episode, you will learn:

• How your mobile apps allow users to browse products/services, place an order, and track the progress of the order in real time
• Steps you can implement to save battery resources for your service providers
• Why you need a third-party payment provider to do your credit card processing
• The way you can manage all of this chaos through an administrative dashboard

This episode is brought to you by The Jed Mahonis Group, who builds mobile software solutions for the on-demand economy. Learn more at http://jmg.mn.

Recorded November 9, 2017
Edited by Jordan Daoust

Episode Transcript:

Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non-technical look at mobile app development. I'm Tim Bornholdt.

Rob Bentley 0:06
I'm Rob Bentley. Let's do the nerdy bird.

Tim Bornholdt 0:22
Today we're taking a non-technical look at the technology it takes to build an ondemand mobile app system. Very exciting stuff. Right, Rob?

Rob Bentley 0:30
Yes.

Tim Bornholdt 0:31
So before we jump into this, we wanted to just give you a quick overview of what we mean by an ondemand mobile app system.

Rob Bentley 0:39
There's a lot of different components to it. And we can start out by explaining what the users actually see, which is your front end.

Tim Bornholdt 0:45
Well, before we even get into that I wanted to just say what an ondemand system is, so really, we're talking about things like, the ultimate example is Uber, but it could be anything like a pizza delivery app or one of our apps we built is an ondemand dental staffing system, which helps dental agencies staff up their office with hygienists and assistants and dentists. So it's really any system which allows a customer to request a service or a product and receive it pretty much as fast as anyone could get it to them.

Rob Bentley 1:21
Whenever and wherever you want it to be, it comes to you.

Tim Bornholdt 1:24
It's very secure ish.

Rob Bentley 1:25
Yeah.

Tim Bornholdt 1:27
So yeah, so in an ondemand system, there are three major components to it that we will break down in greater detail. We've got the front end, we've got the back end, and we've got the administrative dashboard. So let's start with the front end of the app. So that's usually two apps. Right, Rob?

Rob Bentley 1:44
Yeah. So in the case of Uber, you have the app that the customers use to find a ride, and then you have the app that the drivers would use to be able to provide the ride.

Tim Bornholdt 1:54
Right. So first we'll cover the customer app. So a customer app typically is a native iOS andor Android app, andor a web component. It can be any of those three. It's basically whatever app or website is used to interact with the service. So if an app is delivering a product, like if we're talking about a food delivery app, that would basically allow the customer to browse the menu, look through all the products or toppings, just basically be able to assemble whatever order they want to make, then place that order and have it sent to the company to be sent to them.

Rob Bentley 2:30
Yeah. And depending on if you're doing a product or service, a product based one might have search components involved with this, too.

Tim Bornholdt 2:36
Yeah, exactly. You want to be able to search for a specific type of pizza or a specific, whatever that you're trying to get sent to your house. Conversely, if you are offering a service, so you know, the Uber example would be the ultimate one again here. You basically need to have an app that pops up, has a map out that says come here and perform whatever service you're offering. Then say, bring it on. I'm ready for it right now.

Rob Bentley 3:04
Yeah. So you'll have sort of like a card infrastructure, whether it's, I want this thing to happen, or I want this product to come to me. And then you'll end up paying for it through the app also.

Tim Bornholdt 3:14
Right. So it's very important that before this system allows the order to be processed, you have to have the person input a credit card so that you can get money from them. And then once the order has been paid for, processed, it's been accepted by the system, next, we want the customer to be able to track the progress of that order in real time. So this would be a map popping up on the screen and a little blue blinking dot for where you are. And then you've got some kind of car icon that is moving in real time, more or less, to show you the location of the driver.

Rob Bentley 3:51
And nice touches like the map zooming in closer and closer as the product gets closer to you.

Tim Bornholdt 3:56
Exactly. So once the order has been processed, it's been completed. It's been delivered; we're all done. Now the app needs to allow the customer to view past history, being able to pull up oorders and say, you know, on this date, I paid this much for this burger or this taxi ride.

Rob Bentley 4:12
And along with that, it gives them the chance to quickly reorder that same item again. Say if you get a pizza and you get a large pepperoni every time, you're just going to want to hit a button and get the order going, instead of building it all from scratch every time.

Tim Bornholdt 4:24
Exactly. It's all about getting people in and out of the app as fast as possible. That's really the end game that you want for your your customer app. And I guess at the same point, that's really the same purpose of the app for the service provider.

Rob Bentley 4:35
Right. You want them to be able to go in, use the app as little as possible, especially if they're driving.

Tim Bornholdt 4:40
Yeah, you don't want people to be actually actively looking at the app. You want them to be able to perform their service and get out of the app as quick as possible. So the service provider app, again, iOS or Android, this one would be an app as opposed to a website for most circumstances, mostly for the case because you want to be able to track their location at all times. And an app just kind of makes that easier as opposed to a website.

Rob Bentley 5:05
Right. Does this need to be iOS and Android like the customer app?

Tim Bornholdt 5:08
Not necessarily. It can be one or the other, especially if you have a fleet of your own employees, if they're full time employees, and you can say, "Hey, here's how you have to do your job." You can give them an iOS device or an Android device and just say, "This is what you're going to be using." And that will cut down on your upfront infrastructure costs, especially if you do one versus both.

Rob Bentley 5:29
Right. If you're going to require one platform, though, it probably means you'll have to buy the devices in some cases. Where if you have both, then you can just let the employees use their own device. So that's something to keep in mind too.

Tim Bornholdt 5:42
So once your driver or your service provider's inside the app, you basically have to get them a job. So one way you can do it is by sending them a notification and saying, "Here's the job; go do it." Or it could be a list of available jobs and you can let your service provider say, "Alright, I'll take this one." Accept it. Let's go and perform it.

Rob Bentley 6:02
A big one too is once they have hooked up or made the match with the customers, then their location is sent to the server.

Tim Bornholdt 6:08
Yeah, so let's say you've accepted a taxi job, you're going to drive somebody someplace, you basically want that person to know, "Okay, my guy is coming pretty quickly here." So you want to at all times... it's usually every 30 seconds or 15 seconds, you just basically have a location and it's a GPS coordinate, you send it up, and then you just send it back to the app. So then they can just watch the car driving in real time more or less as it gets closer and closer to you.

Rob Bentley 6:38
Yeah, you want to have a balance between not draining resources on the phone, but also keeping the users engaged and providing enough data.

Tim Bornholdt 6:45
Yeah, exactly. So once you have accepted the job, you've driven to that location, now you need to give the service provider the ability to mark the job is completed. And this is obviously important because you want to be paid for that person performing that job. So once the service provider marks it as completed, then on the driver's side of this system, then it refreshes back to the beginning. And it just listens for a new job or gives the driver a list of available jobs. And you just continue the cycle until they sign out of the app.

Rob Bentley 7:17
And I know that sounds like a lot, but that was actually the easy part of the whole system.

Tim Bornholdt 7:21
Yes, that's the most straightforward part. Now we're going to move on to the actual hard part, which is the backend of the system. So the backend, it performs several tasks. So we're going to cover four major ones here, the first one being matchmaking.

Rob Bentley 7:35
So this would be a customer's looking up their product or service, whatever they want. The backend has to do the job of efficiently getting the data that they want to them in as little effort as possible.

Tim Bornholdt 7:49
Yes, exactly. So basically, what the system does is it looks for the closest person that can go and do it. And so the system has to basically look and see, "Okay, where's the closest person, where's this location, let's do some checking in and then send out a notification." So you can either matchmake based on looking for one person, or you can matchmake basically by like a shotgun spray of just everybody who's available. Whoever gets it first, they get it.

Rob Bentley 8:27
Right. And each case can have different strengths and advantages. And it really depends on what your platform does and what you're going for which approach you should take. I know Uber does the one by where it tries to get one driver and then it moves on to the next and until someone requests it. But we've built other platforms that it sends out to everyone who matches the criteria. First come, first serve.

Tim Bornholdt 8:48
Yeah, it just really comes down to what works best for your situation. Sending out notifications could be its own entire topic here, but it's pretty much related to matchmaking. So basically, like we said, you can either send out a push notification to one person or send out to many. But notifications tend to be one of the trickier things to get right as part of one of these ondemand systems. So just know that that's gonna, when you're developing this out, there's usually issues, especially if you want the notification to launch to a specific page inside your app or for a driver being able to matchmake and say, like, "Yes, I accept this job." And then having it trigger all this stuff. There's a lot of components to the notifications.

Rob Bentley 9:33
Yeah, notifications are difficult on the front end, as well as the back end, because then you have to make your app respond to a limited amount of data, load data you need, and put the user on the right screen in response to whatever notification they get.

Tim Bornholdt 9:45
Exactly. So another part of notifications as part of this whole system, we wanted to talk about sending out email, and it doesn't get much more straightforward than sending out an email.You can plug into a bunch of different services that do this but you essentially want to send out an email with the receipt after the person has paid for something. Pretty straightforward. So the first piece of the backend that we were talking about was matchmaking. The second component that we'll talk about here are payments.

Rob Bentley 10:14
Right. When your front end users send up the payment information, well, this is the part of the process where it actually happens.

Tim Bornholdt 10:21
Exactly. So there's a lot to this. The too long, didn't read answer to this is, for the love of God, Use stripe or Braintree or any other component, like third party company that handles credit card processing, and this whole mishegoss. Even if they they charge a little bit of a fee, it's 2.9% usually and then 30 cents for each transaction, but it's worth every penny that you don't need to worry about things like PCI compliance, and like credit card validation and all those things that are very, very tricky with payments. Outsource that. That is not your core competency. Your core competency is getting your service or your product into people's hands as fast as possible. And having to have this extra weight of security on your back is just not worth saving a couple of percent of, you know, $1 for each transaction or whatever.

Rob Bentley 11:16
The only reason you would ever want to get into handling your own payment system is if you're building your own payment system.

Tim Bornholdt 11:23
Yeah, if you're trying to build a bank, then don't use Stripe. But if you are not building a bank, which is probably everyone listening to the show, just use Stripe. But one thing that you want to deal with when it comes to payments, and one thing that the backend handles is the whole difference between a two sided marketplace and a three sided marketplace. So what we mean by that is with a two sided marketplace, you've got your customer and you've got you and you're just taking money from the customer and that's it. Then you deal with it however you want.

Rob Bentley 11:53
Where someone orders a pizza, a customer sends you money and then you make the pizza and they pay you for it. And that's it.

Tim Bornholdt 11:59
Exactly. We're with a three sided marketplace, what you need to deal with is, you've got your customer who accepts a ride from a driver, if we're talking about the taxi example again, so you have to basically have funds go from the customer to the service provider. But you also want to take a small portion of that for yourself as the business, as the third party person who facilitated that interaction. So that's a three sided marketplace and doing something like that is a little bit more complex and something that you'll need to deal with whenever you're building out a back end.

Rob Bentley 12:35
So yeah, another thing that the server is responsible for, which isn't as hard as the matchmaking notifications and payments, but still can be a little bit of a process is authentication.

Tim Bornholdt 12:45
Right. So you have to worry about customer accounts and service provider accounts and keeping all those details separate because you want to collect essentially the same information, but it's going to vary what you need to worry about between the two.

Rob Bentley 12:57
Plus the onboarding process, especially for your service providers. And it really does, again with a lot of these things, it depends on what your product is. But in the case of a service like Uber where you have people driving and this is going to be a lot of ondemand apps, since it usually involves delivering a service or a product to someone, wherever they are. I actually did driving for Uber for a while and to be onboarded as a driver, you needed to upload a picture of your license, your drivers insurance, several pictures of your car. You had to take it into a mechanic that was on their approved list of mechanics, upload a paper of them with their report on your car saying that everything's fine. It can be a little bit more involved than just "What's your email?" and "What's your password?" and "What's your name?"

Tim Bornholdt 13:45
Well, yeah, and not just with the drivers example but if you are with Kwikly, the dental staffing app that we made, you can't just be like "Oh yeah, I'm a hygienist" and just let anyone go and start working. You have to actually say, "Okay, show me that you graduated from dental school and show me that you have these CPR certifications" All the onboarding components to it, the server needs to handle that somehow. And that's just another part of authentication is getting the users into the app. It's another component that you'll need to worry about with this.

Rob Bentley 14:19
And in the case of the three sided marketplace, where you have contractors versus employees, you have to get money to those people. So then the server also has to handle as part of that onboarding flow, getting hooked up with a bank account and making sure it's legit.

Tim Bornholdt 14:32
And making sure that they are authorized to do work in whatever country you're operating in. If they're in America, you need to make sure they have their I9 or W9 or W4.Whatever those tax forms are, you have to just basically make sure that they're able to work in the United States. So you need to get social security numbers and passports and all that kind of information. So there's a lot to deal with with that. And that kind of also goes into the the admin back end that we're going to talk about here in a little bit. But that's just another component you'll have to worry about when you're building out a back end to an on demand system.

Rob Bentley 15:07
And it's something that all businesses have to do. But in your case, you would have to have a piece of technology that can do that for you and do it accurately because you don't want to mess with the government getting involved because you weren't doing things right.

Tim Bornholdt 15:19
Right. And that's kind of a marriage between you as the person that is building the app and has all the domain knowledge of "This is how things work in our industry", and working with somebody like us who, we just build the tech. So we have to work together to really make sure that we're making all the necessary precautions of falling in place with laws and regulations that pertain to your industry. So finally, the last component to the back end that we'll talk about is rating and reviews. And that's actually the easiest part of all of this.

Rob Bentley 15:54
Yeah, that's a standard thing kind of nowadays.

Tim Bornholdt 15:56
Yeah, just accepting whenever an order is completed, making sure that driver can review the customer, because you don't want bad customers on your system. But then obviously, the customer needs to review the drivers or the service provider so that you're making sure that you don't have, you know, creepy things going on or bad things or just, you know, just making sure you're maintaining a certain level of quality. So that's it for the backend.

Rob Bentley 16:21
Yeah, that's all.

Tim Bornholdt 16:22
That's it. And we're not even done yet, we still have a whole third of the system to cover, which is your administrative dashboard. So this is essentially the backend. We would consider this to be part of the back end of the system, but I guess you could call it the front end of the back end. It's a little semantic, but that is how it is.

Rob Bentley 16:38
It's really for you, the owner, and whoever you're working with, your staff, whatever it might be, to be able to go in and change things if necessary if mistakes happen, or you just need to go in and remove a worker or add a worker or things like that.

Tim Bornholdt 16:54
Slow down, Rob, you're giving away the whole episode. Like Rob said, there's basically three components to the admin dashboard. And you can go a lot further. But the essential basics of what you need for your ondemand system, if you're building it out, you need a way to manage your workers. So part of that is making sure that there's enough supply to meet the demand of whatever system you're building. And then also the ability to suspend workers if they're getting enough bad reviews. You just need to make sure that you're able to kick drivers off and not operate inside the app if they're terrible.

Rob Bentley 17:33
Yeah, on the flip side too, like we said, it's managing the customers too. If they're customers, you can ban them from your service if you need to.

Tim Bornholdt 17:40
Yeah, and by terrible customer, usually, it's just that they didn't pay. This is essentially the customer service side of your business. This is where things happen. The other part that you're going to be able to do is offer refunds, and for whatever reason being able to tie into whatever system you have and issue a refund, to send out receipts so that they have that for their records and all that good stuff. This would all happen from your admin back end.

Rob Bentley 18:08
And then also, the final piece of this would be your analytics that you collect.

Tim Bornholdt 18:11
Right. If you're building an ondemand system, which is essentially a SaaS tool, you need to basically know - the analytics are going to tell you the health of your system. How many customers are using it? When are the peak periods? When do you need to be able to shift more demand? How many times did somebody request a service and not have it fulfilled? All these metrics, all these things are things that you build out over time, but you need to have the infrastructure in place. Basically, you need to be collecting as much data as you can. So that later on when you have these questions, you can just go in and ask your system.

Rob Bentley 18:48
You'll figure out what data is important to you. And then your tech team will be able to build out a nice looking graph to show you that.

Tim Bornholdt 18:54
Perfect thanks for bailing me out. That's what I was trying to say. So that's it. That's all the components that go into a back end system. I didn't think this was going to be that long of an episode, but it ended up being pretty decent.

Rob Bentley 19:05
Just like developing an app, right?

Tim Bornholdt 19:07
Yeah, right. It's never as long as you think it's gonna be. Well, yeah. So final thoughts. There are a lot of components to a back end, obviously, we just said, we talked for 15 minutes here about what it takes to build a back end. And it can be pretty complex. That's why you work with a team like ours, or you bring on developers that know what they're doing that can build out this system.

Rob Bentley 19:29
Yeah, not only do we have the technical experience to write the code, but we have processes in place and we have the experience to make sure that you're getting all the parts of it that you need.

Tim Bornholdt 19:38
And really, at the end of the day, building out a tech system like this, you don't need to be a technical person to understand what's going on. And a lot of our best customers aren't technical people but they know the business and they know what it takes and how all of this operates and works together. And that's your job as an owner, as a product owner. You don't necessarily need to know "How do you hook stripe in? And how do you hook in all these push notifications? And how do you handle matchmaking" That's our bread and butter. That's what we do. What you need to do is at least understand where things could go wrong and how things interact. And just basically, understanding your system as a whole is what's going to make you a successful business owner at the end of the day.

Rob Bentley 20:22
Absolutely.

Tim Bornholdt 20:23
Was that a pun? App-solutely.

Rob Bentley 20:29
You've been listening to apps.

Tim Bornholdt 20:32
Show notes for this episode can be found at ConstantVariables.co. You can get in touch with us by emailing Hello@ConstantVariables.co. I'm @TimBornholdt on Twitter. Rob is @ScottMahonis. Today's episode was edited by the delightful Jordan Daoust. This episode was brought to you by The Jed Mahonis Group, who builds mobile software solutions for the ondemand economy. Learn more at JMG.mn.