Products For Builders

[00:00:17] Speaker A: Hey, it is bootstrapped web. We're back after a week off. Jordan, how we doing, buddy? [00:00:22] Speaker B: We are doing well. Had a long week. I'm. I'm a tired dad. [00:00:27] Speaker A: Yeah. [00:00:28] Speaker B: Yep, yep. Been on my own for a week. [00:00:30] Speaker A: You're on your own this week? [00:00:32] Speaker B: Yes, yes. My wife's sister had a baby, so she's visiting the new baby, and I have been on my own Monday to Friday. It was a big, busy week. I got through it. I didn't do takeout more than once. You know, I cook dinners. Oh, the whole thing. [00:00:48] Speaker A: That's impressive. [00:00:49] Speaker B: Yep. There wasn't too much fighting and crying. Things worked out. People got to places on time. I didn't miss any rides. It's a lot of rides. [00:00:55] Speaker A: Hey, those trains run on time. [00:00:58] Speaker B: I had some help, some remote help from my wife, but we made it through. [00:01:04] Speaker A: Yeah, I left my wife with the girls last week because I was in Cabo, Mexico. I had to suffer through a week at an all inclusive five star resort in Cabo. [00:01:19] Speaker B: Yeah, so that sounds horrible. I saw some pictures. Whatever's going on at that conference seems like all the right things like, that conference looks like so much fun. [00:01:31] Speaker A: Hey, Chris. Lemma. Really? I talk about it every time I go. This is maybe my fourth or fifth time going there. I ended up. I was sort of like a last minute attendee, but I ended up being one of the speakers. I sort of stepped in for someone, and, yeah, it was such a good time, and Chris really does it well. From the curating of the attendees, I think it's about 50 people who go down there. He goes deep on vetting every application and making sure it's the right group. It's like half returning attendees, half new people. So I got to meet some friends in person that I've known for a while. I've got to hang out with some returning people, met a bunch of really cool new people. The structure of it, you know, full, full, all inclusive, like, really one of the best resorts I've ever been to in Cabo. Amazing resort, amazing. Restaurants, pools and beach are incredible. What he does is, like, half the day is like workshops, quote unquote, workshops, but we're, like, waiting in a pool, talking about business, and then a lunch. And he actually, like, puts you together with lunch groups who, like, fit your, you know, fit whatever you're. You're working on. And I had an incredible lunch group with a couple other SaaS people. Um, and then, and then the afternoons are totally open. But what that means is, like, everyone's just in the pool with drinks, talking, more business, you know, and then dinners. [00:03:01] Speaker B: It sounds like fun, man. Workouts in the morning and we had. [00:03:04] Speaker A: Workouts in the morning like three days in a row. 07:00 a.m. yeah, I have to. Felt great. [00:03:10] Speaker B: I have to ask, this is cabopress. This is WordPress adjacent. [00:03:15] Speaker A: Oh yeah. How? [00:03:16] Speaker B: I mean, it feels like it's turned pretty dark and negative in WordPress land. It's not like a little debate between a company and automatic. It feels, it feels like it's in a really bad place. [00:03:30] Speaker A: It is, yeah. This conference is, it's historically very WordPress. So there's still a lot of that. There's definitely a lot of people who are just not in WordPress like me, but yeah, there's a lot of people. And so I got to actually talk to a bunch of people who are in like pretty large WordPress ecosystem companies, a few people who are starting things up in WordPress land. There are many agency owners there who work in the WordPress ecosystem. So how's the. I definitely got a feel for that. Plus what everything else that we're seeing on Twitter and all the, I mean, every day it's like something else with this thing. [00:04:09] Speaker B: Yeah, people. Yes. I don't really know, I don't know if it's any point in like talking about it, but I assume, I assume it was, it was pretty, it's pretty tough goings over there. You see people who still want to work there staying, they kind of sound like they're hostage it. You know, you can read through the tweets, not good. Then you got me, who are contributors to WordPress core who are leaving the project. You got private companies, you got people taking sides. [00:04:34] Speaker A: Yeah, I definitely, I'll just report on like my observations. These are literally not even opinions, just what I'm seeing. Number one, this isn't even specific to cabopress, just in general. I know people who run like significant companies in the WordPress ecosystem. I won't name them, but yeah, they're not enjoying this and they can't really talk publicly about their opinions, like too dangerous. Some of them talking about like how, yeah, I drafted this whole blog post about it but I can't publish it, stuff like that. And then yeah, just talking to people at Cabopress and elsewhere, I'm definitely seeing a trend multiple times across multiple companies. There are some who are like well established companies in the WordPress ecosystem. They are taking active steps to spin off and try to detach themselves from WordPress. So that looks like these are well known brands and they are going through a big rebrand to say like we are something new now, or they're doing something like taking a version of their product or service and spinning up a new version of it off to the side under a different brand. That's like not WordPress. [00:05:49] Speaker B: So it's like risk management here. Both reputational. What you say publicly where your company focuses. I feel like I've seen people start looking at different frameworks and different platforms. [00:06:00] Speaker A: So the other thing that I'm seeing is startups. So like people who are in the process or have been planning and working on starting up a new product or service into the WordPress ecosystem, they're actually changing their roadmap and changing their plans, sometimes changing their name to say like this, I'm still doing this product, but it's not for WordPress or it's not just for WordPress, it's separate or broader or like I'm just seeing that with multiple. So we're seeing, because if I'm bootstrapping a new product, I'm not doing it in WordPress today. [00:06:39] Speaker B: Pretty rational. [00:06:40] Speaker A: That's not something I'm going to do. [00:06:42] Speaker B: It's not like a vindictive thing, it's a rational decision to say, I don't think I want to bethe the same way. I'm watching other people that bet years into this ecosystem. It definitely brought up a lot of Shopify memories. I saw a lot of people trying to define platform risk as a very specific thing. Like hey, if the platform doesn't do x, then it can't be considered platform risk. I thought back to my experience in how what's under the surface is actually much, much more damaging than what's explicit meaning. These thoughts, these decision processes that are impacted by fear and by intimidation and by rational calculation, those changes overall are bigger than the actual, you must remove this from your website. You can't do x. A lot of the things we did with Kartik and Shopify, they were just, they were just warnings. [00:07:46] Speaker A: Yeah. [00:07:46] Speaker B: Just, just a gently worded request from the platform and you're put in a position of that sounds like a request, but there is no option. There's only one option to that request. You can't say no, thank you. Yeah, and I think that's, that's happening a lot. At some point during the week I felt like it was so kind of ridiculous, all these crazy screenshots, people getting. [00:08:08] Speaker A: Banned from slack, the screenshot thing. [00:08:10] Speaker B: It's really crazy. [00:08:13] Speaker A: And by the way, that's one of my most popular tweets ever. Apparently it's over. I don't know, like a thousand likes, 600 likes, something like that. And like, what is it? [00:08:21] Speaker B: What did you post? A screenshot of something? [00:08:23] Speaker A: It was just a spur of the moment because this happened the other day. You know the screenshot that's going around of the checkbox? [00:08:30] Speaker B: Yes. [00:08:30] Speaker A: To log into the WordPress.org back. So if you're a contributor to WordPress.org now, when you log in to contribute, you have to check a box to say, I think it says, like, was. [00:08:43] Speaker B: That you spreading the screenshot? [00:08:44] Speaker A: No, there was this screenshot of that checkbox that says, like, I am not affiliated with WP engine or something like that. Right? I don't know the exact word. [00:08:53] Speaker B: So crazy. [00:08:54] Speaker A: And I saw those screenshots floating around. I was like, oh, that's a funny joke. Like, somebody photoshopped this thing. Yeah, that's silly. You're like, imagine if they put a checkbox like that. [00:09:03] Speaker B: That would be so crazy. [00:09:04] Speaker A: That would be crazy. And then I like, and then I saw someone else do it and someone else do it. I'm like, wait, is that real? And I looked at it. I'm gonna see if it's still there right now. It is. [00:09:15] Speaker B: Yeah, I think it is. And I saw someone get banned from slack for asking questions about it and saying, hey, is this gonna be remembered in some way? This is pretty weird for someone's, like, career for sure. Looked at the source code and was like, yes, that's being flagged in the database as this person signed in, checked. [00:09:36] Speaker A: So as soon as I realized like, oh, this is actually not a joke. This is actually a real thing. And I'm looking at it right now. Yeah, it's a check. So you're logging into WordPress. There's a checkbox that says, I am not affiliated with WP engine in any way, financially or otherwise. And I was like, wait a minute, that's not a joke. [00:09:55] Speaker B: Yeah. What is that? And there's no way that's not lawyer speak. That's just some dude. [00:10:01] Speaker A: And you know what you just said about, like, what? Okay, like, we could, what I said earlier about, like, there's startups who are changing their plans and there are big companies who are, who are spinning off new brands. That's real. But who I really kind of feel for are the independent professionals. So think about people who work for agencies. They're not even like the owner. They, but they are people who have, who make a living that their, their professional career is in this industry. And maybe their agency just happens to have clients who are hosted on WP engine. [00:10:39] Speaker B: Right? Maybe they're an affiliate or who knows? [00:10:42] Speaker A: Or they have a site or two on WP engine or whatever. Or maybe they've contracted for somebody who works with WP engine. So are those people expected to not check this box or check this box or no longer contribute to WordPress.org dot? Or, like, what are they supposed. And it's like, they're not asking for this. They're not trying to take a side here. Like, there are these screenshots of people getting banned from. I guess there's, like, a WordPress slack. [00:11:10] Speaker B: Yeah, that's what I've talked about. [00:11:14] Speaker A: Yeah, I saw those screenshots, too. And it's like they're asking in the most polite way, like, please advise. Like, what am I supposed to do here? Does this impact me legally in any way? Like, I'm just trying to do my work as a professional. What's the deal with this checkbox? And I mean, like, because now these people have to literally think about, like, okay, do I need to change companies? Do I need to change careers? Do I need to do something differently than I have been? Like, it's just a total mess. [00:11:45] Speaker B: It's really, it's not good. What I started to feel toward the end of the week was there's got to be a silver lining. There's got to be some good that comes out of this with people just diversifying their efforts, looking at other platforms, making other platforms better because of it. Right. Like, there's got to be some positive that comes out of this because it is like a moment of, like, creative destruction in some ways where this ecosystem just got just shook up all over the place. And what pops out on the other end, hopefully, there's a bunch of good stuff that comes out of it. [00:12:22] Speaker A: Yeah, I mean, you could make the argument that, like, almost, you know. Yeah. Platform risk, there's all different degrees of it. There's different flavors of it. But you could make the argument that, like, literally all of us have some form of platform risk. I mean, and it's also on my mind because the new product that I'm working on is. I'll actually announce it here. [00:12:46] Speaker B: Yeah, that's kind of interesting. Go ahead. [00:12:48] Speaker A: Yeah, but it's not lost on me. All right, so I'll, I'll talk about the product more in a minute here. But it's at instrumental dot de V, and it's basically the components library for the rails ecosystem. And it's definitely not lost on me that I'm building a product for the ruby on rails ecosystem, which is an open source thing with one highly opinionated individual at the head of this thing. Where have we seen that before? [00:13:17] Speaker B: Did you see DHA? [00:13:18] Speaker A: Yes, I did. [00:13:19] Speaker B: I'm sure you did. That warmed my heart. [00:13:22] Speaker A: It sure did. Yep, it sure did. And I think it's interesting, at least the ones in my purview are like DHH with rails, Taylor Otwell with Laravel, Matt Mullenweg with WordPress. It's interesting because these are three very, very widely used open source software platforms. All three of them have a single individual at who's leading the ship. And all three of them, and, you know, of course, like, all three of them are like highly opinionated in their own way, but they all have three completely different approaches to leading the way here. You know, we see what's happening with Matt. [00:14:02] Speaker B: Right. [00:14:02] Speaker A: We see that ideological, like, just kind of a mess over there. [00:14:06] Speaker B: DHH is well known. How would you describe Taylor's leadership? [00:14:13] Speaker A: I mean, I'm Larsan. I'm less familiar than people who are really in Laravel. But my observation is, like, he might be the most effective of the three. I think. I think he's probably the most successful and the most effective at what he does in that. By the way, Caleb Porzio, who created Livewire for Laravel, and he just came out with Flux UI for Laravel. He had a really good podcast on his solo podcast where he compared the rails ecosystem to Laravel. That's a really good listen. And he talked about the leaders, DHH and Taylor and their different styles and whether it's like, whether Laravel is a cult or Israel's occult and all this stuff. It's a really good listen. [00:14:57] Speaker B: I don't think it's surprising that they have three individuals at the helm that's not. [00:15:01] Speaker A: Yeah, it's almost, Taylor does really, really well and has done is he really centralized the Laravel ecosystem. Like, brought in, really embraced these businesses, these like products in the laravel ecosystem. If you go to laravel.com, there is a navigation menu and you're being linked to Lara casts. That's an independent product by Jeffrey Way. You're being linked to Livewire. You're being linked to all these different products that are, that people are making livings on. Right. So, so that's very different from WordPress. Right. WordPress, like, since day one, has been really kind of anti like paid products in the ecosystem in a way. Like they, you know, they discourage promoting your products at work camps and things like that. Like, shame it. Like. [00:15:57] Speaker B: Yeah. Wu themes should have been embraced. [00:15:59] Speaker A: It was exactly. [00:16:01] Speaker B: Yeah. Like, very clear situation. [00:16:03] Speaker A: And Laravel and Taylor has taken the opposite approach of like, hey, let's. But we're all a family here. We. You know, we. And it's. And look what we see. We. Laravel has one of the most thriving ecosystems on. On the web. I think Rails is interesting. DHH obviously has a lot of opinions. People love them or hate them. I think a lot of rails developers love building with rails, as do I. That's my preferred platform to build things on. It's not as. It's weird. I guess it's like somewhere in the middle. Like, rails is not as embracing of products or businesses built around rails that aren't 37 signals less centralized. But they are not. But they are not. It's not like WordPress where they sort of push them away or try to deny them access to any way. [00:17:04] Speaker B: Rails feels looser and more laissez faire. More, hey. Like, we are ideologically open source and therefore, like, we just do this and we don't know what happens after that. You can go off and do whatever you want. [00:17:17] Speaker A: That's a worldview. And there's a freedom and openness about that that is refreshing. But at the same time, it does have some, like, if you compare the rails ecosystem to the laravel ecosystem, laravel ecosystem is just much more integrated. And there's like tools for everything that you could possibly want. And with rails, like, there. There are tools for everything, but some of them are sort of like projects that were abandoned a few years ago or, you know, they're. [00:17:45] Speaker B: And I'm like, it's not. Rails is a problem. Like, there's no central, like, oh, trying to curate and identify the best ones. Yeah, it's kind of cool approaches and. [00:17:54] Speaker A: In my view, from where I sit and what I'm doing now with the product, one of the big gaps in the rails ecosystem is components. There are a few well known application templates, like boilerplate templates. Jumpstart is one bullet train. Those are probably the two popular ones. There's not many what people think of as components, especially front end components, but also just in Laravel land. The new hot one is flux ui by Caleb Porzio, the creator of Livewire, which looks incredible, but it's for Livewire and Laravel. There's tailwind UI, but that's really just HTML and tailwind. And there's a lot of other ones, but there are not many in the rails ecosystem. And so what I've done as a designer and builder in rails is I create my own components. Like I take, I design and create my own with like tailwind and stimulus and hotwire and rails. But I have to like, that's a lot of time to create that stuff and most developers don't really have both the front end and the backend skills. So that's the gap that I'm hoping to fill in and that's what I'm building at instrumental dot de v dot because it's something that I want to build as a product and I think that has, it's like leveraging my byproducts. But what I actually see is the opportunity is an ecosystem that's still huge. Rails is still huge, but there are gaps and it's very, it's just fragmented, right? Like it's not as tied together as things are in Laravel. [00:19:52] Speaker B: Is there an analogy with the laravel ecosystem? Is it like a tailwind UI? [00:19:59] Speaker A: Yeah, I would say it's more like flux UI for rails. That's sort of the mental framework. I mean, I'm not saying it's going to be as, as nice or as well done as what Caleb's been able to build. The stuff that he creates is incredible, but that's along the lines of what I'm trying to do for the rails ecosystem. And that's what I already have in my work here is I have a working library of components that I use in all of my projects I'm talking about, and it ranges from front end to back end. So I have a lot of front end components, buttons and forms and dropdowns and application shells and navigations and modals and stuff like that, and the associated tailwind and rails partials and stimulus J's and hot wire stuff. Then I also have components that are more like backend. A couple of the projects that I worked on recently use AI, like hit the OpenAI API. So now I have some, some classes and service objects and things that I do in rails so that I can easily implement AI features in a SaaS app. Same thing with stripe, same thing with a bunch of other functionality that I would put into an app. So the vision for this is to release it probably as a library where you can pick and choose your own components, maybe offering an application template to pull them all together. In. One thing I could talk more about how I think it'll be a little bit different from other components, libraries and things that I've been frustrated with. [00:21:44] Speaker B: But you're underway instrumental dev instrumental dot de v dot. [00:21:48] Speaker A: Right now you can go there. There's an email opt in for early access, and then I have a survey on the back end of that. And if you do build in rails, but even if you're not in rails, if you're a builder, full stack builder, I would love to hear your feedback in the survey on that. You could even just go to instrumental dot de v survey if you want. [00:22:07] Speaker B: To and skip the email. [00:22:09] Speaker A: Yeah, that's fine with me. I'm really just looking for information, and I want to talk about. I caught myself making a mistake. [00:22:19] Speaker B: Okay. Okay. A sign of maturity. [00:22:22] Speaker A: Okay. So I was on the flight going down to Cabo, and I was thinking about this prod. I was working on it on the plane, and I think I talked in the previous episodes about, I've been looking for, like, non SaaS business models to start building, and education was one of them. I've been really interested in, like, these educational platforms courses, not just a single person selling courses, but, like, bringing in teachers and stuff like that. Community is another type of business that I've been interested in, and these components. And my thought a few weeks ago was like, let's combine all three, and instrumental dot de v will be the place for people to learn how to build stuff and ship stuff. It'll be a community to connect with other builders, and it'll be components to help you build. Right. And maybe it'll be for rails. Maybe it'll also be for Laravel. Maybe it'll also be for everything else. And that's just too much. Right. Like, I caught myself with. That's just, it's not only so much to build and ship, but it's also like, that's three different problems. That's three different solutions. That's not a single solution for a single audience. Right? Okay. Education is like people. If you're doing an educational company, you're marketing to people who literally want to learn. They want to go from zero to one, or they want to go from here to their community is like, they just want to connect with people and network, and that's a different problem that you're solving. Right? And components, people are building projects and they need components to use in their projects. So, like, people might come for the components, but they might not care about the courses. And I realized it when I was writing. I always start with a sales page before I build anything. I start with, how am I going to market this? How am I going to sell this? So my starting point has been designing and writing the copy and the design for the sales page. And I was writing it, I was like, it just sucked because it was like, it's too bland, it's too broad, it's not targeted enough. The headlines don't, don't hit because you're. [00:24:47] Speaker B: Trying to sell several different things. [00:24:49] Speaker A: Yeah. Hey, if you have this problem, end this problem, end this problem. And that just doesn't work on a sales page. And so then I was like, let's step back. What am I actually trying to build here? And what am I actually trying to offer? Where do I offer the most value? It's the components. So now I'm rewriting the homepage to be like rails Ui components. You know, it's for rails, it's not for laravel. It's if you build with the stack that I build in, which is rails, tailwind stimulus, hot wire. That's what this is. [00:25:23] Speaker B: Okay, so the exercise of writing, being forced to actually articulate your thoughts, helped you bump into, oh, well, hold on, I'm going too broad. I gotta start more focused. And that's what helps you avoid a classic mistake. [00:25:39] Speaker A: Yeah. And I have a new version of the homepage. It's not live just yet, hopefully today or tomorrow. Because now that the whole thing that I'm writing is I'm selling the problems and the benefits of this Rails UI components library, I can speak to the things that frustrate me about other components libraries. Right. The main one for me is most of these things are selling, hey, we will make it faster for you to build stuff and ship stuff. I think that is a benefit, but I don't think that they actually deliver on that because most of them are like, here's everything in a box, just implement it. And you have an up and running app. But the reality is people are not taking these boilerplate app templates and just turning it on and letting it run. No, what they are doing is they're taking them and they need to customize them, they need to take them and they need to adapt them, and then they need to build on top of them and build features and tweak them and take out the things that they don't want. And that's the play, that's the playbook. When you're using these things and the components libraries and the app templates that give you too much all in one big box end up slowing you down. We started with one at the beginning of zipmessage and it slowed us down because it gave us too much and we had to undo and rip out too much. We're talking about weeks and weeks of extra developer time to adapt it. So my vision for this thing is to give you components that are simple and clean and give you a lot of the structure that's time consuming. But I also want to show you maybe in video tutorials with each component. Here's how it was put together. And if you want to take it apart, it's easy. You could do this, this and this, or you can configure it in this way. But I'm going into it the understanding, like you are a developer, you work in code, so I'm giving you nice clean code that you can work with. [00:27:45] Speaker B: You're selling less the end state and more. [00:27:48] Speaker A: Yeah. [00:27:48] Speaker B: Along with your process. [00:27:50] Speaker A: If people wanted an end state, they would just use a hosted SaaS product. Yes, but we're selling to developers who are, who need to use their hands to build with stuff, you know. [00:27:59] Speaker B: Yeah, we just had this conversation yesterday internally. We were talking about our front end development and our UI. Cause we're doing a big, a lot of work on the onboarding. So these are screens that we just don't have right now. Right now we just dump you into the admin and then we give you a little intercom essential. Just say set up a 15 minutes call to get set up because we didn't want to build onboarding before we knew what we were talking about. And in that conversation I made a comment. I said, I want this thing to come out the way it looks in Figma, right? This is just an annoying non technical CEO basically saying it's so pretty in Figma. Please make sure it comes out that way in the admin because sometimes it doesn't and then you're spending time dealing with it. And then where the conversation ended up going was around what components are we using or what? What are we doing to give ourselves a leg up and not have to do everything custom. And then the conversation starts to get into, well, if we grab stuff off the shelf, then it becomes heavy. We need to customize it anyway. If you want to look like Figma, like you're basically asking opposite things. You're saying you want to go fast, so use a UI library, but you also want to look like Figma. Those are not compatible with one another. So everyone deals with this internally and you have to make a lot of trade offs and you end up building custom stuff, then you end up like customizing things off the shelf. There is no straightforward answer. So what you're doing is you're selling it to people who, you know how they work. [00:29:29] Speaker A: Yeah, I mean, I think that there's a lot of like legwork and groundwork that I can provide that can actually save you time. Like, it saves me time when I'm working in my projects. But there's also like, this is the hard thing about designing and building a product like this because there is a line in the sand where like, I know I could keep going, I could keep designing and keep adding more design elements into this, or I can keep adding more magic that's happening in the backend under the hood to make it, quote unquote, easy to just plug in. But the more of that that I'm adding in, these are more assumptions that where I'm assuming that you are going to want this stuff. So I need to draw a line in the sand to say, like, I'm going to save you a lot of time, but only up to this point. And I'm leaving space for you to take it and run with it, you know, so like not over designing, like not over like, like just having a very clean and almost like not stylized, but just structured design. And then the backend logic. A lot of these component libraries, they try to make them work like magic. Developers don't want the magic. They want to adapt it. They're going to have to adapt it. So that's hard. I'm still at the beginning of productizing it. Like, it works for me, but I'm still figuring out the technical aspects of like how do I make this something that I can release to other developers? And this is literally where I want to get the feedback from other builders to see like which components have you used? Where have you run into frustrations? How can I make this the easiest collection to actually use? [00:31:24] Speaker B: You know, yeah, a bit of customer discovery, but not for the software product more so to just understand how far you should go in doing things for them compared to where do you stop, where does your product stop and allow the developer to take it from there. [00:31:42] Speaker A: It's an interesting product problem because it's not like a SaaS with clarity flow. It's a constant discovery of, okay, you're a coach, what are you trying to do in your business? Let's go build a feature to solve your problem. This is more like giving you tools and raw material to help you go actively build stuff. [00:32:08] Speaker B: Cool. Well, it's great to see you up and running. Looking forward to hearing more what's up on your end. Okay, so I want to talk about a difficult topic that we normally don't talk about. And that is letting people go. But I think it's worth talking about. We let a few team members go this week, and it's always a difficult process, but it made sense to us and I think it's just worth talking about. [00:32:41] Speaker A: Yeah. Why don't we start with what can you share in terms of what were the roles? [00:32:46] Speaker B: And so you have to kind of explain this to yourself and explain it to your team members and explain to the larger team. And I mean, like, the leadership, like, right. This is not a small thing. You're eliminating jobs. So you can't just be like, well, we want to save a few bucks, or we don't think x. It's not, you know, it has to be more than that. And the way I wound up kind of explaining it to myself and to the leadership and then to the team, and this, I was helped in this thinking with a few peers. So I started to get this feeling that we didn't have the right team structure, and I started to go to a few peers that I trust and saying, what do you think about this? You know, I'm real close to the problem, literally, and I just want to get an outside perspective. Am I crazy? Am I not crazy? What do you think? And I got some really, really good feedback. And the way it looked once I had more perspective about it was that we made a big evolution. The company changed. It morphed when we went from the rally checkout in 20 plus people down to nine people and pivoting and building Rosie. So that is an evolution, a big change from one type of company to another. And a lot of things go with that. People go, but also layers go. And management, who people report to and what the process looks like, it changes. [00:34:21] Speaker A: Actually, let me just pause there. So the nine people who continued on Rosie, like, what's the makeup of what are the roles? It's mostly engineering focused. [00:34:32] Speaker B: No, it was pretty evenly split between several engineers. [00:34:36] Speaker A: Okay. [00:34:37] Speaker B: And then some product and then some go to market. And so what ended up kind of forcing itself onto my desk, like, you know, you can't avoid things that are, like, obvious because they have a way of intruding. They have a way of just coming back up. So now, when we, when we made that initial change and we started building Rosie, we didn't really know what type of product Rosie was, what it's like to manage this thing, what it's like to build it, operate it and sell it. You know, you just don't know that much until you're there. Now we're in the market. We have customers, we have revenue, we have signups. We're looking at numbers on the conversion rate. We're trying to figure out, okay, what do we need to do here? And when I looked back over at the team structure, it felt like we had not finished evolving the company. Now that we know what the product is like, we know more of what we need to. The product wasn't there. It's not a surprise that we didn't get it perfectly right. We went from one type of product to another. But it was lingering. The team evolution was lingering behind the product evolution. [00:35:47] Speaker A: Okay, so what was the need that wasn't so. [00:35:52] Speaker B: These are all three people that we let go were good at their job. Right? So it's like the tricky, difficult thing, but we. [00:36:01] Speaker A: That's always the hardest thing, right? [00:36:03] Speaker B: You know, and you still had like. [00:36:05] Speaker A: Nine great people on the team. They were there for a reason. [00:36:09] Speaker B: Yes, that's right. [00:36:10] Speaker A: This isn't the kind of thing where it's like, oh, it was a 30 or 60 day trial and it's just not going to work out. This is more like we had, you. [00:36:17] Speaker B: Know, we had two in the same position, and now we have one because we only need one. And this is the one that's right. So it's kind of different. So let me explain it, because I think people will understand more in detail. Number one, we had a fantastic DevOps engineer. And if anyone needs a DevOps engineer, please let me know. At rally, we had payments, we had vaulting, we had multiple integrations, we had a decent sized engineering team we needed. DevOps was critical. And then all of a sudden, now, a few months into Rosie, we look over and we're like, man, this thing is not nearly as complicated. We're leaning on a bunch of APIs. We're going to lean on even more API. Everything's going to turn into an API. When it comes to LLMs, every service is going to just be an API. And so that's one of these things where, like, I can try to justify keeping them on, because maybe six or twelve months into the future, we might need more DevOps, but right now, that's not what the team wants. Then we had a senior QA engineer, and they were amazing and necessary for rally because you can't make mistakes, you can't have downtime, you can't have a deployment screw things up for 2 hours. It has to be perfect when it comes to payments and checkout. And all of a sudden now we look at Rosie and we're like, you know what? I think the developer should be doing more QA, and we just don't need the same thing. We'll probably need some manual testing and that sort of thing, but not a bunch of automation, engineering, and then a product manager. We don't need two product managers for this. In many ways, the product management was. [00:37:49] Speaker A: The hardest thing because you're starting to describe the shape of my team with clarity flow. You have a few more people, of course, but, like. [00:37:57] Speaker B: But it's atomic, right? [00:38:00] Speaker A: Well, yeah, and I think you're starting to describe the shape of my team and probably the majority of, like, bootstrapped SaaS product teams. [00:38:08] Speaker B: Yes, I think that's a good way. [00:38:10] Speaker A: To put it, you know, because, like, yeah, there's always a somebody in charge of product, and sometimes it's a founder. Sometimes it's like a lead or head of product or something like that. There's a lead engineer, right, or a CTO, and then maybe one or two people, three people working with them, and these are full stack people. And full stack engineers can do a lot of stuff. They know how to configure a server, at least the basics. [00:38:43] Speaker B: They know how to get things on the Internet and keep them up there. [00:38:45] Speaker A: And when we're talking about a bootstrapped SaaS startup, we're not talking about the scaling phase. We're not talking about solving problems to serve thousands and thousands and thousands of requests. We're not at that level, so we don't need those people. [00:38:59] Speaker B: Yeah. So it's like we evolved back into the atomic unit of a bootstrap sass, maybe a little more luxurious than that because, you know, because we can and we want to do things a certain way, but we've shrunken down, and now it feels like, okay, now the company structure caught up with where we actually should be right now based on this product and this time. And so it was like, on the. [00:39:23] Speaker A: DevOps thing, I was saying just before, like, in the history of zipmessage and clarity flow, we only brought on a DevOps specialist in, as I remember, only one case. And it was like a one or two month project when we were migrating from Heroku to, like, get things set up over to AWS to get our. It was a big migration. It was pretty technical. We had to set up a lot of stuff, a lot of different services and infrastructure, but it was a project, and they finished up. And now my engineers, my backend team can still operate our systems. [00:39:58] Speaker B: Yes. [00:39:59] Speaker A: Yes. They have people that we can go to when we need more complexity. [00:40:03] Speaker B: That's right. That's always out there. So it was a tough week on that front, but I feel comfortable in the decisions that went into it because they weren't taken lightly, and they make sense. And now we kind of can sit back and grow only when it hurts, where it hurts. And it's like we're being very efficient. We're giving ourselves as much Runway as possible. We are not hurting the company because of it. And very interestingly, and this is probably stuff we'll talk about next week, we are finding that we are able to buy customers advertising in this realm works, and what that tells me is we can optimize that over time to understand, here's how much we can spend. Here's what we need to convert from that spend in terms of trials, in terms of activation, in terms of conversion. And it's more of a. It's more of a machine than a mystery. [00:41:05] Speaker A: Yeah. [00:41:05] Speaker B: When we spend $400 a day, many sign ups, we spend $800 a day, we get this many signups. [00:41:11] Speaker A: Mm hmm. Yep. What else on the team there? So, like. [00:41:17] Speaker B: So right now, I'll describe it. Six people. [00:41:20] Speaker A: Yeah. [00:41:21] Speaker B: Right. Myself, mostly marketing, strategy, product, that kind of thing. Sam. On the go to market. So, you know, talking to customers, customer success. Yep. Sales, everything. Then we have rock CTO, along with a front end engineer and a back end engineer. So we don't go full stack. We have two specialties. [00:41:42] Speaker A: Yeah, but that sounds like a solid crew right there. [00:41:45] Speaker B: Right where it's like. Right. And rock does a lot of, like, what I would call, like, strategic engineering or, like, we need amplitude. We need to get this analytics set up to understand where people are dropping off. Like, that's engineering work that rock would do. And he also does exploratory engineering. Like, let me go figure out what an integration looks like before engineers go in and start building integrations. [00:42:08] Speaker A: Yeah. And I do the same thing as well. So I have one full time back end rails developer, and she just knocks out the roadmap that I give her, and it's just so I do all the scoping and design and architecture and just give her, like, we're building a big forums feature now. She's hacking away on that for the next few weeks. [00:42:28] Speaker B: Cool. [00:42:29] Speaker A: But we're also doing research. So I have another more senior engineer, and I only bring this person in occasionally as needed when we need to do this, like, technical research for future planning of a very complex thing, you know? [00:42:45] Speaker B: Yeah. Rock and I love that aspect of his job because it'll almost it'll often start with my thinking and ideas, and it'll translate over. An example would be rock. We need to get our costs of the AI services. We need to get it down by 50% in the next three months. Like, just have that in mind. Look around. That's what needs to be on your desk in some form. [00:43:13] Speaker A: Yeah, and we literally had that project on that senior person's plate about eight months ago. Like, she spent two months. Like, how can we shave a couple hundred dollars off of our aws bill? [00:43:26] Speaker B: Right? Like, look into it. [00:43:27] Speaker A: You do different configurations, different services, different optimizations, and. [00:43:31] Speaker B: Yeah, and then, and then number six on the team is Jessica. And this, I think, is one of the most interesting aspects of this change in company structure, because Jessica's vp of product. But my directive, like, my here's like, my marching orders, for lack of a better term, is less product, more growth. And I mean growth as, like, an area discipline. So let's make the product management process as light as possible. Let's just get on meetings. Let's have a conversation, let's write some requirements, and, like, no big, crazy process. We didn't like this scenario where developers almost ended up in a position where they were asking permission from product. Like, I want the developers to feel more free. Okay. So it's like, Jess, we need less product process and a lot more emphasis on growth. Viral loops, sharing loops. What, what's the conversion rate of each individual screen in the signup flow? What do we need to do to improve that? How do we get activation faster? Like, all these things that are focused on the usage of the product, the sharing of the product, the adoption of the product much. [00:44:43] Speaker A: Got it. I like that. So it's like shifting the focus of that product manager role less from it shouldn't really be project management. It shouldn't be like, what are we delivering by Friday? And then what are we planning for next week? It's more about what's working and what's not in the activation flow, the funnels. [00:45:04] Speaker B: Which experiment is next. It's almost like we should demand that we get the benefit of, of being six people. Don't just shrink down to six people and say, oh, now we're missing all these people get the benefit, which is of being smaller, tighter. Like, one of the first thing that came to mind was like, we should get together. Like, we should get together meals. We should have some fun and get the cohesion and the value, the benefit from being a small team. [00:45:31] Speaker A: I like it. [00:45:32] Speaker B: Yeah. So it's kind of fun. It's another new phase inside of all these changes over the last year. [00:45:38] Speaker A: Yeah, man. Exciting, dude. I like this whole transition. I've liked it since you went to Rosie, and then, yeah, it's multiple iterations, and you're dealing with a new reality, and you got to keep rolling with it. [00:45:54] Speaker B: Yeah, yeah. [00:45:55] Speaker A: I think that it's like that age old thing. It's like, what got us here won't get us there. And that can work in different directions. That's not just about scaling up. That's about transforming. [00:46:06] Speaker B: Yeah. [00:46:07] Speaker A: Yes, yes. [00:46:08] Speaker B: And, yeah. You know, the. The challenge of it, I assume, just like myself, other people have the same thing. There are emotional barriers to get through. There are habits to change. It's like, you. And what's going on inside of you as a leader is like, that's the limiting factor. And all this stuff. How willing are you to admit mistakes and cause other people pain? Like, all these things are, like, psychological and emotional. But that makes the difference between either never doing it, taking too long to do it, doing it on time, doing it too early, doing it too late, and so on. So hopefully, I got most of it right. [00:46:50] Speaker A: It does remind me of something that I'm going through right now also. I feel like I am passing through some sort of transformation in my work and my team, my consulting work, which is one month app, that's still how I position it. I'm building MVP products for clients, and that's been going well. And it started to really pick up in the last couple of weeks. Today, I'm just finishing up one of those for a client. I have another one that is starting on Monday, and then I have probably two or three more that are very close to being booked for October, November, and December. Right. So these projects are starting to pile on a little bit. And when I was in Cabo, I was thinking through, because that was like a week off to step back and say, like, how are things going here? Right. And I was sort of on the fence between. All right, so the problem or the pain point that I'm starting to feel in a very real way every week is I want to be building product. So I'm always going to be spending roughly 20% of my time on clarity flow with my team there. But then it's a high priority for me to be spending some portion of my time working on a new asset, a new product. I talked about instrumental dot de v dot. That's what that is. But I struggle now to find the time to put into that. Currently between the consulting projects and my clarity, flow, obligations. I really can only give it about one good full day, if you can even call it a full day of active effort, of moving the ball forward on this new product. And one day a week is not enough. I can't really do much. [00:48:52] Speaker B: 20% of your time, Colin. [00:48:54] Speaker A: It's even less than that probably. I can't really push the ball forward with this new product with only one day a week. So I need to figure out how can I make the consulting, how can I reduce that down from three to four ish days a week down to like maybe one day a week or, you know, yeah, like make that another 20% and make the rest working on the new product. Because I was also debating like maybe I just wind down the consulting altogether and I could swing that. You know, like I have some Runway that could last me a bunch of months. So I could cut it out and try to go hard on this new product. But I don't like that option. I've done that before. I've gone all in on products before they're profitable and I don't like it. [00:49:52] Speaker B: Yep. [00:49:53] Speaker A: And I don't like the idea of just like cutting off the pipeline right at the moment where the pipeline is starting to heat up. [00:50:03] Speaker B: That's right. So what are you doing? [00:50:05] Speaker A: Because I'm also starting to feel the natural wave of demand and word of mouth spread. And past clients are coming back to book more projects now. So between the past clients coming back and new clients coming in through word of mouth or new network effects, it's steady. And I don't want to cut that off. So the other option of course, is to hire a developer. I have my team that I work with and I've already talked to them about bringing on another, maybe two additional developers to work with me just on my consulting projects. That's what I'm going to be doing is I'm continuing to build out. I'm going to continue to take in new consulting projects and book them out. But this is the transition that's going to be hard, is figuring out how can I run these projects and still own them and direct them and put my design and architecture and direction and project management on them. I do that really well. In general, we have a really solid flow with clarity flow. But then multiplying that by a second, a third, maybe even a fourth project happening simultaneously, that's still taking a lot of my time to manage it all. This is going to be like a painful transition period where it goes from like me 100% solo, which is what it is now to me, plus one or two developers working directly under my direction. But I think soon after that, the next level is, like, bring in another manager or someone like me who can totally own projects without me. [00:51:52] Speaker B: In many ways, it's an asset waiting to be turned into an asset. [00:51:57] Speaker A: Yeah, it's like, you know, it's like, sort of like the agent, the evolution of an early agency. I'm not, but I'm really not trying to make it a large agency. [00:52:06] Speaker B: Yeah, that's fine. [00:52:07] Speaker A: I'm trying to keep it small, but small doesn't have to be just me, you know? That's right. [00:52:13] Speaker B: That's right. [00:52:14] Speaker A: But I'm also trying to not have a situation where, like, we are unable to take in new projects. I'm not saying no to projects. [00:52:22] Speaker B: Right. [00:52:22] Speaker A: The whole goal here is to be able to take in the demand, execute it at a high level, like we always do, without sacrificing quality. But. But have that consistent cash flow business happening, you know? [00:52:35] Speaker B: It's a hell of a challenge. It is the classic challenge, and, I. [00:52:39] Speaker A: Mean, I've done it before. That's right. It's hard, but this is also the type of business that I would still like to be run. You're right. It is another asset. I'm happy to be building software. That's what I do. And we're leveraging byproduct. We're taking these byproducts, turning them into components for the library. There's case studies. I still have my own SaaS ideas that I could, during periods where we slow down, if I have an extra developer or my extra time, can go into other product where we're showing off the components. Library, like, you know. Yeah. It's a mix of different things, all building software related. But I need to figure out how to make it like a smooth, smooth on the financial front and smooth on the stress level front without overheating on any of those meters. [00:53:35] Speaker B: Yeah, that's the trip. You're juggling a lot. [00:53:39] Speaker A: Yeah, always. [00:53:40] Speaker B: Cool. All right, my brother. That's a good episode. It's Friday. It's Shabbat. Tomorrow's Yom Kippur. [00:53:46] Speaker A: Yes. My league championship series. I'm pretty sad about that. [00:53:51] Speaker B: Sort your tweet about. About the Mets. I mean, things happen. [00:53:54] Speaker A: Hell, yeah. [00:53:57] Speaker B: All right, brother. [00:53:57] Speaker A: Have a great later, folks.