Episode Transcript
Speaker 0 00:08 Welcome to the rogue startups podcast. We're two startup founders are sharing lessons learned and pitfalls to avoid in their online businesses. And now here's Dave and Craig. All right, welcome back
Speaker 1 00:20 to another episode of rogue startups. Dave is off this week. Um, but I guess first happy new years to everybody. Uh, hope everyone had a good restful, uh, time over the holidays and are ready to get back at it here in the new year or this week. I'm joined by a good friend Benedikt Dicha of user list. Benedict has to go in.
Speaker 2 00:38 Hey, nice to be here. Yeah, everything all right over here.
Speaker 1 00:42 Great. Great. Yeah, so I know it's a, it's an interesting time right after the new year. I know we all go into the end of like end of the year and thinking about what we did last year in the beginning of the year, think about all the great stuff where to do this year. And so yeah, I guess I thought, you know, for folks who kind of don't know you or what you're up to, you want to give a bit of kind of background on who you are and what you do.
Speaker 2 01:03 Yeah. So as I said, my name's Benedict. Um, I'm a software developer by trade. I studied in the university and stuff like that. I've been, uh, doing a lot of consulting work, mainly helping software founders, building their products. But now it's like two years ago I co founded a new product, a user list user list.com, uh, together with, uh, Jane Portman and Claire Southern shop. And we basically do lifecycle messaging slash email for SAS products. And we've been doing this for quite a while now. And 2019 was a big milestone for us because we finally finished a product, air quotes, uh, and, and launched it. So, uh, this was definitely the highlight of my, my 2019.
Speaker 1 01:53 Yeah. Nice. Well that's, that's good to be able to point back at like a thing that kinda made 2019 for you. We were talking about this with our family and our kids. About like, Hey, what is, what do you think about when you think about last year? And our kids of course that like silly, Oh, I got this toy for Christmas kind of things. And for me I was like, I dunno. Like there was so much shit that happened. I don't even know like where to point. So that's great. Did you have a thing that's super,
Speaker 2 02:17 so there's no, just, there's not just one thing that stands out for you?
Speaker 1 02:22 No, I mean we, there was a lot of stuff that happened, right? But I mean, I, I guess like for us, like with Castillo's, which is like my big priority right now, like joining tiny seed was a really big deal and, you know, taking someone else's money and being accountable to them changed just a lot of how I work and how I think about work. Uh, so I think that that really frames a lot of my life and my work life specifically. But that's, I dunno if that's an accomplish, I guess it's an accomplishment. I don't know. That's a weird way to think about it.
Speaker 2 02:49 Yeah. I, I think that counts as an accomplishment. I mean, yeah, it's not like everyone, everyone gets in there and, uh, it's kinda stamp of approval a little bit, so,
Speaker 1 03:00 yeah. Yeah, I think so. I think so. Yeah. And honestly, I mean, and this is kind of something that the episode that we're going to talk about today is going to be kind of like, I think we'll call it something like a doing it better the second time around. So Benedict and I are just going to kind of chat through things we've learned through you, you know, building products for our customers and now building products for yourself and under this is like the second SAS product you've built for kind of yourself and for me kind of now looking back to when a half years into Castillo's like what I've learned and what I maybe wish I would have done different. And next time I go do this. If I do it again, well what I'll do differently because yeah, I mean we learned a lot and I think the nice part is a lot of it is fixable even as you go.
Speaker 1 03:42 But um, one of the things that, one of the things that we've learned recently is like we spend a nontrivial amount of time redoing stuff now and, and that really chaps my ass, cause I say like maybe it's my fault, you know, that like I pushed too hard and that we, we did this, you know, not in a perfect way the first time, but then having to go back and redo the whole thing is, is kind of painful. So I don't know. Do you find that, do you find like you build an initial version of something but then you have to go back and six months to to refactor it or update and or something like that?
Speaker 2 04:18 Yeah, it happens and I'm usually quite worried about that upfront. Like whenever I build a new thing, I sometimes get really stuck with, I'm like weighing all the options and possible solutions and trying to find the best one. So I feel like nowadays I'm almost on the opposite spectrum of that. Um, just like worrying too much and getting stuck in not shipping stuff because of that. So I sometimes have to remind myself that just getting something out there is more valuable than finding the perfect solution.
Speaker 1 04:52 Yeah. How has that dynamic between you and Jake's? I know Jane's a designer, so you're very fortunate, you get like a beautiful mock-up to build every time. It's very fortunate, but how has that dynamic of like shipping and speed versus quality, uh, for you guys?
Speaker 2 05:09 Um, so I think Jane is always a lot faster with the designs than I am with the extra code. Um, sometimes a little bit just different, but that's usually because I've been planning to implement certain stuff over a longer period and I can just ship it quickly because of the groundwork that's already in place. But, um, yeah, I think you mentioned this on previous episodes as well. Product development is always kind of the bottleneck, at least a few is that way. And I constantly feel like I'm the bottleneck and way too slow with development.
Speaker 1 05:44 Yeah. I mean you mentioned that the product was done last year, right. But like it's never, it's never done right. And I think you can when you feel like the product is done and we like the product is done too, but we still have two full time developers working on it all the time. How do you feel about like how do you guys balance um, like bug fixes and feature development? Cause I think that's a, that's an interesting thing that we all struggle with.
Speaker 2 06:11 So depending on like how serious the issue is, parks usually come first when it's like a deal breaker for, for a customer, like something breaks for them, stuff like that. And that usually stops feature development and we go back into fixing it. If it's something that's like just a tiny issue in a sense that it's not really a problem but maybe not super nice like a small UI issue or something like that. Then that usually sits in the back tracker for a while and then when I have time I usually go in there and just fix a bunch of stuff in in one session. All those small little things that just like improve the overall quality of the product, but yeah, as I said, like major features always get priority. Major issues always get priority.
Speaker 1 07:01 Yeah. Yeah. We, we, we tend to work the same way and I think it's a matter of like what's a major issue for us, it's like billing is always a big one. No, someone's ability to publish a podcast episode or to get analytics and for you guys to to be able to send an email or tag somebody properly, everything else. Basically all the UI stuff gets pushed and back. We typically fix those all like once a month is kind of how we're working. We're going to be doing the base camp, a shape up, kind of a cycles here. Going into 2020 so we're going to have six week kind of on cycles where we just say what can we fit into these six week, the six week period, and then take two weeks for kind of cleanup. And that'll be mostly bug fixes and refactor I think.
Speaker 2 07:44 Yeah, I think that's a good approach. Uh, overall just like have some, has some dedicated time to actually go back in there and fix stuff or improve small things from time to time because otherwise if you're just always focusing on new features, stuff gets left behind and usually bites you a year after or something like that.
Speaker 1 08:04 Yup. Yeah, we definitely swung way too far that way. Uh, maybe at the beginning of last year and there was just some ugly, bad stuff that we worked around for too long, but cool. So I think we both have a list of like solid tactical things that we have learned that we're hopefully doing better this time. Or maybe we just learned that we would do better next time. And I think this would be a cool episode for folks who are, well, anybody for somebody who's just getting started in SAS or that is uh, you know, starting something new or whatever. Do you bend it or do you want to go first with something that you kind of have learned that you're hoping to do better?
Speaker 2 08:36 Yeah, of course. Um, I have to put an odd, a small disclaimer with all of this. Um, for one Lake, this is the first time I actually have co-founders, which changes a lot of things just like by the nature of having someone else work on this with me versus like building my own product or being higher, cheaper at something. And the other one is, um, I never made it this far with any other project. So, um, useless definitely is, uh, the most successful product I've built so far that at least for myself. Yeah. So that also, I mean now I'm doing stuff that wasn't even an option back back, uh, with other projects because I don't have a need for it or it was that from the start. So
Speaker 1 09:22 that's cool. No, that's great. I mean, so that's, that's really, uh, like advanced learning then. That's super. Yeah.
Speaker 2 09:27 Yeah. And like, I think one of the first things I'm quite happy about, uh, is like actually having co-founders, like making that decision to team up with someone was definitely an improvement to trying to do it alone or with my first product, which was, um, a content management system for, um, musicians and band websites. So I was working with that project alone. And now with having both Claire and Jane on the team, it's just so great that there's always some progress even if I'm not actively working on it because I don't know where can a consulting project or something like that, just having a team there that pushes things forward when you're not working on it as a great, great thing.
Speaker 1 10:14 That's cool. That's cool. Yeah. So I've never had a cofounder. Um, it would be a big deal for me, like personally might, I don't know if my personality is conducive to to that, but like everything you read is that it's better. Right. And places like Y Combinator and even tiny seed really want to have cofounder groups. And for their companies because they're just more productive by, by more than, you know, you're more than two times productive if you have a cofounder, I think as a team. So, yeah.
Speaker 2 10:44 Yeah. I, I don't, I'm not exactly sure if it has to be a California, like I think just having a team is a big thing, but like early on having a cofounder, it's usually the only way you can afford having a team, I guess. Yeah, yeah,
Speaker 1 10:58 yeah. I'll, I, I'll put my spin on that. Like I know that we as a company and an the product is much more solid now that we're a team of five people than when it was just me and Jonathan. Uh, and he was hacking away at stuff and I was doing marketing and support and trying to figure out how all the pieces fit together. Yeah. And if I had to do over again, either I would get a cofounder or if I had, you know, a couple hundred thousand dollars that I could go hire two or three people for the first, you know, year and a half or two years until till we got to way the company could support them. I would definitely do that. I wouldn't, I wouldn't just do it alone. Um, yeah, I'm not a developer so I can't, but yeah, I would definitely hire some people right from the beginning.
Speaker 1 11:40 Yeah. You're, the first thing on my list is, is really technical. Uh, but um, as a non technical person, like I learned these things cause I don't know any better. I guess to begin with is we had, we had no real sense of like testing or staging environment or anything like that for a while. At this point we have a lot of both. Um, then everything is automated. Everything is, is really buttoned up and we're all much more confident in what we're building now. So I'm happy to ship stuff if it's kind of mildly human tested because I know we have unit tests. I know we have a staging environment that the developers have gone around and punched all the buttons and stuff like that. And so like suddenly like deploying something to production on Friday doesn't scare the shit out of me anymore because we have some kind of hard data around this.
Speaker 1 12:28 And I would say like I always heard, especially the rails guys saying all everything has to be unit tested. And I said, Oh, you're full of shit, just ship something and we'll figure out the bugs later. But yeah, I mean if I was starting something new today, I would, I don't know if I would have a hundred percent unit test, but something like 70% on like the critical path stuff. And I know it would take longer to get started, but we see now that our speed of development is much faster because we're not worried about breaking stuff. That's a big one. That's just a like delayed gratification kind of thing.
Speaker 2 13:04 Yeah. And I go even further, like, um, I'm a race developers, so I've been on the testing train for quite awhile. But with user list, I tend to write even more tests than before because from past experience you always forget that one part and uh, at some point it breaks and production and makes your life miserable. So these days when I work on the new feature, I really, really try hard to cover all the edge cases so that I can think of. Yeah. Because as you said, like it makes things so much easier and yeah, just having the confidence to deploy on a Friday, Friday afternoon and be somewhat sure that the system, this is a good thing. Yeah.
Speaker 1 13:49 Yeah. And for the, for the non technical founders out there, what I would say is like, and I always kind of fight back this urge of myself to say, let's just ship it, let's build it and ship it as fast as we can. The unit tests is like an investment upfront to be able to do that later on. So it's going to take 30% longer or a hundred percent longer upfront, but then every new feature is twice as fast or something later on. Right.
Speaker 2 14:14 Yeah. And I think in the end I think it just speeds up the feedback loop about like the quality of your code and maybe even undiscovered issues. Yeah. Cause it's like more often than not I sit down and write a feature, add some tests for it and then why writing the test site is covered at, Hey may I call it actually is wrong and it's not doing the correct thing. And I'm noticed that the very moment I write a test and not like the week later when a customer complains about this weird behavior.
Speaker 1 14:43 Right. Uh, so do you want to go with uh, something else from your list?
Speaker 2 14:46 Yeah, so, um, one thing that ties a little bit into having testing for me is I'm keeping the dependencies of the application. Like all the libraries you use UpToDate. And these days I use a service for that called <inaudible>. And they basically, whenever there is an update of a library, they update it and then run the tests. And if everything goes well they just create a pull request and get up. And I can just upgrade that dependency with one click and compare to previously where I'd basically ignore dependency updates for couple months and then sit down and try to figure out like how to upgrade everything to the latest versions to get security fixes and new features and stuff. I basically do this in smaller increments almost every week. And that helped a lot to keep like the system well for one stable and upgraded and secure. And that's a, that's a big one for me because like now it's like less of a pain than it was before.
Speaker 1 15:52 Yeah, yeah. Yeah. So, so it's funny, we've, we learned this lesson very much the hard way. We were kind of two versions of Laravel behind at one point. Um, and yeah, it took a couple of weeks to upgrade everything because yeah, we have integrations and all this, it dependencies, all this kind of stuff. And now, um, now we try to, whenever new release comes out we wait, you know, a month or two and then we upgrade to it. We want to make sure it's stable to have another kind of sub point release. But yeah, once something comes out, we, we have it planned for maybe the next step cycle to, to take a look at it and we end up updating a couple times a year at this point. So PHP and Laravel versions a couple times a year. Uh, I don't know about like all of our smaller packages and stuff like that. I don't know how often the guys update that stuff, but yeah, I mean cause you hear stories about people running versions of rails or whatever that are five years old and it's literally like rewriting the whole application to, to update at that point. Whereas you could have just taken whatever a couple of weeks, three times a year. Uh, and yeah, safe and fast and secure and all that stuff. Yeah.
Speaker 2 17:05 Yeah. And I think they like upgrading gets harder the longer you wait because with small upgrades you can have a limited scope or a limited set of changes you have to make. And it's pretty clear usually because there's a change log and they outline a breaking changes and stuff like that. So small version jumps or like incremental version jumps are much easier than trying to, I don't know, upgrade a two year old system to the most recent versions because then there's so many things that change that you have a hard time figuring out untangling what you actually have to do.
Speaker 1 17:41 Yup, yup, yup. Um, yeah. We'll include a link to that service you mentioned. I might have to recommend it to, to our guys. Is that a rails only thing or is that, is that everybody?
Speaker 2 17:51 I think that food as a race or, or Ruby and JavaScript. I think there are other services out there. I think it was dependent part or something that got acquired by GitHub, so they might do PHP as well. I'm not entirely sure. I had to look
Speaker 1 18:09 cool. Yeah, I'll check it out. Okay. Yeah. Then the next thing like on my end was, uh, we started, uh, so I read the traction book, which is all about kind of like how to not be marketing book, but the kind of how to run your business book. A couple of G's a year ago at this point. I guess that I've been preaching about it on the podcast here, but what the, the one big thing we took away was we have regular weekly meetings. So we have a meeting nine o'clock Eastern time every Monday and there are about an hour long usually. And it's just amazing how helpful it is to get everybody on the same page with all the stuff that's going on. So, you know, marketing knows about a product release that's coming out and support knows about a bug fix that's getting patched. And I talk about, you know, higher level strategic things and I just, I can tell everybody is happy knowing what everyone else is doing.
Speaker 1 19:00 Everybody feels kind of more cohesive with like that we're all on the same page and we're all going in the same direction. Um, I talked to several people at MicroComp Europe about this, one of whom was Kevin McArdle from Shure Swift, who, you know, runs a very, very large business that has several kind of smaller components. And he said they, they got big on the, on the traction and the EOS, the entrepreneurial operating system, uh, kind of bandwagon earlier last year in 2019 and he said it's amazing how kind of transformative it was for, for their productivity and efficiency. So yeah, I think if you haven't read the book, read the book at the very minimum, just schedule a weekly meeting where people just talk about what they're doing. It does not, it doesn't have to be like a standup, but just to get people on the same page. It's super, super helpful. Yeah.
Speaker 2 19:49 Yeah. And I think that's definitely true for remote teams where you, where there's no water cooler where you can pick up on those things by accident I guess. So you have to kind of force it by just having a call. Yeah, yeah, yeah, yeah. We do that as well. Um, and one thing we also started doing I think a year ago or so is like, we start to call with a fun fact question. So we have a list of like just random, we had questions, what's your favorite animal, what's your favorite food? Stuff like that. And usually start to call with that to just also get to know each other a little bit better.
Speaker 1 20:25 Yeah. That's cool. That's cool. You and Jane know each other pretty well, right?
Speaker 2 20:30 Yeah, kind of. I mean, we haven't met that many times. Maybe five times a sauce. So, and yeah, we work a lot together, but like outside of work, we don't really know each other that much. So that question or that fun fact that the beginning of each helps a little bit with that. She just like sometimes interesting stuff, uh, occurs and someone has a fun story to share and then can basically talk about stuff that usually gets not talked about in a business context. And that helps with that. Just getting to know each other a little bit better.
Speaker 1 21:05 Yeah, no, that's cool. We do, we did that on Slack every Friday morning. We just have a fun, fun Friday question and I call it a, and I found out that one of our guys is a classically trained bakery chef. Nice. I was like, Oh, okay, we're getting an Airbnb at our next meeting and you're cooking.
Speaker 2 21:23 Yeah. I think, see this is, this is exactly why I liked us because you learn things that you never had imagined about your, your team and your co foreigners. Um, one more technical thing and then I think I'm done with technical technical things on my side. I'm usually birding monoliths, like just like having all the code in one application and not breaking it out into like microservices and stuff like that. But, uh, what I learned over the years is that usually it makes sense to at least prepare to break things apart. So these days I'm still writing like modelists that just do everything, but I already put some breaking points in there. So if the need arises, I can break the application up into smaller parts. And usually that happens because like one part needs more performance than the other part and I need to scale it on multiple servers or stuff like that. But from experience trying to boot separate application, they separate microservices from the star. The zone is a bad idea and just makes your life harder than it has to be in, especially in the beginning.
Speaker 1 22:38 So you, you kinda come at a, like a monolithic approach and then break it up later. Is that what you guys are doing?
Speaker 2 22:45 Yes. So here's the list. At this point it's still a monolith. Um, but I know that some parts are likely to be um, performance critical. Like for example, our endpoint that receives data from all our customers to basically get to process it into our system. That part gets a lot of traffic and at some point we probably have to break it away into its own tiny little application that just does that processing part. So it's already prepared for that. Like it has its own sub domain and the code is also kind of isolated from everything else. But for now, it's just run runs as part of the main application, but in theory it wouldn't take a lot of time to break it out into its own microservice.
Speaker 1 23:35 Mm, cool. Yeah, I like that. I like that we have a, we have a similar thing that we'll do sometime this year, which is to break our analytics processing and data out their own application and database because it's part of the main application now and it's just enormous. I mean hundreds of times the size of the rest of the database and it's just like, okay, this is, this is silly. Um, so yeah, I hear ya. You know, from a, like from a marketing perspective, the one thing that we are just gonna have been chatting about it on the podcast here too much. I know everyone's rolling their eyes is like tracking and in attribution. You know, I feel like we've done a decent amount of that. Um, when Denise came on board with us, she really brought a lot of, kind of a lot more savviness to tell.
Speaker 1 24:17 We do tracking, uh, and data reporting and stuff like that. And it's cool because now like it's much easier for us to get a good sense of like what's working well, what's a problem, where people are coming from, all that kind of stuff. And it's not super hard to set up. Most of it's like Google analytics now we have amplitude and we're managing all of it with Google tag manager. Um, so that's the other thing is I was asking our developers to hate go insert this JavaScript snippet on every page before. And so it's just like, Oh it's so silly. Either use segment, right or use Google tag manager to be able to manage all of your data connections. Um, yeah, it's something that I wish I had done from the beginning cause then I could have done all this stuff by myself instead of having to bug the developers to insert this one line of code and then do a whole new deployment. So it's a, it's much nicer now.
Speaker 2 25:05 Yeah, that's also a good point and I think we are not doing a super great job with that. Like we have been, I think, I think we add Google analytics on the website basically forever. But that's about it. And that I don't think we do a good job of like attribution and proper tracking. Like what channels work best for in terms of signups. I guess that's something we have to work on.
Speaker 1 25:28 Yeah, I think it only, I mean it's, it's really important once you, I think once you have product market fit because then all you not all the most important thing is just getting more users. Right. And so like if that's your biggest focus then then having all that stuff and being able to double down on the thing that's working becomes much more important at the beginning. You're trying to figure out so much stuff that that's not the biggest problem, you know?
Speaker 2 25:52 Mm. Yeah. Yeah, that's true. One other part for me that I'm doing differently compared to previous projects is like trying to build more in public. Um, just be more open about what we're working on, what struggles we have. And I think it works particularly well for this product because like people interested in like following along are also kind of in our target audience for like potential customers. But even if that wasn't the case, I think just talking about it is a good way to also sometimes get outside feedback and get new ideas and yeah, just have more fun in the process.
Speaker 1 26:32 Yeah. Has, has your podcast been a big part of that?
Speaker 2 26:35 Um, the podcast is definitely also a part of that, but even before the podcast I try to be more open about, I'm working on, on Twitter and sometimes I'm just sharing thoughts or code samples or stuff I'm working on and not just like trying to build it and then ship it and then, yeah, basically tell, tell people after the fact. Um, I think like just allowing people to follow along also helps a little bit <inaudible> with the marketing, but I don't have hard numbers on that.
Speaker 1 27:08 No, I agree. And I think you nailed it. I think especially the fact that people who kind of know and follow you or to your potential customers that that's really helpful. Like one of the, a couple of the tiny seed customer, uh, uh, companies are not in that respect at all. One is like, uh, legal tech and the other is like daycare. Um, they care center management and I'm like, you know, none of those people follow any of us on Twitter, none of those customers. Um, so that doesn't work. But I think you guys are in a, in a cool opportunity. I think we, we probably are too where we have customers who are our customers cause they know me and that's cool. Yeah. So yeah. Do you want to give a shameless plug for your, for your podcasts while we're, while we're at it? Absolutely.
Speaker 2 27:50 The, uh, the podcast is called slow and steady. It's together with my friend Brian Ray and we do it weekly, um, basically talking about what happened in the, in the last week or so. Um, I guess it's similar to, to, to this podcast in a way. And um, yeah, it's at slow, slow and steady. podcasts.com or in all the usual podcast players, channels, stores, whatever.
Speaker 1 28:18 Yeah, it's a great show. I listened to it. It's, it's great to be able to, I love these shows that people are able to kind of follow along with what we're all doing every week or whenever. Uh, you guys publish to see kind of what's going on. I love it. Yeah.
Speaker 2 28:30 Um, I think the most supports ones we covered. The other ones are mostly related to the fact that now we have like we have a California situation, so one thing we are doing differently is like we have a lawyer, we have legal paperwork we probably incorporate as a company. That's all stuff that I didn't do when I was like just on my own because it wasn't really necessary. But now, now that we have like three people working on this, it's really helpful and good that we have a shed agreement where we talked about various situations and like what if someone wants to leave and what if someone gets hit by a bus and stuff like that already figured out before. And I'm really glad that we have this in place.
Speaker 1 29:21 Yeah. I heard Jane talking on startups for the rest of us about this. Where do you know that was already kind of agreed upon ahead of time and Claire wanted to kind of change her role within the company. And so it wasn't any drama or anything cause you guys had already decided that I had to times when everyone had cool heads and it wasn't traumatic or anything. Yeah, that's kudos to you guys. I mean we're a, I'm a, I'm a single person LLC I guess. So there's none of that. But yeah, I think anyone who has co-founders especially should have the, who has equity, who has kind of decision making rights and what happens when somebody wants to leave. Um, because that is 100% guarantee to be dramatic. Even if you have it all figured out ahead. It's, I'm sure it was still kinda touchy. Right. But the fact you guys had that figured out at a time is cut down on that stress a lot. I'm sure.
Speaker 2 30:08 Yeah. It just aligns everyone with the EC we what to expect and how things are probably going to play out. So, yeah, just like having, and I think it doesn't have to be like a full, fully legal legal compliance lawyer checked document, but like just, just some notes that get everyone on the same page.
Speaker 1 30:30 Yeah. Yeah. Um, I have, I have two things that we did very poorly that we, we still are doing one of them poorly and we changed one already. The one we changed was the name of the product and I know you guys went through a, you didn't change the name but you change your domain. I'm sure that was like mildly painful. But you know, we started out, <inaudible> was originally called seriously simple hosting because of the plugin was called seriousness of, well podcasting still is called series civil podcasting. And so we didn't have a good name for the hosting aspect and so we just called it seriously simple hosting, which is a terrible name. And so we had to like rebrand everything, you know, um, and that was just a pain. And so like the thing I learned from that is like, just pick a good name from the beginning and go with that. We've done that well with podcast motor, I guess podcast motor has always been podcast motor. I think it's a great name and it will always be podcast motor. But you know, I think that, I think you guys had a good strategy actually with like if you like the name user list and user lists.com is whatever it is too expensive and you can't get it or whatever. Get that.io and then plan to just move the domain but not the name because the name is harder to harder to change later on. So
Speaker 2 31:44 yeah, I guess, yeah, you're right about that. Yeah, just changing the domain wasn't that big of a deal. Especially because like yeah, the name itself didn't change so it didn't have to change a lot of things. Basically setting up a redirector now whenever we see the IO domain somewhere, just replace it with a.com and that's it.
Speaker 1 32:03 Yeah. Yeah. Dealer technical thing that we just totally, we just did, we just didn't consider it. And now that the, the app is growing and we're able to kind of address this as like how users and accounts are set up. Um, so originally like a user was an account and now we have a concept of like, and even in the, you know, let's say like podcasts, you know, so like if you think of, um, user list or, or you know, drip to say like a user is part of an account and an account can have several domains that it has an email address for or email list for. We didn't have any of that shit. We just had like a user was an account was a vodcast. And so we, we took the first step to that, which say like users can have multiple podcasts and that was kind of painful.
Speaker 1 32:53 And then we redid how that worked, uh, about a month ago. And now we're going to say like multiple users can be part of an account and an account has multiple podcasts. But of course like this is a month of work for a developer to do at this point because I mean a ton of shit has to be tested and RSS feeds that if they break someone's podcast just goes away and all this kind of stuff. So I would say like, I can't imagine it's much more work to do this right ahead of time, like to begin with. And I blame myself for just saying, Nope, a user has an account as a podcast go, let's build it. You know? Um, and Jonathan did back of his mind is probably like, well that doesn't make much sense, but whatever, whatever he says. Cause that was like the first thing he built probably. Um, but I would say like future-proof that in your app maybe is what I would try to do next time.
Speaker 2 33:45 Yeah. Yeah. But I guess it's also one of those things where you have to be careful to not just over-engineer it from the start. It's like thinking back, I can point at at least a couple of times where I spent most of my time setting up a project and building stuff like authentication, password reset, user permissions. I don't know what else, like all the stuff that isn't the core of the product and focus on everything but the core of the product and as you can guess, not get anywhere with the product in the end. Yeah, so I don't know, I mean I hear you and I kind of agree that you have to at least somewhat think about it, but when in doubt, just go with the simplest solution and shipped the core of the product and to the part that actually is unique to your business and not like stuff that's auxiliary to that and just like nice to have I guess.
Speaker 1 34:46 Yeah. You know, something like this makes me think of is is I think that probably for both of us, our confidence in what we're building has grown so that if you are starting something new today, having kind of seen the, the path you've been on in the success you guys have with you as a user list and and kind of the path we've been on and where we are with Castillo's, I would say now I'm not going to start something new unless I'm really sure that it's going to work and so I'd have the confidence to say let's take two extra weeks and set this up the way that we're going to want it in five years because I'm not as worried that like no one will come sign up for this thing.
Speaker 2 35:23 You know? Yeah, that's true. I think that you're right, that plays a big role in like making those trade offs because like Edison that like when you're just starting out and have no idea, you can waste a lot of time on that stuff doesn't really matter. But if you're in a spot, as you said, like very confident that this is going to work and people are going to use it, then sure. Like you can probably afford to, to spend some time on like setting up proper permissions and relationship between user sins and counts and stuff like that. Yeah.
Speaker 1 35:55 Fantastic form of procrastination though. Right? Like you're just starting, if you don't know if it's going to work then over engineer the hell out of that thing. Yeah. I mean it's the same way with all the marketing, all the marketing stuff and attribution. When you don't have any customers, you're like, well just go get some customers. That's all. That's all that matters right now. You got to pay the bills. Are you taking any of these things like that we've talked about or maybe that, that you, that you don't want to talk about here, kind of an implementing them with user lists like this year you think?
Speaker 2 36:22 I think we would definitely have to do a better job with, um, the attribution and in our tracking and analytics, but I guess that's supported. I feel like we're pretty on a similar path and have similar ideas, so that's not sure what else to adapt.
Speaker 1 36:39 That's great. No, I mean I think that's the, that's the Mark of like a really mature team, right? I mean you guys, this is your not your first rodeo, so that's awesome that the stuff that you and Jane and Claire have learned from your previous products or consulting engagements have carried over to this where you're doing most of the stuff right the first time. That's awesome.
Speaker 2 36:57 Yeah, and I think that's also one thing I should mention that it's not like that we are geniuses and making things the right way from the start. All of this we learned the hard way I guess making, making a lot of mistakes along the way and just like learning from things that didn't work in the past and now trying to make them better. So it's not like we are, we are in any kind of special or know some secret stuff. We just learned it the hard way
Speaker 1 37:26 for both of you guys, you're both pretty wonderful, so give yourself some credit.
Speaker 2 37:29 Yeah. What we've been doing this for quite a long time. So I think every, everything that I'm kind of doing right now, I did wrong in the past. So yeah, that's how it is.
Speaker 1 37:40 Fair point. Cool. Uh, yeah. So Benedict can you share with folks where they can kind of learn more about you and user list and what you guys are up to?
Speaker 2 37:48 Yes, so a user list is usalous.com and we're also on Twitter at user list and myself, I'm on um, Twitter as Benedict taker and uh, yeah, that's about it. Uh, if you, if you're interested in the podcast, it's a slow and steady podcast.com and we are all always happy about new listeners.
Speaker 1 38:09 Awesome. Awesome. It's a great chat. Thanks so much Benedict and a happy new year to, to you and to everybody listening. Happy new year to you as well.
Speaker 0 38:16 Cheers. Bye. Thanks for listening to another episode of rogue startups. If you haven't already, head over to iTunes and leave a rating and review for the show for show notes from each episode and a few extra resources to help you along your journey. Head over to rogue startups.com to learn more. <inaudible>.
