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

Chances are that the competition you're facing is not Uber or Postmates. 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 Lejavardian. 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. Been super excited about this, but can start at the very beginning in your life. You started computing at the age of three. You were a best selling author at the age of 15. You had a six 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. 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 as a kid I was always surrounded with computers and I remember just being hooked to just playing with, 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 versus like kind of just pull pigeonhole you into like oh, this is what you have to do, right? So this is like a pre planned like career or life that kind of been assigned to. So yeah, just experiment with 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 IDE or this just came 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 mobile apps, social apps, Snapchat, Facebook, Instagram. But no one was really focused on building software for the physical world. But what about the local businesses down the street for the vast majority of these, again, this is back in 2013, they're run on pen and paper. No technology, no software. So we felt like that was an interesting opportunity. What are software can build for these, 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 just will go in, 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, it was 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 store, 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, it's a, it's when I say whenever you get one of these delivery requests come in, they should 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. 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. It's a 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 eight restaurants called 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. 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 palotodelivery.com we picked up the phone call. First of all, I have no idea how 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 palo alto delivery.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. Like we weren't originally we were supposed to tell. The original plan was to tell this person, no, 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 him it was not a real delivery service. And so I said, hey, why about my co founder, do you guys want to tell him? And they didn't want to tell him 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? Like, 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 ourself, picked up the food, and delivered it to that customer. So I remember the exact date. It was January 12, 2013. And that was the start of Palo Alto Delivery.com. and the next day, we got two more phone calls, and we decided, okay, we'll take those two as well. And then it became three, and then five. And the next thing you knew, the whole palotodelivery.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 DoorDash got. Well, later it became DoorDash, but that was how Paloto 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, like, thinking about the complexity of operationalizing all this with software?

Yeah. And honestly, like, none of that mattered in the beginning, right? In the beginning, the only thing that mattered was just serving the customers you have. Or, you know, people use the phrase product market fit a lot. The most important thing in the beginning is like, are you solving a customer problem? Right. In this case, there was a clear customer need for both sides. For the consumer, they wanted delivery, and for the retailers and the 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 to, go after. And at the time, it was. It was. And it was an unmet need as well. There. There wasn't really anyone solving problem for both sides. I mean, there were 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 aggregate. They're like marketplace aggregators, this is kind of where we were able to kind of fulfill that unmet need for them is we're not only. It wasn't just listing your web, you're listing your restaurant on a website. It was, we can actually power the delivery as well. Yeah, that was kind of 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's kind of. Yeah, that was really like what allowed DoorDash to take off in the meeting.

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 doom thing that don't scale, that's probably the most important part of the DoorDash founding story and DNA. And we probably took that to like, the most extreme end as possible. Right. Like in the beginning, like, the whole thing didn't seal. There was, like I said, it was zero software. The whole thing was done through pen and paper or 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 next 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 restaurant? 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 can't expect a driver to be paying for all this food up front on their own personal credit card. 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 cars, you load it up with cash, and then you can 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 every. 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, like, these bunch of young college students coming in with, you know, bricks of cash, buying up all the debit cards every day. You know, they probably thought we were, like, drug dealers or something, 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 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 six months later, we'll just convert them into some sort of integration into the point of sale. We'll give them an iPad, we'll 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're growing these growing doordash and adding new restaurants was outpacing our ability to implement these integrations. So we have to just keep. We thought this was like six months thing, but turns out it'll be like years later before we were able to digitize everyone. So in the meantime, we thought, okay, why don't we just figure out a way to scale order placing? 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, why don't we just try to. Instead of trying to limit our growth, why don't you try to figure out a scale order placing? So we just literally said, okay, why don't we just go and hire a bunch of order placers or contractors that all they do is just place orders. 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 enough engineering resources, et cetera. But really what is actually truly, truly necessary. Automate. And I think by doing things at own scale, it really forced us to actually work on the things that couldn't scale because, you know, versus like 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 DigitalMind. Just check the link in the comments or description. So over time, obviously there was Uber Eats and Postmason, 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. Yeah, that's really the main competition. Even if you added up all the deliveries player back then, even right now, we added everyone together, all the deliveries players. I think we're still less than 20% of the overall restaurant food market. In the beginning, the only thing that matters is are you serving your customers? Are you serving the restaurants? Are you serving your consumers? Are you serving your dashes? That's it. Getting that, getting that to work, right? Like, chances are like a customer is not going to be. You're not comp. You know, a customer not is. They're. 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 you because you messed up their delivery. Right. Like most, you know, so it's about like, can you get that delivery quality consistent, like obsessing over like every single delivery, the quality of each delivery, the speed, the customer service. When things do go wrong, what's your response to it? And doing that at scale, 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 it was very clear that the product we are building, it's not a pure software business, It's a business, it's an operational business. It's something that requires, you know, 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, like one of the things we care a lot about is going into the lowest level of detail because no two delivers 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 is on average our delivery time is like 37 minutes. But that doesn't really tell you anything, right, because, because some of your deliveries can be 20 minutes and deliveries can be 80 minutes. And it's really those like the kind of the outliers are going to kill your, your customer experience. So you got to like, so, so for us, like we always look at things down and 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? This is clearly, this was a completely messed up delivery. So what are we going to do to address it? So that's kind of the level of rigor it takes to build a operationally intense product. It's more about how do you optimize the delivery experience when things go wrong. 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. It's very similar with us. And you mentioned 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 mean, I'm still trying to figure that out to this day.

Good. That's good to hear.

I mean, for me, when people ask me, how is DoorDash so innovative? Innovative or like. Or how does innovation happen at DoorDash? How do you come with all these products and features and know what to build and keep, like, figuring things out? Well, I can tell you it's definitely not because, like, we're like, a bunch of product geniuses sitting in a conference room, and we're just, like, coming up with these, like, amazing, like, ideas. So for me, it's more about, like, how do you create products? How do you innovate at a consistent level? And so really, it's all about experimentation. It goes back to, like, how the founding story of DoorDash. 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 really can just be defined as the how quickly can you iterate? That's it, right? 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, the more innovative you are 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, experimenting a lot more. And that's kind of how we think about DoorDash is like, how do you kind of run this giant experimental iteration machine and decentralize that where anyone at the company can be iterating? And your job as 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, okay. 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 pick up steam, and then as they scale, it's like, all right, this project has graduated into the Series a. Here's like, 10 more engineers, 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 and more resources. But. And so 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 top 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 destiny and build that future for ourself, or do we rather. Or do we want to wait on the sidelines and wait for this destruction to happen to us? And like, we always want to be the former. We always want to be the one that's control our own destiny, especially if there'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 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. 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 figuring 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 think there's a couple things we learn. I think one is it's not going to be this like one singular one autonomy. At least for delivery. Right. Maybe rideshare is different, but for delivery it's not going to be like, oh, we create this one. It's 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. Right? There are some deliveries that we've done, we've done, you know, millions of deliveries with cyborg robots. But these, the cyber 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. These things don't work when you need something delivered that's six miles away. Maybe drones fit in really well for deliveries that are going from. In more rural areas where there's not 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. Something to go, like to do the three to five mile deliveries in, in places like Texas or, you know, or Kansas or, you know, where it's more of an urban sprawl. So. Yeah, and then we 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 through there? So again, it's not a one size fits all. There's going to be, it's going to be a spectrum of solutions and some of these we're going to build ourselves, some of these we've, we are partnering. I mean, we're already doing a lot of these. Like, we've done, for example, drone deliveries. We've, we've done probably hundreds of thousands at this point, actually, across, across the world. We've done in Australia, Texas, most recently Charlotte. So we are, so it's, it's, we are doing these things. But again, you could take, you can, you can take a much more iterative approach instead of like one size fits all, 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 nine 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 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. Orders just kept flooding in. We couldn't shut the orders off. We didn't have enough drivers. Everyone was out doing deliveries. And of course, it ended up being a complete disaster. Everything was late by two hours. A lot of the time for a lot of these customers, this was the first time they ever used DoorDash. And it was the worst experience possible. They're never going to use DoorDash again. And, oh, by the way, we probably have about four weeks of Runway, three weeks of Runway left. 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. It's like we only had the YC money, essentially. So. 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, like, pretend this day never happened and just try to, like, ride it out and help 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, two hours late, like, you should have the whole. You should get your order refunded, plus maybe even more on top. And then when we did the math on, like, refunding everyone's order, well, keep in mind, like, 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 got to 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. And it took us about maybe 15 seconds to make a decision. And we decided, you know, what we got to do, that this was the only way we could preserve our reputation. Like, you know, like, otherwise, like, what's even the point in doing this? And so we pressed the refund button. We also spent all night writing handwritten apology notes. And for the all the egregious delivery, we actually hand baked cookies and delivered to every one of these homes that evening. And that really bought us kite, you know, preserved Our reputation and also defined what doordash means as a company, which is like 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 spouts about. You know, 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.

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, 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 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 counted for like today I'm like the exact opposite. Like, I'm like, embrace the chaos. Right? Embrace, embrace ambiguity, embrace change, embrace the fluidity. Because things are never gonna 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 gotta 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 is that way you could explain to someone how to be a good delivery driver and also kind of make sure that first experience they delivered something was also the driving user.

Yeah. Onboarding used for dashers 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. A doordash employee. Like I've actually done this before where we literally like just go on a three hour dash together, like just one on one. And just to make sure this person felt comfortable. And then after that you 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, so the only way to automate onboarding was we actually got to do these physical onboarding sessions and then eventually like you build 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 and then we switch 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 on scale, like it's not you can't scale like onboarding sessions, but it turns out 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. It's like, you know, 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. Right. So I guess it can scale to, you know, 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 my.

I got man. Cool, awesome, thanks. I look forward to talk 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.