The Unscalable Truth Behind DoorDash’s $100B Empire with Stanley Tang

Chances are that the competition you're facing is not Uber or Postmates. It's— you're probably dealing with a restaurant that has probably never even heard of any of us. You know, the competition you're really competing with is existing consumer behavior of ordering takeout or not ordering delivery at all.

The Library of Alexandria was an attempt to capture all human knowledge. Fire and war destroyed it. Today, we try again. Welcome to the Library of Minds, where you'll learn the frameworks and mental models of the world's greatest thinkers. And when our conversation ends, yours begins. Each guest has created a digital mind on Delphi that you can talk to anytime, anywhere. I'm Dara Lajevardian. Let's dive in. Welcome, Stanley Tang, to the office. Co-founder of DoorDash, chief product officer, now head of DoorDash Labs, where you're focused on robotics and automation. I'm super excited about this, but can start at the very beginning. You know, in your life, you started computing at the age of 3. You were a bestselling author at the age of 15. You had a 6-figure business in high school working on internet marketing. It seems like you were early to a couple trends, and I'm curious, What about your upbringing made you spot things before others, or was it just straight curiosity?

Yeah, no, that's a good question. I think I was very lucky. I grew up in a household that really embraced technology and this idea of just trying different things out. Like, so my dad's a physics professor. So at a very young age, I remember I was 3 years old when he first brought home a computer. I remember, so as a kid, I was always surrounded with computers and I remember just being hooked to like just playing with like, I don't know, Microsoft Paint and making like PowerPoint slides, making websites, all that. And my dad always encouraged me. I mean, he's a physicist. So one of the things he really emphasized was just this whole idea of experimenting with things. Just like you're not gonna know what you like unless you try it. So as a kid, like he really encouraged me to just try a lot of different things and see, you know, explore different hobbies and and versus like kind of just pigeonholing you into like, oh, this is what you have to do, right? So this is like a pre-planned like career or life that I kind of been assigned to you. So yeah, just experiment a lot of different things. And I think I just fell in love with technology and computers and the potential of tech and software and the internet.

So the story goes that you and your co-founders couldn't get food delivered to your Stanford dorm. And I'm curious, at the time, were you guys actively looking for startup ideas or did this just come up as something so obvious that you just had to start it?

Yeah, well, the founding story is actually really funny and really interesting because we were actually weren't trying to start a company, but actually it came out of a class dorm room project. You know, the project had nothing to do with food or delivery. It was about how do you apply software to the world of local small businesses. So this was like 2013 at the time. I think the hot thing back then was like, you know, mobile apps, social apps, Snapchat, Facebook, Instagram. But no one was really focused on building software for the physical world. Like, what about the local businesses down the street? There's like, for the vast majority of these, again, this is back in 2013. They're run on pen and paper, no technology, no software. And so we felt like that was an interesting opportunity is like what our software can build for that audience. So as part of the project, we would go and interview a bunch of small business owners around Stanford. So Palo Alto, Mountain View, San Mateo, just door to door. We'll go in and say, hey, we're a bunch of Stanford students. Doing a class project, you want to talk to us? So we spoke to flower shops, furniture stores, restaurants, boutique retailers, you name it, all across the spectrum. And I remember it was at a one day at a macaroon store in Palo Alto when we first encountered this problem around delivery. I remember the owner, Chloe, sat down with us at the time. She started explaining to us, oh, she's getting all these delivery requests from her customers., but she has no delivery drivers to fulfill these orders. She's a one-woman shop. She would go do it herself, otherwise she has to reject it. So this is why the vast majority of business, local businesses, including restaurants, don't offer delivery. And so, and we spoke to a coffee shop in San Mateo. We heard the same thing. It's a, you know, we heard it from flower stores, especially during Valentine's Day. And so we thought maybe that's the idea we should be pursuing. Like, it seems like there's an opportunity to, instead of just building maybe this piece of software, that these businesses want isn't a piece of software, but actually a service. It's, so whenever you get one of these delivery requests come in, they should be able to call a service that is optimized for local, you know, last mile delivery. The idea is like instead of each of these businesses hiring their own drivers, we would create a shared pool of delivery drivers that all these businesses can tap into. Like that's kind of, Yeah, that's what we should be, that's what these businesses need. So that was kind of the initial light bulb moment for us. And so we thought, well, what if we built an experiment instead? And this experiment was very straightforward. The idea was, okay, why don't we put together a simple landing page? So one single page static HTML website where we found a bunch of restaurants we liked in Palo Alto that didn't offer delivery. So we compiled it into these PDF menus, we threw up on this website, and all this website said was, if you want to order delivery from these 8 restaurants, call this phone number. And it was a Google Voice phone number that ran the cell phones of the founders. And the whole point of this website was, if we put this out there, how many phone calls we will get? It's not a, it was essentially, it was a fake delivery service, but the idea was to see how many phone calls we'll get. It was a data collection exercise. And then we can use that data to then support, oh, there's demand for delivery, therefore we should go work with these restaurants to build something. I mean, that's as far as we thought, nothing further. And then literally like an hour later, we got a phone call. Like we picked up our phone, it was the Google Voice number on pollo2delivery.com. We picked up the phone call. First of all, I have no idea how this this person found this website. I mean, even to this day, I still have no idea how because we haven't told a single person. So he literally must have just typed in palotodelivery.com. We picked it up and yeah, it was this guy somehow he found our website. He wanted, I remember his exact order. He wanted shrimp pad thai and egg rolls from this restaurant that unfortunately doesn't exist anymore called Bangkok Cuisine in Palo Alto. And I remember in that moment, we were kind of taken off guard a little. Originally we were supposed to tell, the original plan was to tell this person, oh, this is not a real delivery service, it's just a data collection exercise so that we can complete our class project at Stanford. I think in that moment, this guy seemed really, really hungry and we kind of felt bad telling him this is not a real delivery service. So I certainly did not have the guts to tell them it was not a real delivery service. And so I said, hey, what about my co-founders? Do you guys want to tell them? And they didn't want to tell them either. So we said, oh, you know what? It's just one delivery. How bad can it be? Why don't we just do this delivery ourselves? We can actually learn about how this whole delivery thing works. Not like we have anything better to do. So we literally just placed a, we picked up the other phone, called Bangkok Cuisine, placed a takeout order. We got in our cars, drove over ourselves, picked up the food, and delivered it to that customer. So I remember the exact date, it was January 12th, 2013. And that was the start of PaulToDelivery.com. And the next day we got 2 more phone calls and we decided, okay, well, we'll take those 2 as well. And then it became 3 and then 5. And the next thing you knew, like the whole, PaulDelivery.com just went viral on campus. Everyone was ordering. We were the delivery drivers going back and forth. Again, up until there's no technology and this is literally just Google Voice phone calls. And then on the other end, we're just placing the takeout order ourselves over the phone and we're just coordinating everything through texting and Google Spreadsheets and things like that. So that was how That was how DoorDash got— well, later it became DoorDash, but that was how Pollozzo Delivery got started. Love that.

You didn't even expect it. So in 2013, people thought food delivery was not a great business because of margins and also the complexity of operations. At the time, were you kind of maybe overwhelmed by the mission that you had in front of you, or you guys were not even thinking about the complexity of operationalizing all this with software.

Yeah. And honestly, none of that mattered in the beginning. In the beginning, the only thing that mattered was just serving the customers you have or people use the phrase product-market fit a lot. The most important thing in the beginning is are you solving a customer problem? In this case, there was a clear customer need for both sides. For the consumer, they wanted delivery and for the retailers and restaurants, they wanted to offer the, they wanted to have the ability to offer delivery because it was a way to expand their reach and grow their business. So we've kind of found this perfect customer problem to go after. And at the time it was, and it was an unmet need as well. There wasn't really anyone solving this problem for both sides. I mean, there were like companies like Grubhub and Seamless that existed back then. Kind of these legacy food delivery players that actually weren't really delivery players. They were actually more like marketplace aggregators. This is kind of where we were able to kind of fulfill that unmet need for them is, you know, we're not only, it wasn't just listing your restaurant on a website. It was, we can actually power the delivery as well. Yeah, that was kind of the the initial focus is like, are you solving customer problem? You got to get product market fit. Is it unmet need? And there aren't any existing players that are really equipped to solve this. So that's kind of how, that was really what allowed DoorDash to take off in the beginning.

And what is the point where you switch over from doing things that don't scale to operationalizing with software? Because Obviously if you do it a little bit too early, maybe you learn more data and you have to rebuild the system, or did you just not care about rebuilding things?

Yeah, yeah. So the doing things that don't scale, that's probably the most important part of the DoorDash founding story and DNA. And we probably took that to the most extreme end as possible. In the beginning, the whole thing didn't scale. Like I said, it was zero software. The whole thing was done through pen and paper. Were like, I guess like texting and Google Spreadsheets. And then when we started onboarding new drivers, we said, okay, like we gotta, we made everyone install like Find My Friends on your iPhone so we could like track everyone's location and dispatch manually. Like initially in the payments, like we didn't have payments available online. The whole thing was just like done through like, we had these like Square dongles lying around. So that was payments when it came to charging the customer, but what about paying for the food at the restaurants? So in the beginning, when the founders were doing the deliveries, we would just use our own credit card, which is fine. What if you are, now that you have these, you know, drivers that are doing deliveries for you, how can you, you know, you can't expect a driver to be paying for all this food upfront on their own personal credit card, right? And it starts adding up. So the solution was, well, why don't we go we found out you can actually buy these prepaid debit cards from like a Walgreens or CVS. You essentially just go in, you buy one of these cards, you load it up with cash, and then you just give it out to your drivers and then just replenish it every week. So that's what we did. And here's the funny thing we didn't realize was that you actually can't buy one of these debit cards with a credit card. You have to pay cash to buy one of these debit cards. So what we would do is every day we would go to the ATM machine, we'd draw a boatload of cash, walk into Walgreens, buy up all the debit cards, and then the next day we'll go back and do the same thing again. So just imagine the Walgreens staff seeing these bunch of young college students coming in with bricks of cash, buying up all the debit cards every day. They probably thought we were like, drug dealer, just on the same, but that's what it took to make this happen. And the last example I would give, and I'll kind of illustrate kind of how we took do things that don't scale to the extreme is this idea of initially the thinking was, okay, we'll start by doing things that don't scale. We'll just call these restaurants and then 6 months later we'll just convert them into some sort of integration into the point of sale. We'll give them an iPad, digitize it at some point. Well, it turns out the pace at which we were onboarding these restaurants was, or the pace at which we were growing DoorDash and adding new restaurants was outpacing our ability to implement these integrations. So we had to just keep, we thought this was a 6-month thing, but turns out it'll be years later before we were able to digitize everyone. So in the meantime, we thought, okay, like, why don't we just figure out a way to scale order placing, right? Like, it's like, no one ever thought, asked the question, well, actually, how far does doing things that don't scale actually scale? And the answer is always much further than you think. So we thought, okay, like, why don't we just try to, instead of trying to limit our growth, why don't we try to figure out a scale order placing? So we just literally, we said, okay, what if we just go and hired a bunch of order placers or contractors that all they do is just place orders. Like we built like a little dashboard where you can like kind of claim orders and then for every order they placed, and we were able to scale that, I guess. I think at our peak we had probably over 8,000 people placing orders every single night. And even to this day, we still have order placers. A lot of things at DoorDash, I would argue even to this day are things that are quote unquote unscalable., but we still do it. And so I think it kind of just forces you to prioritize what actually matters. It's so easy to just say, oh, we got to automate all these things, we don't have enough engineering resources, et cetera. But really, what is actually truly, truly necessary to automate? And I think the by doing things that don't scale, it really forced us to actually work on the things that couldn't scale because versus thinking, oh, we just got to— let's just automate auto placer because it feels like it's something that doesn't scale, but turns out it does scale.

Enjoying the conversation? Got a question? You can ask Stanley Tang's digital mind. Just check the link in the comments or description. So over time, obviously there was Uber Eats and Postmates and there was competition. And I'm curious, one, if competition was ever a thing that was top of mind for you guys. And then two, obviously DoorDash had an edge in its distribution focusing on local businesses. But I'm curious if you think there was anything DoorDash did differently from a sense of product planning and the way you did product that gave you an edge over others.

Yeah, I think I'll answer in two ways. I'll answer kind of your first question and then the second part as well. The first question, like in terms of thinking about competition in the early days, not really. I mean, the only thing that matters, I mean, later on, yes. But in the early days, it's, you know, you're going after such a big market. No one's really a big player yet. Like chances are the competition you're facing is not Uber or Postmates. It's, you know, the competition you're really competing with is existing consumer behavior. Of ordering takeout or not ordering delivery at all, like cooking at home. That's really the main competition. Like even if you added up all the deliveries player back, I mean, even right now, like if you added everyone together, all the deliveries players together, I think we're still like less than like 20% of the overall like restaurant food market. And in the beginning, like the only thing that matters is like, are you serving your customers? Are you serving the restaurants? Are you serving your consumers? Are you serving your dashers? Like, that's it. And getting that, getting that to work, right? Like, chances are, like, a customer is not going to be— you're not, you know, a customer is not— is there— they're going to keep using you because, well, they're not going to switch off of you because, oh, like Uber came on. They're probably going to switch off of you because you messed up their delivery, right? Like most of the, you know, so it's about like, can you get that? Delivery quality consistently, obsessing over like every single delivery, the quality of each delivery, the speed, you know, like the customer service. Like when things do go wrong, like what's your response to it? And doing that at scale. I mean, that's honestly the hardest part, which I think leads to the second part of your question is I think you have to understand what the product you're building. And for us, like it was very clear that the product we are building, it's not a pure software business, it's an operational business. It's something that requires the marriage of technology, good technology and operational excellence. So it's just a lot more of an operationally complex business that requires you as a— therefore, one of the things we care a lot about is going into the lowest level of detail because because no two deliveries are the same, you can't look at things at an aggregate level. You gotta, you know, like things might look good on a dashboard, like, because on average our delivery time is like 37 minutes, but that doesn't really tell you anything, right? Because some of the deliveries can be 20 minutes, some of the deliveries can be 80 minutes. And it's really those like the kind of the outliers that are going to kill your customer experience. So you gotta like, so for us, like we always look at things down to like even our business reviews, we look at things down to like the zip code level. Like we'll pull up like literally individual deliveries and go like, what the hell happened here? I like, this is like clearly like this, this, this was like a completely messed up delivery. So what are we going to do to, to address it? So, so, so that's kind of the level of rigor it takes to build an operationally intense product. It's more about like, how do you optimize the delivery experience? Like when things go wrong, like what do you, you know, like do you have automations in place to detect, oh, the driver's going wrong? Direction, therefore you should have a learning system. It's like, how do we do a better job predicting restaurant prep time and by time of day and things like that? So those are kind of the product challenges we focus on as opposed to where does this button go?

Yeah, I love that you said that your biggest competition is consumer behavior because it's very similar with us and You mentioned, you know, you lose a consumer because they have a bad experience in the product. So I'm curious, startups, speed is obviously very important. How do you think about balancing speed and quality when you need speed to survive, but you need quality not to lose consumers?

Yeah, that's a really good question. I know, I mean, I'm still trying to figure that out to this day.

Good, that's good to hear.

I mean, like for me, like when people ask me like, how is DoorDash so innovative? Innovative or how does innovation happen at DoorDash? How do you come up with all these products and features and know what to build and keep figuring things out? Well, I can tell you it's definitely not because we're a bunch of product geniuses sitting in a conference room and we're just coming up with these amazing ideas. So for me, it's more about how do you create product? How do you innovate at a consistent level? And so really it's all about experimentation. It goes back to how the founding story of DoorDash. Like DoorDash started off as an experiment. We had no idea if this would work or not. And all we've done is simply just scale that so that instead of just being one experiment at a time, we're running probably 1,000 experiments at a time. And it's just about constantly experimenting, constantly iterating. And for me, innovation is really, can just be defined as the How quickly can you iterate? That's it, right? It's just how many cycles of, or how many iterations can you get in as short of a time period as possible? And the quicker and the tighter you can get that loop, like the more quote unquote innovative you are, right? From the outside, because it looks like you're, but simply just like a company that's more innovative is just simply a company that's iterating a lot more and experimenting a lot more. And that's kind of how we think about DoorDash is like, you know, how do you kind of run this like giant experimental iteration machine and decentralize that where like anyone at the company can be iterating and your job as like the founders and the leadership team is more about, it's less about telling, hey, this is what you need to do. It's more about like, Okay, like you're, it's almost like you're like a VC firm or VC fund. Like you're just like, you know, you give people small budgets, see which projects like pick up steam. And then as they scale, it's like, all right, like this project has graduated into like the Series A. All right, here's like 10 more engineers. All right. Oh, this is now you hit the Series B milestone. Here's like 50 more engineers. And then as they hit these milestones, you just keep giving more resources. But, and so versus, you know, versus like trying to predict what's going to work and what's not.

Yeah, so on the third bucket, you're now head of DoorDash Labs. You're focused on things involving robotics and automation. Is that iteration loop the same? Because I imagine you're now working on something where it's more expensive, the wait times are longer, and you don't have as much data because it's an entirely new thing.

Yeah, I would say hardware is definitely a little bit different, robotics and hardware. I think it has to be a little bit more tops down. Like you kind of have to have a vision and say, hey, this is where the world's going. Like robotics, autonomy is going to be part of our future. So do we either want to control our destiny and build that future for ourselves? Or do we rather, or do we want to wait on the sidelines and wait for this disruption to happen to us? And like, we will always want to be the former. We always want to be the one that's control our own destiny, especially if it's going to be a big paradigm shift. And that's why we're going to invest in this. But again, you can take kind of a thoughtful way of kind of this iterative milestone-based approach. Maybe not quite the same as software, but whereas for us, we've kind of taken a much more methodical approach where it's like, let's first figure out what is even our autonomy approach? Like, should we be should we be building these things ourselves in-house or should we be working with partners and vendors? There's like these, you know, there are drone companies out there, sidewalk robot companies out there. Like first, like let's figure out what our, even what our approach is. It's like understanding what the use cases you're solving for and then figure out, okay, like what form factors fit into each of these use cases. And it turns out like, you know, I think what we learned is I'll say there's a couple of things to learn. I think one is there's no, it's not going to be this like one singular, one autonomy, at least for delivery. Maybe rideshare is different, but for delivery, it's not going to be like, oh, we create this one as a singular autonomy solution that addresses every single problem we have. It's going to be, you know, it's going to be a spectrum. Like there's some deliveries that we've done, we've done, you know, millions of deliveries with sidewalk robots, but these sidewalk robots play a very particular, they address a very particular use case. It's the college campuses, downtown urban areas where distances are like less than half a mile. Like these things don't work, you know, when you need something delivered that's 6 miles away. You know, maybe drones fit in really well for deliveries that are going from in like more rural areas where there's not like road accessibility is like a bigger issue. So that's where drones come in handy. And then maybe you need something like a, you know, a bigger, like something that's closer to like what a Waymo is, like a bigger autonomous delivery vehicle to go some, to go like to do the 3 to 5 mile deliveries in places like Texas or, you know, or Kansas or, you know, where it's more of an urban sprawl. So Yeah, and we've even explored like there's going to be autonomous robotic solutions that are needed inside the kitchens around kitchen automation, kitchen operations improvement. We have these things called Dashmart, which are essentially ghost warehouses. How do we bring automation to there? So again, it's not a one-size-fits-all. It's going to be a spectrum of solutions. And some of these we're going to build ourselves. Some of these we've partnering. I mean, we're already doing a lot of these, like we've done, for example, drone deliveries. We've done probably hundreds of thousands at this point, actually across the world. We've done in Australia, Texas, most recently Charlotte. So we are doing these things. But again, you can take a much more iterative approach instead of like one size fits all, let's throw the kitchen sink at it. It's like, okay, let's try to identify what the use cases are and and for each of the use cases, figure out what the right form factor is and then figure out if it's working or not and then scale from there.

Yeah. All right. I have a couple more questions, then I want to open it up to the team for questions. What was the darkest moment of your journey as a founder and what did it teach you?

Oh, I mean, there are a lot of these moments, But I'll say the one that stuck out to me the most was actually a moment very early on at DoorDash. It was maybe 9 months into the company. It was September 2013. DoorDash has just been around for a few months. And I remember this was also the night of the first Stanford home football game. So everybody was back on campus. Everyone was excited for the game. They wanted to order food. And also it was raining hard that night. So, and for us, like when it's pouring rain, that's when demand spikes. Like everyone, no one wants to go out. And we were just completely unprepared that evening. Like orders just kept flooding in. We couldn't shut the orders off. We didn't have enough drivers. Like everyone was out doing deliveries. And of course it ended up being a complete disaster. Everything was late by 2 hours. And a lot of the time, for a lot of these customers, this was the first time they ever used DoorDash. And it was like the worst experience possible. Like they're never going to use DoorDash again. And oh, by the way, like we probably have about 4 weeks of runway, 3 weeks of runway left. Like we just got out of YC. We haven't raised our VC round yet, the seed round yet. So we probably had like, you know, it's like we only had the YC money essentially. So we got back and it's like everything was disastrous and we're like, holy crap, what the hell just happened? And it's like no one's ever going to use DoorDash again. And so the question became like, what do you do in that moment? Like, do you just kind of, you know, do you try to like Well, preserve as much of the cash as you can. Just try to pretend this day never happened and just try to ride it out and hope people forget. Or do you try to do the right thing for your customer? And in this case, the right thing for your customer is if something is like 2 hours late, you should get your order refunded plus maybe even more on top. And then when we did the math on refunding everyone's order, keep in mind when you refund the full order, you have to actually pay more than what, because DoorDash only collects the delivery fee, but when you refund the order, you gotta pay for the entire meal itself, because it wasn't the restaurant's fault, so we can't make the restaurant pay. So when we did the math, it actually worked out to about 40% of the amount of cash we had remaining. So, and it took us about maybe 15 seconds to make the decision, and we decided, you know what, like we gotta do that. Like this was the only way we could preserve our reputation. Otherwise, what's even the point of doing this? And so we pressed the refund button. We also spent all night writing handwritten apology notes. And for all the egregious deliveries, we actually hand-baked cookies and delivered to every one of these homes that evening. And that really bought us preserved our reputation and also defined what DoorDash means as a company, which is we are the company that's going to do what's right for the customer. Even to this day, it's like, this is what DoorDash is about. Customer love is one of our core values.

No, I respect that a lot. I feel like that's a decision that companies today may not make. So in the early days, it was obviously very chaotic. Is chaos something that eventually leaves or is it just forever and you just learn how to embrace it?

No, it's forever. You just learn to embrace it. I mean, I used to be— it's funny because this is— there's one thing that I've changed the most through this company building process is like I used to be like a very kind of OCD kind of person. Like when I was in my early 20s, like I was one of the type that your calendar had to like be perfectly organized. Like every minute has to be accounted for. Like today I'm like the exact opposite. I'm like, embrace the chaos, embrace ambiguity, embrace change, embrace the fluidity, because things are never going to be perfectly organized. And yeah, just as long as you're growing, I mean, the day everything is perfectly organized is the day the company shuts down. So you just got to embrace it.

Yep.

What iterations of the onboarding experience that you had to go through and at what point you feel like you found a way to refine it so that way you could explain to someone how to be a good delivery driver and also kind of make sure that first experience when they delivered something was also good for our user.

Yeah. Onboarding used to be very, very hands-on, very heavy hand-holding, hands-on. Like they would, we literally, they will show up to our office for an in-person orientation. And go through like a full hour. We'll go through how the app works, how DoorDash works, how, you know, how to, you know, best practices and this and that. And they will then go out with one of the DoorDash employees. Like I've actually done this before where we literally like just go on a 3-hour dash together, like just one-on-one and just to make sure this person felt comfortable. And then after that, we put them into the kind of put them into the wild and have them do deliveries on their own. So because we, again, we had no product automation, like, so the only way to automate onboarding and was we actually got to do these physical onboarding sessions. And then eventually like you build it into the app where you, or the app gets so much better where it's like kind of self-explanatory, right? Like there's the onboarding, like now, and then we switched to like they watch a video in the onboarding app and then now it's like, The whole app is like so easy, so automated that you don't need these onboarding sessions anymore. So that's kind of, again, it's like we did initially, we did the thing that don't scale. Like it's not, you can't scale like onboarding sessions, but it turns out that you can actually scale it pretty far. And I remember I was talking to Gojek, which is like a, it's like the DoorDash of Indonesia. And they said they, Yeah, they do these driver onboarding sessions where they literally rent out entire football stadium and it's like 50,000 Dashers just show up and then they do an onboarding session and then an hour later they all leave on their scooters and then they start doing deliveries. So I guess it can scale to, it does scale to a certain extent.

Stanley, thank you so much. I have so many notes. I can't wait to talk to your digital mind.

Yeah, man.

Cool. Awesome. Thanks, Johnny. I look forward to talking to you myself.

Awesome.

Thanks for tuning in. If you enjoyed today's episode and want personalized advice from Stanley Tang, head to the link in the comments or description to ask his Digital Mind on Delphi.