· 33:46
0:00
It's one of those things where if you build this magical experience, developers are inherently I would say, like, sceptical or kind of dubious. And so it's important that you kind of open the curtains a little bit and show people how it works. Hi, you're listening to Scaling DevTools. I'm Jack. And we're joined today by Dennis Pilarinos, who is the founder of unblocked. And before that was the founder of buddybuild, which was acquired by Apple.
0:28
Dennis, thank you so much for joining. Thanks
0:31
so much for having us and looking forward to it. So,
0:33
unblocked is a tool that lets you ask questions about your code. So it's like broad questions, rather than just like, how do I loop through this array? It's like, where do we? How do we manage our secrets? How do we this sort of broader questions?
0:51
Yeah, the idea is that you take the source code and complement it with all the kind of coded JSON systems that you used to have conversations about your, your source code of your application, like Slack and notion and linear. And in conjunction of, you know, source code plus all that data, you can ask really kind of high level or very specific questions and get an answer to anything that you might want to know about your application code base. That's
1:14
awesome. And what stage are you guys are at the moment,
1:18
we launched the company, or we announced the company in October of 2023. So we're a few months in public, we have a couple of 1000 developers who use it, and the majority of them use it almost every day. So people seem to be liking it. So very early, very early days, but kind of off to a good start in terms of testing this thesis, like, Is this a real problem? Can we solve it in an elegant way?
1:42
Amazing. So we're gonna come back to two unblocked. But the thing I wanted to ask you in this episode is like, what you learned as a founder, who sold a developer tool to Apple, and is now building another developer tool, and kind of like the the journey you went on and what you've learned in doing differently now. So could you tell us a bit about buddybuild and how you got acquired by Apple? And what that was like? Sure,
2:11
yeah. So we went from inception to acquisition for buddybuild and almost three years to the day. And so people often ask me like, Well, why did you start buddybuild? Or what's the motivation behind starting unblocked? And I think it's a consequence of like, I'm not a super patient person. And I'm a very mediocre developer, I would say, like, people would describe me as impatient. I'm self aware enough to recognise I'm not very good. And so those two things combined, when I started to try to do something, I always asked myself, Why does it have to be this hard. And so for buddybuild, a couple of friends and I were trying to build an iOS app, and you know, standard workflow, get pushed, get a bill, test it and kind of provide some feedback. And we're blown away by how hard that was. So he kind of gave up on the app and said, Well, what if you had a hosted CI solution for mobile, of course, we didn't talk about it in that way. At that time, we just really wanted to like focus on that workflow. So we built that. And we kind of built it in a way where we really optimised for a kind of a developer experience where we treated developers as like how most people can build a consumer application where you didn't have to do a lot of like, spelunking, or configuration. We didn't want you to have to change really any part of your the way that you worked or your project, you could just instal an OAuth app, have it, you know, introspect over the repository and automatically create a build for you. It was pretty remarkable. People were sceptical that it was possible to do it in many ways. And yeah, we, we built a product that people loved. We had, you know, 1000s, and 1000s, of developers who use that product from all over the world. And so I think that kind of registered on the radar for a handful of folks, and Apple was one of them. And so, at one point, they asked if they'd be interested in, you know, acquiring a company and the team working there, and we started to explore that. And so that kind of kicked off a pretty long journey, in terms of like having these conversations and figuring out what we wanted to do. But yeah, it was a pretty kind of surreal process.
4:14
Yeah. No, it sounds like it was like, I don't know, like free as if just the way you've explained it there. It sounds like it was just like a very kind of smooth, like, I'm sure it was a little bit. They always have the hiccups along the way. What, like, was it a hard decision to kind of decide to sell to Apple?
4:36
For sure. Yeah, absolutely. It reminds me of this graphic when people are like, wow, from inception to acquisition kind of three years. And there's this meme like internet graphic where it's kind of a chart or a graph, and if you've seen it, where it's like, what people think success looks like and it's, you know, point A to point B up into the right and what it actually is, which is like, you know, right, yeah, just absolute misery, followed by, you know, incredible moments of happiness. So The whole spectrum. Yeah, selling to Apple was definitely one of the things that we want to think very carefully about. I had experience building and running teams at places like Microsoft and Amazon. And so I kind of know what working at a big company is like, and the pros and cons of it. And we thought seriously about that, as we thought about joining apple. And so that was probably one of the, you know, certainly things that we spent the most time thinking about as a company if we want to do it. In fact, during the acquisition process, one of the things that we did was get everyone in the company to actually get into a room and just do a thumbs up. Thumbs down, we had been speaking to a handful of folks who kind of met us, who had flown up to Vancouver, we chatted with them. And at the end of that kind of day, we all got together. And as like, if anyone, any single person, you know, from the office manager to the CTO, decides to put a single thumbs down, we won't do the deal. And everyone, you know, after having these conversations, were suitably impressed. We liked the people that we worked, were chatting with, we thought there was an overlapping culture, we were excited by the opportunity to, you know, take buddybuild to, you know, Apple scale. And so everyone put their thumbs up, and we cannot proceed through that process. But it was, it wasn't just the decision, certainly that I made or the founders made. It was a as a team, my decision. Wow,
6:23
that's really cool. I would have I would have been interesting. If like, Joe on the internet, it's like, this
6:31
would have been interesting to understand why, but yeah, for sure.
6:33
And I asked you, I was doing some research on like CI CD tools. I used to be a mobile dev a while back. And I remember like, because I think it's buddybuild still around.
6:46
No, not just so buddybuild leaves on his Xcode cloud, which is basically the integrated environment that you have within Xcode now. And so the, you know, the vision of buddybuild certainly exist there. But buddybuild.com was shut down, which is still sad for me at times for sure. Yeah, that's
7:03
kind of like how I remember was the people like saying, Oh, buddy, that was great. And then someone else like, Oh, it doesn't really like it's not really existing anymore. And this was like after. So it seemed like you have like, had like a really good, like, developer love situation going on? Which or? Was that the reason? Like, would you? Do you feel like that was why Apple bought you? Or were they like weighing up other companies? And is there any advice that you would have to other founders?
7:35
Yeah, I mean, I think there's, there's so many different angles to it, I think one of the things that, you know, we had was a tonne of experience building secure applications of like, reasonably high scale that were cloud based. And so certainly the team that we were joining at Apple didn't have a lot of experience with that. And we knew a lot at that point about how people built third party applications, you know, iOS and Android applications. And so Apple was really interested in making sure that they kind of owned a lot of that experience and kind of that internet, intellectual property and kind of knowledge. We, you know, one of the things that we really, really do obsess over kind of what a developer experience looks like. And so I think that's one of the things that we tried to like, also influence at Apple in terms of like treating developers, not as like fungible assets, who, you know, help promote the ecosystem, but as like, real people, where when you break an API, it matters. So we really to really, you know, sweat a lot of the details from every pixel that was on the dashboard to, you know, the API's that we provided to kind of kind of the product made you feel, I think, one of my favourite pieces of feedback that we received in the very earliest days was something that someone had written into us where they said, the product basically gives them back a significant portion of their time that they then get to spend with their family, which is like, you know, I was just blown away, but I love that and we would get, we got fan art, people would send us art around how happy they were using the product. So it was super fun. That was definitely one of the things that we're trying to do an unblocked again.
9:14
Wow, fan art. That is. That's a pretty big bar. If anyone's listening to try to reach that, why do you think that you were able to hit that level? And do you think it was like the experience with a team or is it like a cultural thing?
9:32
Yeah, I think fortunately, I've worked at like I said, I've worked at places like Microsoft and Amazon, prior to buddybuild and you learn what aspects of the culture like resonate with you and kind of what work you know, working in a small company versus working at a big company. There's definitely kind of trade offs and things that you should apply a certain times versus not. One of the things one of the things I really liked about Amazon was its hyper hyper focus on it. It's customers like, they have these leadership principles. I think there was 11 at the time now there's 13. And whatever the number is now, but those are not platitudes. Those are things that people refer to on a day to day basis as part of the conversations that they would have with their co workers. And so this, you know, bias for action and being super customer obsessed. It's something we cared a lot about, even at unblocked today. And for most of buddybuild, I do all right now I do all the technical support and a buddybuild I did a more majority of it. So I would be up at 435 o'clock in the morning, answering questions from people who were in Europe overnight, really understanding kind of like, where it worked, what the product didn't work, what features we should be prioritising. So just really getting your hands dirty, and people would be blown away by it. They're like, Oh, they're talking to the CEO. And I was like, it doesn't really matter. I mean, I'm just someone who gets, like, really want to feel the pain to kind of solve these problems for folks.
10:58
Yeah. And it's interesting, you say pain that like, I feel like deploying apps is something that is like a very, like, emotional thing, almost in developer teams, because it's like, if it fails on a Friday or something, it's like, you're, you're kind of screwed, you're going to work late. And like, none of your work counts until you get it out. Was it something that you were thinking a lot about, like building something that people like care that much about? It's like, because you could have done something else that like, wasn't such a big deal to people? Yeah,
11:35
I don't know. I mean, ci certainly is probably not the sexiest developer tool to kind of go into, I think, almost irrespective of where you are in the developer ecosystem, or what part of the tool chain or workflow or scenarios that you're thinking about, one of the things that, you know, we care a lot about is making sure that people have an amazing experience. So, you know, one of the things I didn't want to have to subject our users to because I didn't want to have to do it is change my project in any way, shape, or form unless it like accrued some value to me. So our onboarding experience for buddybuild was you literally pointed it out to a repo. And you'd have to check in a file and describe the branches or any of that kind of stuff like which one we should build, or how your dependencies work. None of it. All you did was just like, pointed out to her pointed at a repo, we had like a very, very high rate, I'd say like in the high 90s People would get a green built just by like saying build this repo, that's it didn't have to do anything, because that's kind of the experience of, you know, I wanted in the team wanted to be able to provide, how do you do that? Well, there's a lot of work to make it seem, actually, in fact, I remember the very first version of like, kind of that onboarding flow, people thought it was totally made up, they didn't think there was actually a green bill, because it felt so magical. And so when people would be like, you know, they honestly think it was bullshit. And they'd be like, oh, there's no way it actually built the thing. So what we had to do was actually built a streaming kind of service. So you could actually see the log lines coming out of the build system, somewhat sanitised, or whatever. So you could see it actually building you could download the binary there afterwards. So, yeah, it's one of those things where if you build this magical experience, developers are inherently I would say, like, sceptical or kind of dubious. And so it's important that you kind of open the open the curtains a little bit and show you how I show people how it works.
13:22
Yeah, I really like that, that that makes a lot of sense. Yeah. And it is such a pain, like, I mean, now, and I know a lot of people use like Fastlane. And I don't know if that was around, like when you were Yeah, that like, huge file that you kind of can config. And you can spend days and days and days setting this thing up. And it's so it's pretty amazing. They could just get like a 90, you could get a 90% success rate on on building. Yeah,
13:55
I mean, there's a place for you to get started and then kind of evolve it. It's the same thing that we do with unblocked, which is a lot of almost all the teams that use it when we chat with them to like, Look, our codebase is absolute spaghetti, dumpster fire, we're embarrassed to like kind of onboard it. And everyone thinks they're like a unique snowflake snowflake. And it's everyone feels that way, I'm sure. Well, there's definitely members of the team that feel that way about our code base. And so we don't want you to have to change like refactor your repo or like, you know, reorganise your, you know, Google Docs or how you use notion, like, you should just work the way that you want to work. And the product that we build with unblocked just uses it the way it is to provide a really compelling experience. Like it's, there's no work on behalf of the end user in order for you to get something that should feel magical.
14:45
Okay, that's very, very interesting. So let's say like this week, you wanted to like make it you know, slightly more magical. How what are the kind of like things that you do in that process? One
15:00
of the things I learned early on in my career, which I always thought was a really good kind of heuristic, or framework is is something called be XT business experience technology. So is there a business behind the thing that you're trying to build an important question? Because if there isn't, it's not long term viable, then our processes, we really think through what is a really kind of kickass compelling experience? Like, what is the X? How do we make sure that like, that feels amazing. And so we sit down as a team, Design Engineering myself, and we say like, would that feel amazing? Would this feel amazing? And then really, we spent a lot of time kind of in figment, that design process to say, you know, remove the constraints of the technology as it exists today, what would be an amazing experience, and then go and build or use the technology to create that experience? And so sometimes I find a lot of teams are focused on what's the technology I have at hand? And how can I make it do something cool? We are, what would be something cool? And like, let's make the technology happen to make that experience possible? Would
16:04
you work on something if the technology required you to like go go away for like, a year and work on it? Or is it like something that's like to set like any upper limit on like, the diff, the time between like, this is what would be amazing. And then like actually releasing, there's
16:22
often kind of stepping stones for you to get there. But we generally try to make those stepping stones kind of as, as meaningful as possible. So you might have like a fullness, like of what that experience might look like. And you're like, Well, if we ratchet it back and build this thing at this point in time, then would that be compelling? Once it's not, I don't know that there's really any point in like releasing it. So it is one of those things where we basically we'll wait until we think it's really good. And we don't think there any issues with it and kind of go from there.
16:54
That's interesting. And do you do like to bring many like user? Like, are you talking to your target user? So that point or
17:03
so, you know, there's kind of two phases, generally, when you have a lot of people that you can ask, you know, hey, what do you think of this and not? You don't have anyone, then you kind of have to, you know, fortunately, we build developer tools. We're a bunch of developers. And so we can say, Yeah, based on our perspective, and what we might like, at a certain point, though, you kind of have to, that can actually be a very significant hindrance, and you building a meaningful developer tool, I think it's very easy for people who develop who build developer tools to say you should have work like this have a very opinionated way of of working, or what that experience should look like. I think you need to be like, you know, strong convictions loosely held, be able to like say, hey, you know, here's this hypothesis of the problem that we're trying to solve. Here's an experiment that we want to run, and say, you know, we think the way that we should best solve this is through this kind of software experience, and have an opinion, go out, show people and if it works, then you're gonna get more and more people at a certain point in time, you can spin up a small group of early adopters, before you release it to like the masses to say, we think this is magical. Do you think this is magical, and you know, kind of iterate with those folks to kind of sanity check your stuff? The weirdest thing about it is like, it's this almost weird paradox where when you come up with the idea, you're like, Oh, this is magical. And by the time it's built, you're bored of it. You're like, Yeah, whatever. Let's move on. So and then you release it. And then people are like, Oh, this is actually really cool. You're like, that is really cool. I forgot about that. So it's this weird, weird kind of cycle that you go through? Yeah,
18:40
I struggle with that myself.
18:44
I think you know, every, every artist, no matter what creative process they go through, when they have the final product, they more often see the deficiencies of it than the actual art that they've created. Like, you could talk to any historically significant artists and be like, Oh, what's your favourite work? They'd be like this, but I wish I had, you know, that's how it all almost I think almost every software engineer feels the same way. You don't want to know how the sausage is made.
19:14
Yeah, that makes sense. One question I had, because I feel like this is something that a lot of people struggle with, is how you segue how you come up with like, a ideal customer profile like user when, like any realistic, like any developer would want to like, ask, ask questions to that code. Or, you know, almost anyone. Like, how do you think about like, customer like target customers?
19:42
Yeah, it's a good question. So for us, you know, you try to think of the extremes, right? And we've been fortunate to experience them a group of four people who go into the office every single day and know the codebase because it's six months or a year old, probably don't need to know a lot about how the nobody's worse because they have it all pasted into their brain. Some of our customers are like, well, some of them are decades old, but let's just say 10 1215 years old, who have 1000s of repositories and 1000s of people, those people, there's no way that any single person could page in and understand how the entire history for every part of their code base. And so the software that we're building is kind of uses, you know, the LLM stuff, as an enabling technology to solve a very specific common workflow, right, which is, a developer has a question like, why did we do it this way? Or how does that work? Or who should I talk to, and so you can use this technology, the LLM AI stuff to actually solve this human workflow that happens every single day. So in terms of like finding our ideal customer, well, it's kind of Goldilocks, right? Once too, too hot once too cold kind of look for the one that's just right. I can't imagine that like, well, having worked at Apple, this is not a product that Apple should go and roll out right now. Maybe at some point in the future. But given like that size, and kind of the software engineering complexity, how they organise themselves, how they share information or not, it's not a great fit. But there's, I don't know, one and a half to apples in the world, depending on who has the highest market cap at any given time. So you know, you just have to find that sweet spot in between.
21:23
How does that like? Like, do you find those people? Like, if you're looking for the sweet spot? Is it like, how are you? How are you going out and finding them?
21:33
Yeah, that's a super good question. Like, how do you get started, it's always like, it's one of those flywheels, that's, you know, I hate that kind of, kind of expression, or that an analogy, but it is really like, it's really, really, really hard to get started, like, it's very painful to have it start moving. So you really kind of have to beg and plead and you know, kind of do whatever unnatural acts that you can get to like, say, like, Please, someone use my software. And then if you build this magical thing, the flywheel kind of starts to move a little bit. And so what we've seen is like, people seem to really find value in the product and are starting to love it. And so they start to tell their friends, and then those people enjoy it. And then they start to tell their friends. And so it starts, the flywheel kind of starts to move onto itself. But in the very early days, it's, you know, asking friends for help or favours to say, like, Hey, would you use this? Tell me what you think. I've recently talked to another CEO, where his company's probably eight or nine years on now. And they're doing 10s of millions of dollars in revenue. And he misses these. He's like, I remember my favourite part of thinking about building a company is all the rejection in the nose that you get. And I was like, I think that's an easy thing to say, when you're making 10s of millions of dollars. Constantly getting like smacked in the face. You kind of have a slightly different perspective on it.
22:53
I was gonna say that sounds like a kind of like a one of those influencer tweets of cold plunge as well. Yeah, exactly. Interesting. Okay, so I want to like specifically ask you like, what do you do differently now that you didn't do with buddybuild?
23:12
I think there's a yes, there's a couple things, I always had this analogy of like, when you're doing building a company for the first time, you're kind of walking into a dark room that's littered with furniture, and you're probably going to smash your toe on a bunch of things. And so hopefully, you just get bruises and not breaks. In the second time around, you kind of have a layout for what the furniture is, and you try not to like bump into the same thing twice, right? We're still gonna make mistakes. Because things change, right? The ecosystem, the environment isn't static. So of course, it's like, someone just moved the chair or, you know, put a floor lamp where it wasn't last time or what have you. So trying to make some of these things. But very specifically, I think, one of the biggest, I don't think a lot of people talk about this, but one of the biggest things is, you know, from zero to three years, that's not working 3540 hours a week, that's working 6070 hours a week for three years, like barely taking vacations really being obsessive about building that business. There's, you know, unquestionably I went through kind of a depressed period after the acquisition, where I kind of lost my identity and purpose, because it was buddybuild, like, I didn't have any kind of space or time for that. And so one of the kinds of things that I talked about, so the team that's building unblocked is a lot of the original members that built buddybuild. And so one of the things I asked is like, I am an obsessive person, don't let me get to a place where it impacts kind of like effectively my mental health and so I set up you know, very specific ways to make sure that I don't fall into that rabbit hole that is just constantly obsessing with it and so you know, try not to work on Saturdays going for walks, I got a dog dogs are time consuming things like that.
24:56
Yeah, it's, this is kind of taken it sideways. I spell like, I remember when I finished university, I did like, a startup full time for a year. And it was with my friend and we, we slept, we had a room, like a flat and we slept in the flat and we worked like all the time. And we, we did that for like nine months. And we made a tonne of progress. We did quite well, but we burned out, we ran out of money. And we, you know, we left and in, in hindsight, there were a lot of successes on the way but like, it's one of those things where like, I there's this like, kind of side to you where you're like, even when you're like, Yeah, I was really depressed or like it was dangerous. It was bad for my mental health. But you also feel like proud of it that you did it and that like you're like, I don't know, like, do you have? Do you find that it's like kind of this weird thing where you're like, most proud of like, the pain that you put yourself through, in a way?
25:55
Yeah, I think it's easy. You know, sometimes people think like, why would you start a second company like, especially in Developer Tools, you must be a masochist in some form, shape or form? And yeah, there's probably a masochistic tendency, right? Yeah. Just like whipping myself. The pride is, I think one of the things that like, certainly, I don't know, just like my predisposition, there's no pride in, in the beatings. Certainly, like, I think I probably maybe internalise that, which is like, I'm a relatively competitive person. And so I like to make sure that the stuff that I work on is really good and quote unquote, wins for whatever that's worth. But it's not winning against someone else necessarily. It's winning against what I think is possible. And so I don't know that I ever kind of externalised it. People want to talk about the Apple acquisition or selling company, Apple, so on and so forth. But that was kind of a means to an end, in some capacity. It was just like, how do we get this vision at like, kind of the, you know, the biggest possible scale? And so, yeah, I don't know that I would. I wouldn't show I wouldn't show anyone the scars, but there's a lot of them. Always happy to talk about them. But it's not something I wear with pride, I guess. Yeah. Does that answer your question, I guess is that they
27:16
also kind of gives me an awful lot of like, do you feel like proud of like the Buddy Belts?
27:22
You know, yes. And no, I think it's a, it's a great way of accomplishing. It's a great kind of experience to kind of go through, it's a great accomplishment to be able to say like, Hey, we built something that people loved. And that was memorialised by kind of an acquisition by, you know, a company that is unquestionably like one of the best in the world. That's very humbling, in many ways. But I think, you know, when I go back to like, what were the highlights, it wasn't the acquisition, it was the it was the fan art. It was the, you know, people saying thank you for giving back the time that I can spend with my family, things like that, or, you know, that's the most humbling that's like I think the to the degree that you can take a problem that most people find, quote, unquote, not interesting, and build something that people actually really love. Maybe that's why I do it the second time, right? It's, I think anyone who starts companies has some level of ego. And maybe that's, you know, that ego stroke of having someone really love the thing that you build. Maybe that's the that's the accomplishment, or that's the that's the thing that kind of motivates me.
28:26
Yeah, that's, that's very interesting. And did you did you like is that highlight? You kind of missed that from the time that you were working at Apple? As like a software? Bug flick? Was your director of technology? Right?
28:41
Yeah. And developer tools? Yeah. So yeah, after Apple, I took a year and a half off. And I remember meeting a guy actually. And I was like, oh, you know, it's decompression. He's like, no, no, man, it's recovery. And I always thought that was a very interesting way of describing it. And he was actually probably pretty true. Like, I remember after the acquisition was a Saturday morning, it was 830. In the morning, I was hopping into the shower. And I was like, what do people do if they don't work on Saturdays? Like, I just didn't? Like, working, but I was like, okay, yeah, that's kind of what you do. So yeah, a year and a half off after, after this after the acquisition. And I started thinking about this problem, right? Like, it seems painfully obvious that we have these gross inefficiencies in getting the information that we need to get our jobs done as engineers. And so it was like, Well, that just kind of bugs me, right. The way like the most acute way that we feel this is people send us slack messages or tap us on the shoulder and say, like, Hey, I have a question. Like, at one point, we were going to call the company bother, right? Like, don't bother you, won't bother you. You know, everything's good, weird, negative connotations. But I was like, man, it'd be great if you could just like ask questions and get responses or you know, as you're scrolling through your source code, you can see all of the conversations in notion in Slack and all your bugs were laid the source code that you're looking at, that'd be amazing. And so I was kind of passionate about solving that problem. And I've always optimised my career for the people that you work with should be like a significant, like, it's 85% a decision of anywhere that I would go and work. And so getting an opportunity to potentially work with the, you know, the buddybuild, the team that built buddybuild was, you know, just something like if there was an opportunity to do that, to solve this problem, be kind of crazy not to. And so that was the motivation to kind of go back and clearly I'm a masochist in some capacity.
30:33
Yeah, that's, that's really, really interesting way to put it. Yeah. And I think, Dennis, we're coming up to time. But would you have any takeaways that you would give to a founder, you know, currently going through their first dev tool experience,
30:55
a couple of things, I think things that are unique to Developer Tools is, the way that you work is not the way that everyone works, right. And so you have to be like, You need to have those kinds of opinions for potentially how it should work, but flexible enough to accommodate. And so I think, unlike other businesses, it's very easy. I think developers to be like, well, you should organise your project this way. Or you should think about dependency management that way, or whatever it may be. So that's probably one, too. You know, things that are kind of like less specific to developer tools. But like, really make sure that the people that you're working for or working for, I always think that I work for the team, even though I'm like, you know, the CEO, but like, we all work together. And so make sure that the people that you're working with are people that you respect and admire, that they are better than you in some way, shape, or form. And so I think that's like, you know, those are kind of one that's very specific to developer tools. And one that I think is like, is very, kind of broadly applicable for any company that you start or any company that you work at, for that matter.
31:55
Yeah, it's actually interesting. You know, like, people always say, like, first time founders talk about products, like second time talk about go to market, I felt like the thing that you've spoken most about is people. And then in the conversation, I
32:10
think, like, you can't build a great product or go to market motion, unless you have fantastic people. I'm still very, very obsessed over the product, like repeatedly as like, if you build a product that people love, the rest really does take care of itself. People will tell other people, you don't have to have a structure go to market, you know, thing, but like you will at some point, but you can get a long way by building a product that people love. Well, how do you do that? Well, you have to build it with really good people. So yeah, that's kind of a very analytical, maybe Machiavellian way of thinking about it. But
32:45
that's no, it's definitely not. So where can people learn more about you and about unblocked? Sure.
32:51
The easiest thing to do is go to get unblocked.com. We want developers to get unblocked and so we'd like that kind of domain name where you can get the software and you can help yourself get unblocked. So yeah, get unblocked.com is where you can get that and then I'm just Dennis Pellegrino saw on Twitter. So super long last name, I think they've been Dennis Apple, Vancouver, you'll, you'll probably get me.
33:15
Amazing. And thanks, everyone for listening was actually my first ever plug that I really should have done for. If you listen and you enjoy the podcast, I really appreciate it if you could give us like a rating and Spotify and Apple and all these sorts of things. And give us a shout out. Yeah, thanks, everyone for listening. And see you again soon. Thank you, and thanks for thanks for coming.
Listen to Scaling DevTools using one of many popular podcasting apps or directories.