The Untold Story Behind the Facebook Like Button with Soleio
In this hour‑long interview, Dara Ladjevardian talks with product designer and former Facebook and Dropbox leader Soleio Cuervo. The conversation weaves together several strands: the chaotic birth of the Facebook "awesome" (Like) button, how Cuervo helped invent the title "product designer" and built a culture where designers could ship code, the emphasis on speed, ownership, and data‑driven decision‑making at Facebook, and the tension between top‑down road‑maps and bottom‑up hackathon innovation. Cuervo reflects on painful product intuition failures (early Facebook onboarding, the delayed Like button) and the lessons they taught about trusting data over gut. He then describes his transition to Dropbox, where a culture of "space‑shuttle‑quality" reliability forced a re‑thinking of his fast‑and‑break‑things instincts. The later part of the interview turns to strategy for AI‑native companies like Delphi: balancing rapid iteration with trust‑and‑safety, using corporate‑regret minimisation, aligning core team strengths with strategy, and whether design can serve as a moat. Cuervo shares his vision of AI‑driven knowledge representation (the "Oprahbot" idea, replicating Aristotle’s mind) and why he is excited about Delphi’s mission. Throughout, he emphasizes utility over aesthetic novelty, system‑centric design, and the importance of brand as a vehicle for future expectations.
Chapters
The like button internally is called the awesome button. It lived in product purgatory internally for about two years. It was developed as a hackathon project in the summer of 2007. Like, it constantly got bounced by the CEO Mark Zuckerberg. Every implementation of it was just kind of goofy. It didn't feel right. And it turned out all of our product intuitions from years of working on Facebook were dead wrong.
The Library of Alexandria was an attempt to capture all human knowledge. Fire and war destroyed it. Today we trust 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 Legvardian. Let's dive in. I'm here with my friend Soleo, a prolific designer and leader and one of the first people to really flesh out the role of a product designer. He was an early designer at Facebook where he co invented the like button and I think a thousand other products, if I recall.
Yes.
And he was, he led design at Dropbox, where he turned their design Org into one of the most designed, most admired design orgs in Silicon Valley. And now he invests and advises design first companies like Figma, Perplexity and Delphi. Thanks for coming, Soleil.
Thank you for having me.
Starting in the early days, I know you kind of started your design career also developing and coding, and I'm curious how that multifaceted kind of skill set shaped the way you design. And if you think people today should try to have a multifaceted skill set or if they should specialize.
Oh, right. Easy questions right out of the gate.
Came in with the hard questions.
Should have had two coffees this morning. I have pretty strong opinions about this because I grew up in the early web where we didn't have great design tools. The best we had was Photoshop. And as many of you know, Photoshop is very ill equipped for doing anything software related. It's a great raster editing environment, but raster editing was a small facet of the early web. And so I studied music at Duke University. And on nights and weekends, I spent my time building marketing posters and websites for my bands, my buddy's bands, eventually Duke University departments. That became a line of business for me. And so the term design I sort of, I feel like I've backed into a little bit because most of the work that I was doing was actually shipping. It was actually producing a of Lot live experiences out in the world. And that was a hook for me with web development, which is that you can make a thing and put it online. And it was just, it was out there. And when you're doing any sort of polish work, that sort of falls under the category of design. And a lot of that polish work didn't happen outside of code. It happened in the browser, it happened in the text editor, it happened, you know, over an SF2 heave server. And back then we were hand rolling everything. So my foray into web apps was largely as a front end developer. But because I had pretty good Photoshop chops and I was able to make things clean and tidy and neat, I found that building myself as a designer was a bit more attractive to startups in San Francisco than just being a front end developer. Because in practice I was doing the work anyway of hybridizing front end development and design. These days I think we call them design engineers, but back then it was just more plainly called a designer. And I would argue that, I think Facebook was actually the first to coin the term product designer, because when we actually instantiated the role, it made no sense to call ourselves web designers. We were working on a product team. When we thought about the work that we were doing, it wasn't strictly just like page views. We were thinking about the system, we were thinking about the product, the product experience end to end. And a lot of the work that we did wasn't really at the UI level. It really felt like it was sort of sitting at the product architecture level. So the term product design kind of took hold in a software context. And I would argue, I don't think there were any other companies that use the term before Facebook in a software context.
So today when you join a company as a designer or an engineer, there's millions of blog posts on like, how to be a good designer, how to be a good engineer. You didn't have that. You said this was like one of the first product design roles. How did you navigate kind of an undefined world? Were you creating it as you go or like what were you were your guiding principles?
Yeah, yeah. There weren't a lot of comparables to work from. It made hiring extremely hard because we were sort of just inventing a role, like calling it imagineer. Right. And then trying to find people that, you know, fit the role. Imagineer. For us, we felt that Facebook was predominantly a technology company. In that context. We were competing with MySpace, so we had a pretty formidable incumbent that we needed to run down. Took us about four years to do so. Everybody forgets that we didn't get that for free. But the other piece was that we viewed design as a capacity for speed. We felt like a principal idea of Facebook as a culture, as a team, was that our competitive advantage was going to be speed, that we can do everything faster than everyone else, that a team of 10 could do more in one month than most companies could do in a year. And through that culture, that sort of perpetual lens of speed, we viewed design not merely as a practice of quality or necessarily an environment which we needed to sort of think about like the spit and shine and polish and the visual aesthetic of the product. Those things were necessary. I kind of think of it as like playing in tune. We view design more as like, how do we as a team enable engineers to be able to build in the Facebook environment? We often refer to Facebook as an environment almost like an operating system, and where we would provide internal resources so that teams can make good decisions and self serve componentry on their own and ideate and create experiments and generate new features and products without us necessarily having to be an explicit gate to get out to production. This resulted in a lot of haphazard things going out to market. And sometimes we would have to chase down features that seemed a little goofy or obviously didn't get enough attention. But because we enforced this idea that every designer needed to be able to write code and push to production, there were no excuses for not fixing things that were not arranged correctly. If you saw it, you fixed it. Right. We really took on this ownership mindset where it's like, if there are no obstacles to you writing to production, like, you see something that's goofy, just fix it. You don't need to ask permission. That's why we work at a startup. And I felt like that culture of ownership and speed was one of the defining characteristics of the team. Again, it made hiring very hard because we were trying to call front end developers designers. But I felt like finding that intersection of people who were good front end developers, were fast and were tasteful was sort of our sweet spot. And every person that we brought onto the team reinforced that idea or that principle for design.
Yeah. And in that fast paced culture, how do you. I know the speed was a priority, but was there ever a sense of, is this good enough, like designing the like button perfect, like the perfect like button in the world, or this is good enough, let's just ship it?
Well, like button's got a weird story to it because it lived in product purgatory internally for about Two years. It was developed as a hackathon project in the summer of 2007, and we didn't launch it until Q2 of 2009. It was one of those projects where, like, it constantly got bounced by the CEO, Mark Zuckerberg. Every implementation of it was just kind of goofy. It didn't feel right. And we had this, like, pretty simple rubric for what went out to production to 100% of users. Like, did we ship it internally? Did people qualitatively like it? Like, did we actually use it as. As where we were constantly dogfooding Facebook? And then two, did the numbers internally kind of reflect, you know, the kind of engagement that you would expect from everything else that we had that had been released internally? So there was a public version of Facebook, there was an internal version of Facebook, and anything that sort of crossed this threshold of, like, okay, we've got employees. People use the product every day. Is it producing the kind of numbers that we would expect relative to everything else? Okay, it seems like people like it. People are using it. Let's go ahead and push it out to production to 100% of users. And that strategy, for me, was clarifying because it forced the question rather, it reframed the question of like. Rather than thinking, should I work on photos, should I work on. On profile, should I work on privacy? What should I work on as a designer at Facebook? Instead, it reframed it as, like, where can I have the greatest impact? Where can I increase the reads and writes of a system? We have this stupid like button internally. It's called the awesome button. We had this stupid like button project, right? And right now, all of our commenting interfaces are like, vintages. Like, we have a commenting interface from, like, 2005, one from 2006, one from 2007. None of them integrate with newsfeed privacy settings in the right way. So we should sort of, like, standardize them and we'll create a universal feedback interface. We called it the ufi. And this will be the staging grounds for, like, experimenting with this like button and. And getting it out the door. Because I'm convinced that if we move all conversation to newsfeed and use this as a staging ground for the like button, maybe we can actually make a strong case, an empirical case for why can double reads and write or help contribute to saturating that opportunity space. So double the reads and writes to the system. And so we. We ended up working on the like button in that context, and just by having it be a part of a. Of. Of an Effort to make the system cohere, make the product cohere. It found a much more natural home in that environment. And of course, we were very tepid. We were like, okay, we can't rule it out to 100% of users. We have to run a controlled a B test, make sure we're not cannibalized. We're not doing all the things that we were concerned about. And it turned out all of our product intuitions from years of working on Facebook were dead wrong, that people were more likely to comment and talk to their friends if there were preceding likes on a given post. And we're like, oh my, it actually functions as a social lubricant rather than being like an obstacle to conversation. And it was a lesson for me in how sometimes our internal dogmas can fly in the face of the data. So never ignore what the data is saying to you. Like, the anecdotes are one thing, the presuppositions, the philosophy can sometimes guide you in one direction, but the data will always be the data. And how the market responds will tell you in many different ways what you ought to be building next and where your efforts might be rewarded by your user base. And so, yeah, that's how the like button went out the door. And a lot of people claim credit to designing it, but I know my names are on the commits, so that's.
And so you had these dimensions that you can now decide what to build around. Did you guys have like specific deadlines? Because the like button seems like it got delayed and it got pushed out two years. But were there roadmaps in the early days or was it ad hoc? Like, this feels good, let's just ship it. Or was. Was Mark really driving you guys to. On a weekly or bi weekly basis, we ought to just keep shipping even if things break.
We sort of had this. This funny dual methodology of like, we had top down initiatives, sort of like the strategy and how those were broken into specific kind of organizational elements, specific roadmaps, and people who are on the hook for making sure that we like hit our deadlines, especially if there are ever codependencies. If you kind of needed to get things sequenced out in a certain way, it was almost like top down executive strategy. But there was also this internal culture around hackathons where sometimes you had these bottoms up initiatives. And I feel like a good strategy gives room for both. It provides the tree or the structure for activity, but it provides also the frame through which people can come up with novel new ideas. And rather than Argue it out, or, like, write a bunch of memos and work it through the entire company. It's just like, build the damn thing. Yeah. Code wins arguments. We used to have this poster on the office. If there was one artifact from that company that I wish I still had was the code wins arguments poster. Because it was just so much more clarifying. It's much more invigorating to say, instead of us arguing this out, let's just ship the thing and look at what it did and then make a decision based on that. Because then at least we're looking at hard data rather than who, you know, getting into the debate club over, like, what the right thing is. Everybody forgets the things that Facebook shipped that never worked. And, like, 80% of the stuff that we shipped no longer exists. Everybody has forgotten it. It's lost to memory. But if I printed out a stack of papers of, like, the stuff that we announced in the first five years, the vast majority of that just is in the shredder. Things like virtual gifts, group deals. Like, we had, like, weird local ads. We had other primitives besides, like, status updates and photos. All manners. Like, social ads. Like, all manners of things that we thought were good ideas and, like, were done with the. With the highest intention, but that in practice, like, once it went out the door, we're like, actually, this is clumsy and stupid and not great. And it's not moving the needle. Like, just uproot it, take it out of the soil. Like, let's. Let's tidy up. And so part of it's also recognizing that activity as well as, like, getting things out the door.
So one of our required readings in the company is called Loonshots, and there's a. Have you read it? There's a concept in the book called a false fail, where something fails not because the idea is bad, but because the execution wasn't cooked enough. And so I'm curious because, like, Delphi, for the first year, we had no data to prove that it was going to work. It just took a bit longer for it to flesh out. So how do you know something is not working because the idea is bad? Or maybe like, oh, maybe actually, we just need to cook on it a little bit more.
That's a really good question. I think that this varies case by case, but it's sort of the question of, like, am I putting good money behind bad? If something isn't performing to expectations, can the team feel confident that they know why? Can they sort of say, okay, we've given this our best effort and it's just not taken with the market in a way that we expected it to. I think there's also an element of do you have the initial conditions correct? So one of the painful lessons that we learned at Facebook once we expanded beyond work networks. So we were originally colleges and schools then we didn't just open up to the public, we launched to large employers of new grads. So there would be like high graph density for every new network that we greenlit. And eventually we opened up to like, normies. Anybody with an email address could sign up for Facebook. And our retention numbers were abysmal. It was like falling off a cliff. And I remember it was just kind of a. You can feel the blood leaving your face when you look at the numbers. You're like, we are so fucked. Because you were basically opening up the product. And people would sign up and they wouldn't find anybody that they knew on the service. And we were like, oh, maybe we haven't built a universal product. Maybe we need to kind of rethink the news feed, right? And after you sort of dig into the numbers and you take a step back, you realize that like, okay, if we're spending all this effort trying to increase engagement in newsfeed, but when you look at where a person kind of ends up a couple weeks after they've signed up, a lot of these folks just aren't finding their friends. Maybe this is like a search problem. Maybe we shouldn't be like showing newsfeed if you don't have like one or two friends. Maybe like the initial conditions for these sets of users are poor. And so rather than treating this as a newsfeed problem, it's more of like a bootstrapping initial condition problem. If, like the computer's not plugged in and the person can't turn on the computer, it's not because the computer's broken, right? And so we were realizing that like, no, this is like more of an onboarding problem. And we should almost be like more regimented about onboarding so that we know what are the initial conditions that ensure high probability of long term engagement. Doing cohort analysis and figuring out what are the three or four things that a person does in day one that, that are precursors for six month engagement, right? Putting their name on the service, putting their photo, putting one affiliation with their hometown, where they went to school, where they currently work, anything. And maybe we shouldn't even show them ads. Maybe we should forfeit advertising revenue until a person just clicks add friend or accepts friendships so they can Get a critical mass of people that we can then start to show them content through newsfeed. And, um. And so sometimes it's a little bit of initial conditions of understanding, like, did we assemble the thing correctly? Is. Is it that the bike is bad or is that we just did a poor job of like, assembling it? Right, yeah. Anyway, I don't know if these analogies hold, but.
No, I love it.
I love it.
Enjoying the conversation? Got a question you can ask Soleo's digital mind? Just check the link in the comments or description and you've spoken a lot about intuition. Another one of our required readings is Build by Tony Fadell, where he talks about intuition first and then validating assumptions with data. When you moved to Dropbox, you built your intuition as a designer at Facebook, where it was build fast and break things. And Dropbox all of a sudden was this very trust and safety focused company because people are trusting with data. Did you bring that build fast and break things intuition with you or did you have to reframe everything?
It was a challenging transition because I joined Dropbox as an investor and advisor to the company and it ended up becoming a full time employee at the end of 2012 after working with them for almost a year. And by that point the company was four years old, so its culture was, I would argue, largely baked. And having now lived abroad for a couple years, it kind of felt like living abroad, where you feel a little bit like a foreigner and your biases, your intuitions kind of bump up against the native culture. And the native culture, there was one, it was MIT flavored focus on thinking through the entire system, chasing down these edge cases and sort of having a complete picture of the entire system to ensure that it had what Drew used to call space shuttle quality software, where it sort of felt like you can really stake your life on this thing. And they felt internally as a founding team that that was the reason why they succeeded where everybody else failed, that they were really performant and very, very reliable. That once you put something into Dropbox, it was secure forever. What I just described is a very different way of making software than the Facebook. Like, well, we can always just fix it later. Or like, you know, the whole point is that we can rearrange the furniture at nighttime and people will love us for doing it as long as, like, we're kind of like, subtle about it and we steadily make it better. Right. Plus, if you took a thousand Facebook users and looked at their core experience, right, Roughly the same thing. Checking notifications, responding to messages, Reading newsfeed, clicking like, you know, commenting on stuff. Do that same exercise for Dropbox. It just is as variant as like the human condition. Right. People use Dropbox for wildly different things, depending on their trade, how familiar they are with computers, how regularly they're on a laptop or a mobile phone. And so it just required a different approach to problem finding and problem solving because the expectations from the user were very different, the business model was very different and the product surface area was also wildly different. And so it was challenging for me because I had to kind of think through which parts of Facebook are applicable here and which parts just really are not. Right. It was a different sort of sport altogether and I found it enormously challenging because it was not as culturally familiar for me. This focus on excellence over speed.
Yeah, that's a big balance that we have at Delphi because we need the trust and safety people are giving us their data and their identity. But also AI is moving so fast that we also have to have to ship very fast. Do you think you can do both? You think you can manage both? And is it just like you have two different teams for each kind of style or is it depending on what you're working on specifically?
It's a good question. I guess A lot of it centers around strategy. It's like, how, how do you plan to win? There's an element of like corporate regret minimization. Like what, how if you were to fail, like what, what is the manner of failure that would be like, most painful? Right. Would it be like driving the car off the cliff? Or it'd be like just getting run down by like somebody who's just like faster and better and willing to take on more risk. It's like, what? Yeah, that would be excruciating. Yeah. Like, yeah. And, and I think there's also a little bit of, a little bit of like self knowledge here. It's like, what is the part of this team, this company, this culture that is unique and sharp and is like where you can stand toe to toe with any other team on the planet and out compete them? Right. There should be at least coherent narrative there. It doesn't have to be speed, it doesn't have to be excellence. It could be another thing altogether. Right. But ideally those strengths line up with your strategy. So you're not sort of working against yourself, rather you are sort of aligning a strategy to the core capabilities of the team, the core theory of the team. Yeah.
When you were at Dropbox and Facebook, there were fewer people in the world who could Build a product, it was just harder. You needed, the bar was higher. Now the barrier to entry to being a good designer or an engineer is a lot lower. Meaning anyone can really build fast and break things.
Yes.
So does that. Do you think quality and taking your time actually matters more? Because it's the thing that is a bit harder. Less people have patience and more people can vibe code their way to a mvp?
Yeah, it's a good question. I think it depends on what services you're providing. The quality of a napkin is different than the quality of a car, right? And your expectations for the job to be done from a napkin, it's very different than the job to be done from a car. Napkins can't, or at least shouldn't kill you. Your car selection could be a life or death decision, right? How safe it is, if that's a concern of yours. Um, and so I think it kind of comes down to what is the value that you're putting out into the world, how are you capturing it, and what is the way in which the value you put out there is differentiated? What are early customers saying back to you that they sort of are hanging their hat on and saying, like, this is what I look to you for. This is the expectation that I've kind of internalized and expect you to advance in the world going forward. And in the case of Delphi, could be as simple as, like, distribution. Maybe distribution is the most valuable thing that you can offer someone rather than fidelity of the individual. Or it could be the opposite. Maybe it's more like, no, actually I'm choosing this service over others because it is the best representation of me that I can even fathom. It's like, eerily accurate and I'm willing to put in the time and the paces to make it the most accurate. And I'll sort of let the distribution solutions out there kind of like, find me. I think that it ultimately comes down to, like, what is the theory of the end customer and why they end up choosing your product over another? Right. In much the way that every car maker has a theory as why their car gets selected over another.
So do you think design is a moat in an AI world or you don't think it's enough to make you a category King?
I think design is, is a, is a capability. It can be a moat, especially if it is a vehicle for future expectations. I think that there is, you know, there's this value of a brand which both provides, like, recognizability in the world, but it also sort of sets future expectations around what that company might be able to do for you. And you know, take for example, a brand like, I don't know, say Nike, right? If Nike were to announce tomorrow that they're launching Hotels around America, the picture that just appeared in your head is a function of their brand, right? And it has varying degrees of fidelity, but I would argue has pretty high fidelity, right? Because many of you have probably like seen or walked into a Nike store. You've seen all of their collateral, you've seen their aspirational footage. You have felt those commercials that really land in a way that's profound and makes you sweat because you're like, yeah, just fucking go do it. Right? And so that all of that is an encapsulation of brand design which can pay dividends if you're able to service your customers in new ways that sort of fit and further enhance that brand vessel. I think that with software where design can be emote is where it's able to align speed of software development to a novel strategy for how you can create technology or network effects that ultimately bring extraordinary value to an end user. And in some cases its presentation on day one may not matter all that much. Right? I keep. I guess I'm always going to prefer utility over novelty or even beauty because utility at the end of the day is the thing that people have a bone deep response to. If I had a cracked Game Boy that showed you the stock prices of tomorrow, right, you wouldn't care about the design of that cracked Game Boy, right? That would be the most useful fucking thing on the planet. You wouldn't sort of say that like design is its moat. I think that utility is a form of power and design can be an expression of utility. But I think that it ultimately comes down to like how it empowers the individual, the person at the end of the, of the experience. And Facebook often talked about this as like system centric design. And so that's, that's where I always steer towards. It's like, how can design increase your capacity for speed, for understanding the world yourself, your users and for, for driving utility, ideally in a beautiful form.
I'm so happy this is going into your Delphi. I don't need to take a note. So I'm just, I'm just going to, going to be asking it for advice. So something that I think a lot about, maybe you're going to tell me, Dara, you shouldn't be thinking about this. But I do think a lot about it.
Okay. Is your coworkers say that, yeah, we'll.
See a lot of the UX patterns we know today were invented in a pre AI world. And so post AI, the question is, do we try to rebuild what we know about UX from first principles or build on top of what we already have? And I'm a big analogy guy. So the analogy is, you know, you have a stone wheel and then you find rubber. You don't put rubber around the stone, you reinvent the wheel with rubber. And so when we were building Delphi, I'm like, okay, we have menus and buttons and all these things, but what would this have looked like if AI were around in the beginning of the Internet? Is that a worthy question to be asking and spending time thinking about these days or not?
I think my short answer is, yes, it's a worthy question to be asking. I find that it can be just a general approach to designing experiences, and so I think it's just a worthy exercise for this team. If you are an AI native company, you should be just familiar with the tools of today because you know what Google is doing. Gemini is as relevant to what you're doing as what the startup across the street is doing right now.
Last question. I have a couple more, but I want to open it up to questions. What got you excited about Delphi? I know you have tweeted about the idea before.
Yeah. So my last big project at Facebook was Messenger. And one of the things that you do when you're, you know, fixing IE6 bugs and just dealing with, like, you know, bullshit not working, and you're just trying to get something outta the door is like, you try to motivate yourself with how, like, V1 opens up future opportunities that are, like, exotic and weird and, like, where you're, like, accruing power. And we had this internal idea of what we called Oprahbot. And Oprahbot was basically like, you know, if Oprah Winfrey uses Messenger, that'd be awesome, because then we can start to help her talk to anyone on the planet. How much of her texting would we need to know to simulate her? And I found the idea provocative because I had stopped stumbled upon this old Steve Jobs interview from, I think it was from 1985 in Playboy magazine, of all things. I have a hard copy of this thing. Yeah, awesome. Yeah, yeah. I chased this hard copy down. I found it online first, but I chased this thing down. Yeah, yeah, yeah, yeah. And it's a beautiful moment in time because it's shortly before he gets ousted from Apple, and it was just months after they had shipped the Macintosh, which he felt was like his crowning achievement, his great contribution to humanity. And it's a long, winding conversation, but at the very end of it, they're sort of asking him to opine on, like, the future of the computer. And he's sort of like, talking about how, like, if you, you know, what's amazing about technology is that it kind of increases knowledge in the world. And so you, you look at the book, for example. The book was an incredible technology because rather than sort of hearing what the emperor had to say, you can read the emperor's words directly. You can see what Aristotle had to say about xyz. And there was no, there's nobody kind of like acting as an intermediary. You can read the mind of another. And so he was hoping that what the computer could ultimately do for humanity was maybe there is a way in which you can start to stand up and replicate the mind of Aristotle. Wouldn't it be amazing if, like, you can ask Aristotle questions and, and, and, and have his mind opine on things based on maybe what he's written? And if you were to create that system, that would be an extraordinary good for the world, that would sort of fully realize the potential of the personal computer. Now, Steve Jobs says a lot of crazy shit, but he said this in 1985, right? And that promise has lingered in the air. And that promise kept me motivated to deal with IE6 bugs at like 2am, right? Just to get messenger out the door. And I still think that promise, that idea is just sitting out there waiting for the first company to seize it, right? Why I'm excited about Delphi is like, if you guys don't do it, who's going to do it, Right? Why not you guys? And that is my hope, is to support this team as best as I can to bring that into its reality. Because I think the cascading effects of such a system being created are extraordinary. However big you can imagine it, it's much faster. And it introduces a whole set of thorny, hairy questions around sovereignty, around authenticity, around how you sort of represent a mind in a manner that honors what the human learning brain is realizing and internalizing in real time. But nothing worth doing is easy. And I think the privilege of changing the world is having to then own the responsibility of the chaos you inflict. So totally agree.
Well, thank you, Soleo. Yeah, this is awesome.
Thanks, guys.
Thanks for tuning in. If you enjoyed today's episode and want personalized advice from Soleio, head to the link in the comments or description to ask his digital mind on Delphi.
