The Untold Story Behind the Facebook Like Button with Soleio
In this interview, host Dara Lajevardian talks with Saleo (also known as Soleio), an early Facebook product designer and former Dropbox design lead. Saleo recounts the chaotic birth of Facebook’s Like button—originally called the "awesome button"—which spent two years in product limbo, was built as a 2007 hackathon project, and only launched in Q2 2009 after rigorous internal dog‑fooding and A/B testing proved it doubled reads and writes. He explains how Facebook coined the term "product designer" to describe a hybrid role that combined front‑end development and visual design, emphasizing speed, ownership, and the mantra that “code wins arguments.” The conversation delves into Facebook’s culture of rapid iteration, top‑down strategy blended with bottom‑up hackathons, and the importance of data over intuition, illustrated by lessons from onboarding, retention, and the eventual realization that the Like button acted as a social lubricant. Saleo then describes his move to Dropbox, where the culture shifted toward reliability, exhaustive system thinking, and “space‑shuttle quality” software, forcing him to adapt his intuition. He reflects on how modern AI‑native companies must balance speed with trust‑and‑safety, align strategy with core team strengths, and consider whether design can serve as a moat. The interview closes with Saleo’s excitement about Delphi, inspired by a 1985 Steve Jobs interview about replicating human minds, and his belief that building AI‑first UX patterns from first principles is a worthwhile pursuit.
Chapters
The like button, internally it was called the awesome button, it lived in product purgatory internally for about 2 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 try 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. I'm here with my friend Saleo. 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 1,000 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 design, 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, uh, I know you kind of started your design career also developing and, 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.
Um, Came in with the hard questions.
Should have had 2 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 buddies' 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 backed into a little bit because most of the work that I was doing was actually shipping. It was actually producing live experiences out in the world. And that was the 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 over an SFTP server and Back then we were hand-rolling everything. So my foray into web apps was largely as a frontend developer, but because I had, you know, pretty good Photoshop chops and I was able to make things clean and tidy and neat, I found that billing myself as a designer was a bit more attractive to startups in San Francisco than just being a frontend 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 term, 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.
Yeah.
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 used 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 your guiding principles?
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 4 years to do so. Everybody forgets that we didn't get that for free. But the, 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 like our competitive advantage was going to be speed. That we can do everything faster than everyone else, that, you know, a team of 10 could do more in 1 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 in 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 viewed 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 like 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 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 how we work at a startup. And I felt like that culture of ownership and speed was like one of the defining characteristics of the team. Again, it made hiring very hard because we were trying to, you know, call front-end developers designers. But I felt like finding that intersection of people who were good frontend 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 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 2 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. It was— 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 where we were constantly dogfooding Facebook? And then two, did the numbers internally kind of reflect 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 profiles, should I work on privacy, what should I work on as a designer at Facebook? Instead, it reframed it as like, where could 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 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 it can double reads and writes or help contribute to saturating the opportunity space of doubling reads and writes to the system. And so we ended up working on the like button in that context and just by having it be a part 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 roll that 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 God, 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 2 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 Mark really driving you guys to on a weekly or biweekly basis, we gotta just keep shipping even if things break?
We sort of had 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 were on the hook for making sure that we like hit our deadlines, especially if there are ever codependencies. If you kind of need to get things sequenced out in a certain way. It was, it was almost like top-down executive strategy. But there was also this internal culture around like 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 like people can come up with like novel new ideas. And rather than like 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 like, instead of us arguing this out, let's just like 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 like hard data rather than like who, you know, getting into 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 5 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 manner of like social ads, like all manners of things that we thought were good ideas and like were done with the highest intention. But then 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 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, 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, like we had no data to prove that it was gonna work. It just like 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.
Mm. 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 the 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 that 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, you know, 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 newsfeed. Right. And what we— 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 1 or 2 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 a more of an onboarding problem and we should almost be like more regimented about onboarding so that like we know what are the initial conditions that ensure high probability of long-term engagement, doing cohort analysis and figuring out what are the 3 or 4 things that a person does on day 1 that are precursors for 6-month engagement, right? Putting their name on the service, putting their photo, putting one affiliation, whether it's 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 so sometimes it's a little bit of initial conditions of understanding, like, did we assemble the thing correctly? 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 Saleo'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 then 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 4 years old. So its culture was, I would argue, largely baked. And having now lived abroad for a couple of 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 like the native culture. And the native culture there was one, it was an MIT-flavored focus on thinking through the entire system, chasing down these like 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 could really put, stake your life on this thing. And they felt internally as a, 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 1,000 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, 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. Yeah. This like 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 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 if you were to fail? Like 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 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 outcompete them, right? There should be at least a coherent narrative there. 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, 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 an 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. 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, it 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 a way that every carmaker has a theory as to 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 a capability. It can be a moat, especially if it, it is a vehicle for future expectations. I think that there is this, 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 it 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, let's 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, with software where design can be a moat 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 where I always steer towards. It's like, how can that design increase your capacity for speed, for understanding the world, yourself, your users, and for driving utility, ideally in a beautiful form.
I'm so happy this is going into your Delphi. I don't need to take notes. I'm just going to be asking you for advice. So something that I think a lot about, maybe you're going to tell me, Dari, 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 know, 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 in Gemini is 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 fixing IE6 bugs and just dealing with bullshit not working and you're just trying to get something out the door, it's like you try to motivate yourself with how V1 opens up future opportunities that are exotic and weird and where you're accruing power. And we had this internal idea of what we called OprahBot. And OprahBot was basically like, 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 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. Oh 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, you know, just months after they had shipped the Macintosh. Which he felt was like his crowning achievement, his like 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 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 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 2 AM., 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 didn't do it, who's going to do it, right? Why not you guys? And that, that is my hope is to support this team as best as I can to bring that into, into 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 like 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, the chaos you inflict. So totally agree.
Well, thank you, Saleo. Yeah, this is awesome.
Thanks, guys.
Thanks for tuning in. If you enjoyed today's episode and want personalized advice from Saleo, head to the link in the comments or description to ask his digital mind on Delphi.
