Episode 850 | How Not to Screw Up When Hiring Your first Developer and More Listener Questions (with Derrick Reimer)

0:00Welcome back to another episode of Startups for the Rest of Us. I'm Rob Walling and in this episode I welcome Derrick Reimer back on the show and we answer four listener questions. We spend a good chunk of time at the top of the show covering three or four questions around hiring your first developer as a bootstrapped founder. Then we dig into the pitfall of building features requested by customers just because they're easy to build because AI makes it easy. the dangers of doing that. Talk about getting over social anxiety as a founder, because you have to learn to market, sell, and all that. And then at the end, touch on trademarks.

0:40Hope you enjoy this episode. Before we dive in, if you're a founder doing more than a million of ARR, odds are pretty good that you have at least one decision, probably more, in front of you that really matter. Things like, do you hire a sales rep or do you hire another engineer? Maybe churn is creeping up. Do you rework your pricing? Do you rebuild onboarding? Do you take the enterprise deal with the custom SLA or do you walk away? And then you realize there's almost no one you can talk it through with. Your team's too close to it, your friends don't get it, and so much of the advice online is for people 10 steps beyond you or people just getting started.

1:17So that's exactly why we host Tiny Summit. It's a small group of founders, all past a million in ARR, getting together for two and a half days in lovely Cancun, Mexico. And it's built around roundtables and the kinds of conversations you can't get anywhere else. It's December 5th through the 7th of 2026 at one of the top resorts in Cancun. Some of the folks in the room are part of our SAS Institute coaching program. That's our year-round community for founders past a million. Ricardo Lassa of Clickin will be there. So will JD of Senior Place. Colin of Status Skater. Adam Acrea of Judo Scale.

2:11I do think it will sell out and we are taking applications and being pretty critical about who we accept. So there is an application process I did want to let you know about. Now, and separately, if you have a product that you want to get in front of serious SaaS founders, we're opening up sponsorships for MicroConf US in Austin, April 18th through the 20th. Our last seven events have sold out, and this one will too. So you're looking at a room full of, say, 250, 275 bootstrap founders with real businesses, like 32, 35 % of our attendees are doing at least$100 ,000 in MRR. Producer Ron is running partnerships this year, and there's a great range of options, including cross-promotion here on the podcast.

2:55You can email him at sponsors at microconf.com. And with that, let's welcome Derek Reimer to the show.

3:13Back by popular demand, it's Derek Reimer. How you doing, man? I'm doing well. How are you? I'm good. How does it feel to be the guest that I chose to be on episode 850 of this fair show? That is a nice round number. Is that an accolade for you? Yeah. Good. Yeah. I handpicked it because, you know, there's a handful of guest people really, really dig and they keep asking me to bring back on. You, of course, are one of those. And today we're going to answer listener questions. We have some really good questions today. I think we're going to dig pretty deep into them. First one is from Michael. and he's asking about hiring his first developer.

3:58Hi Rob, long time listener here. Thank you so much for your podcast. I founded an accounting sauce for Swiss freelancers four years ago and I'm currently at around 24k MRR and I'm thinking about hiring my first developer and I have so many questions around that so I thought I'd ask you. First of all, what qualities would you look out for in the first developer you hire so that that person can actually take things off my plate and free up my time and hopefully take ownership of the code base in the long run? Also, how do you effectively onboard someone onto a code base you've been the sole contributor to?

4:29Would you try to create some sort of documentations or just dive into it and try to teach them on the go? And also, do you have any other tips on how I can de-risk choosing the wrong person and wasting time and money and making the onboarding process as smooth as possible so that the person can get effective as soon as possible. Thank you so much for any inputs. And again, thank you so much for your show. I've been really enjoying it for the past four years. Every Tuesday, it's been a big part of my life. Thanks. So Derek, I'm going to kick this to you first. He has several questions. So let's maybe tackle first, what qualities would you look for in the first developer you hire so that person can actually take things off your plate, free up your time, and hopefully take ownership of the code base in the long run?

5:13As I was thinking about this question, I pulled up my most recent job description when I was hiring my latest full stack dev, who replaced my first developer for SavvyCal. Right, so you've kind of done that twice and then we did it with Drip. So you've literally done this three times with SAS App. So that's why it's a good question for both of us. Yeah, totally. So kind of running through the list of things that I was listing in this, because I sort of use the job description as my spec for the things I'm going to be evaluating against. So I guess the first piece is experience, obviously. If you're hiring somebody to kind of be in this technical founder handing off control of the code base or part of control of the code base to somebody, you want them to have a decent amount of experience.

6:00Obviously, budget permitting. If you're super early stage, maybe you can't afford that. With Drip, we ended up training developers because we were budget constrained. That's something I would recommend. If you can avoid it, I would avoid it. I was looking for someone with a minimum of five years experience as a software developer. It's an arbitrary number, but senior level. Someone with a full stack skill set. So this is like really trying to hone in on someone who is a generalist, who's comfortable conceptualizing a feature from front end to back end, and not somebody who's a specialist. I think about like when we were later stage at Drip, we started hiring, you know, back end engineers and JavaScript developers and these people who are like hyper specific on their skill set and could really own, you know, part of the stack.

6:53But that's going to work against you if you're trying to offload any and all development tasks to a number two. I put thrive working autonomously. Because I think, that's interesting, my previous podcast co-host Ben Orenstein, founder of Tuple, a pair programming app. A lot of developers enjoy pair programming regularly. Some people are accustomed to doing it all the time or just constantly collaborating on features. and so this is something like you probably as the founder don't have time to be pair programming all the time on stuff. And bringing in a lone engineer, not everyone is cut out for that flow of working.

7:37Some people just really thrive on a team and don't work so well independently. So I think that's another important one assuming that you're just hiring one developer to start. And then confidence to ship. What I'm trying to get at with this is sort of like a tamed perfectionism. You want someone who pays attention to the details and cares a lot about quality, but also is willing to accept better done than perfect and just get stuff shipped. Because I think a lot of times on larger teams, maybe where there's less of a sense of urgency or just more hands involved, you can just spend weeks on one small task and making it perfect and making sure it checks all the boxes.

8:17And when you're tiny, startup phase, you don't really have the luxury of being able to do that. So someone who's very biased towards action. I think the other thing I would add, tell me if you think this is accurate still. But there's something to me about a general agreement on the ethos of how you as the founder code. And what I mean by this is back in the day, you may have been doing TDD. Whether you're test first or whether you're, we wanted tests in the code base. there were folks who were like, nah, don't believe in that, don't want to do that. I would not have hired them if they're not willing to do that.

8:53And test is just one example I'm bringing up. There's tabs and spaces. No, there are a bunch of things though, right? And for some people, they're just super flexible, right? And they are willing to kind of go, oh, you want tests? Great, I'll do it. You want tabs? Great, I'll do it, since that's the right way to do it anyways. You didn't have a reaction to that? Is that not a thing anymore? Because I thought you were spaces. Oh, I have spaces, yeah, yeah. I just said tabs is the right way to do it, and you had no reaction. You're not even listening to me. You're backgrounding me. I'm nodding along.

9:26Yeah, totally. I'm waiting for the reaction. But whatever. And tabs and spaces and tests are just examples of this. But there's something, I think, about being in alignment and potentially having some flexibility and willing to change. Let's be honest. If you'd hired a senior first developer, you're working with them, and a cursor, Cloud Code, Windsurf, all these tools. I know Windsurf's old news now, but these tools came out. There are devs out there who refuse to use them. So what do you do then? Do you want that person on your team? There's some type of flexibility and willingness. It's having opinions, because they should have opinions if you're a senior, but being willing to go with the flow, to let you make the final call, to have whatever it is.

10:06There's a collaborative nature of that. Do you feel like that's something you look for? Yes, for sure. And I think it can be hard to pin that down exactly because on the one hand, you don't want someone who doesn't have any opinions or any taste about things. But on the flip side, I've definitely spoken to developers before who are so opinionated and so strong-willed in their convictions that they're almost hung up on that. So I think this is something that maybe would come out even more if you were to do a test project with someone, which I highly recommend during a hiring process. okay, let's work on something together for an afternoon or a few hours and let's see how you react to encountering something that is maybe not done the way you would have done it, but this is the norm established in the code base and are you willing to go along with those norms and maybe recommend shifting pragmatically in a new direction if there's something that is truly better, but also recognizing we can't stop the world and rewrite the code base or it doesn't make sense to fight against the conventions that we've established in such a way where now it's super confusing and anyone coming to the code base is not able to know how to operate.

11:21So yeah, that's a tricky one, but for sure what you don't want to find yourself in the place of is arguing small things all the time because opinions are too strong. You know the person, we all do, we've worked with them. And a lot are developers, some are not. You know, there's people in other parts of the company. Yeah, and then the other one I thought of that I do, whether they're a developer or not, when hiring at even Tiny Seed MicroConf these days, it's almost a hard pass for me if they've only worked at big companies. If they've never worked at a, let's say, sub-50-person company, because Tiny Seed MicroConf's 10 people, right?

11:58And in this case, we're talking about a two - or three-person company or whatever. I mean, it'd be great if they work at a 10 - or 20-person company, but man, if someone's only worked at say a Fortune 500 or 1 ,000 or whatever, the change of mindset is so dramatic. It's such a big deal that it is something I absolutely screen for. Do you ask folks about that? Oh, for sure, yeah. Similar criteria where I'm just kind of not willing to entertain if someone exclusively has big company experience, like you said. Because yeah, I think dev teams just operate so differently. I mean, even watching Drip grow to a team of, what was it, 20 plus when we left?

12:35In 2025, somewhere in there. That was just the engineer product team. Yep, and so even watching how work gets organized, the pace that people work at, it morphs into a different thing. And that's not necessarily a bad experience to have, but exclusively having that can be a culture shock. And I think some people have a harder time adapting to that. And it can be a lot to reorient someone towards the smaller company mindset and maybe you don't have the luxury to do that if you're hiring your first dev. I remember hiring someone and they got in the first day and they were like, so what's the process for da-da-da?

13:10And I was like, there is intent. You ask me. Do you have a form that I fill out? Because I want to get a new mouse and a keyboard. And I'm like, no, just buy it on Amazon. Tell me the total, I'll PayPal. I'll Venmo you out of the company account or whatever. Or I can come to my computer, put it on the thing I'll do with the company card. It's like, that's the process. So it's just different mindsets. And so his next question then was around, he said, how do you effectively onboard someone into a code base, even the sole contributor to? Do you try to create documentation or do you dive in and try to teach them on the go?

13:45How have you handled this? And I'm sure this has changed over the years with AI and all that stuff. Yeah, I think this has changed almost completely from my first iteration of hiring pre-AI versus post-AI. So I think before AI, I recall drafting some documents where I was giving a high-level lay of the land of the code base, like these are the major subsystems. I don't think I tried to put too much in writing, though. It was more like on calls, like let's together walk through the code base and let me show you in the editor where things are and how they fit together at a high level. But I think these days that is squarely in the sweet spot of an LLM.

14:26and I think it's just so much easier in general to get onboarded into a code base because you can literally fire up an agent and just start asking questions about the code base. I was going to ask that because I haven't done, I mean I've used Cloud Code to do some little piddly projects and stuff, index all the podcast episodes, blah, blah, blah. But I have not, you can just ask it, like what are the major subsystems? Yeah, of course you can. That is incredible, wow. It's like we live in the future. All right, and so that's it. So at this point, you'd be like, ask Cloud Code or ask your coding tool, basically.

15:01And you'd obviously give them an overview. I mean, we used to pull someone in for an hour on the whiteboard, right? And be like, here's some boxes and here's some stuff. Here's the general orientation. Here's the servers, whatever. Yeah. You know what? You're going to get a kick out of this too. It will, of course, read Git history. So it can look at a file and know, like, this was introduced by Derek in 2023. and it'll read the git commit comments and the surrounding, it'll look up the pull request that it was attached to and read the surrounding tickets from around that time. So its ability to gather context is just insane.

15:36It'll say like, yeah, this was put in in 2023 as part of this work stream to optimize this part of the slot calculation engine. Right, because that's always the thing is we'd be like, why does this code operate this way? And we're like, nobody remembers, where we'd have to go back through and go through notes or wipe. Holy crap, that's amazing. Well, remember when you were starting to code drip, I was like, we had a conversation and I was like, I don't know how we got here, but it was like, you're going to add code comments. You know, comments. You used to add comments in code, people, to say what it does.

16:08And you're like, I'm not going to do that because it's Ruby and Rails and it's supposed to be written so simply that you can read it and the comments go out of date. And we had this whole conversation. I was like, fine, I believe you. And with tests, it's less brittle anyways. Now that would be laughable to write comments in your code. There's just no reason to. But it's funny too, even these days, just writing a commit message by hand feels archaic. These days you're building with an agent generally, the agent has so much context and the agent can summarize so much better what we did and why we did it.

16:44So it's crazy how much better the commit history has gotten about capturing context. And so his last question, it says, do you have any other tips on how I can minimize the risk of choosing the wrong person, wasting time and money, and making the onboarding process as smooth as possible? I feel like those are two really separate questions, actually. The onboarding itself, we kind of just answered that, and we didn't give strict stuff. How about this? Would you pair program an hour or two a day for the first week or two with a new hire? Yeah, I've always done that. Especially early on, that's your time to really infuse the ethos of what we do and how we do it.

17:28And getting some of those particular patterns that we like to follow when we do things infused into that person is really crucial early on, I think. And some of that can come from an AI agent reading the code base and trying to discern some of that. But also there's the element of building the rapport, here's how we work together on things, here's how we disagree on things and how we resolve those disagreements. So there's a lot of that kind of human level collaboration value in spending time together pairing. So yeah, I've always spent a good couple weeks each day for an hour or two or whatever pair programming.

18:08And then in terms of not choosing the wrong person, I mean, obviously this is the big risk of hiring anybody. This is tough. There's a couple things that come to mind. When I'm looking to hire a developer specifically, I think we have technical acumen, we have interpersonal dynamics, and that includes, do we get along? The thing we said earlier, are they flexible in their thinking? Are they a good team player? There's a ton of stuff you can wrap up into that one. And then the third is, I guess it's just reliability. This is for any employee. Like, do they ship stuff on time? Do they do what they say they're going to do?

18:45And do they show up to work? And do they, you know, not call in sick all the time? Or whatever, right? There's like this kind of consistency reliability. Because I've had folks who were great technically in different roles, whether to dev or copywriter or marketer, great technically, great interpersonally, and they're super flaky, right? So you need all three of these. So the thing you can't test is the third one, the flakiness. You just have to work with someone. And whether that's for a couple weeks on a probationary period or whatever, aside from asking someone when they're going to tell you the right answer, you know.

19:15But the other two you can test in conversations and in pair programming. So when you and I started hiring engineers for Drip, remember it was a take-home project. Now that is laughable because they will do it with AI, which they should, but like it's just you're not going to do that. But we switched to pair programming once we really started hiring engineers because we found it was so much more productive, not just to see the results, but to see how they thought, to see what it's like when they were challenged. You would challenge them usually with one thing. You're like, oh, I'm a really good throw for a loop here.

19:47I'm going to tell them to suddenly use spaces instead of tabs or whatever and see if they completely go postal or whatever. So those are my thoughts. We would have one or two conversations, usually two. That was after an initial HR screening. But then you and I, I think, would have one or two. Then we would bring them in in person because we were hiring in Minneapolis, but now you do a remote with Tuple or something. What was it, a two-hour? Was it usually two hours of hiring? I don't remember. Yeah, I think something like that. I ended up going maybe three hours on my last one. It went really fast in my recollection.

20:21I thought we were going to make so much more progress. We didn't make a ton of progress on what we were doing, but it was still a high-value exercise. Here's the thing with this. This is someone I'm basically like, yes, they've said all the right things. I like this person, I think they're going to be a good fit for the team, as long as they're a good coder, they're in. You know what I mean? This is the last step for me before we hire someone. Because you might think two to three hours of pairing, wow, that's a long time. But most of the time, not all actually, I remember there was one or two that you paired with and you were just like, no.

20:52And it was great, that saved us a ton of time, but most of the time by the time they got there, we did wind up hiring them. Yeah, I will say using a recruiter was super helpful on this last round of hiring. Just because ideally you're promoting this widely that you're hiring to get it in front of hopefully a good amount of people so the right fit can emerge. But then you just have so many applications to wade through, so much sifting and initial screening. Especially with AI now, AI generating applications and all that. Yeah, and I often recommend remote-first recruiting. It's Dan and Ian's recruiting service for, I think it's Flat Fee.

21:34I know it's Flat Fee and a lot of tiny seed companies use that. There are other options out there. I'm curious who you used. I used them, yep. Used them, okay great. And they hire, so folks know, they hire around the world. They hire developers. They hire any role at a SaaS for sure, customer success and sales and stuff. And they hire marketers and freelancers and all kinds of stuff. So remote first recruiting if you're interested. so that's the end of the questions from Michael thanks for sending that in Michael and if you have a question for the show you'd like myself or Derek or another guest to answer you can head to startupswitharestofus.com click ask a question in the top nav and that takes you to our video ask now Derek, have you clicked ask a question and watched the fancy video that I recorded of myself in my very living room that you eat pizza in every other week before D &D?

22:26I have not, no. Oh, well, you need to do it. I should. Because it's cool. It's just me talking to a camera. I had the same video as me in a baseball hat unshowered with no facial hair that I recorded in like 2018. And it was up until about three months ago. And I was like, Ron, we have to fix this. This is catastrophic. So I recorded one. It's not really that great nor worth watching, but I just wanted to ask. So my next question comes from my email list, robwalling.com slash subscribe if you want to receive an essay every week or two. And I'm going to keep this anonymous because I sent an email and oftentimes people just reply and tell me an anecdote or a story about what they've done related to the email.

23:09And so in this case, the essay was, Why You Shouldn't Build Everything Customers Ask For. And I was just talking about weighing. Well, it's funny, it's actually a conversation you and I had on the show. And I kind of was talking about that where we decided, it was like product decisions, right? When do you decide to build something? When do you decide not to? And so this person responded and said, I'm normally pretty good at saying no, but I built a feature for a new client recently that took me a lot longer than I thought it would, even with my new AI workflow. It touches a lot of other code and will add a lot of overhead to maintain because of that.

23:38That sucks. I like the feature, but it's quite complicated, and I'm wondering how many customers will get their heads around it well enough to want to use it. Previously, I probably would have just said no, but I think AI has made me a little overconfident about how much easier it is to write and maintain code now. We'll see what happens. And I simply wanted to bring this up because I bet there are people in the audience who've done this. And I'm wondering if you've made this mistake and if not, how you've kept yourself from making this mistake. Because I could see doing this myself. Oh yeah, I'm nodding along strongly because I've been trying to reflect.

24:12My job has completely changed on the product side of things. It has completely changed over the last year. and one of the things that has changed is how I think about features, how I think about effort level and how much time and money it's going to take to implement something and the economics have radically changed in many respects. So I have found myself, at times it's a struggle to know how to evaluate whether something is worthwhile to build because so many things feel so much cheaper now to build. And there's definitely this vibe going on right now. I don't know if you've seen the DHH stuff with his operating system on Twitter where he's like, we can fix everything.

24:57That's sort of his mantra right now. Or I think it's just so high on the AI productivity. Every problem is solvable. Don't worry, this will be the greatest thing for everybody. It's sort of the vibe. And I think a lot of people are latching on to that, feeling like we can conquer any task now. Therefore, we can make every single customer happy. And I think that's still a fallacy. But for sure, I felt the temptation. I was thinking back over the last few months and trying to see if I could come up with an example of me falling into this trap. And there was one that I could think of where I was talking to a customer.

25:37This was a decent-sized customer for me. And they had a somewhat complex, nuanced HubSpot integration that they were trying to get working. And so SavvyCal integrates with HubSpot already. We have a basic integration that matches what other players have, where you can sync to the contacts in HubSpot and record an entry on the timeline for that contact when they book a meeting. So it's kind of a basic sync between the two systems. And this customer wanted deal creation and they wanted some logic around when someone books through one of these 40 different links, it should create a deal and attach it to the right third party and then make sure that if the person books with another person that the deal is not duplicated.

26:25So there was just some complex, nuanced logic in there. And I did see it as a potential opportunity to have an even more powerful HubSpot integration that we could then bill as a differentiator. If you're doing anything complex with the sales workflow So involving HubSpot, like SavvyCal could one-up everyone else potentially. And I did go so far as to spend a session with an agent kind of mapping out what this would look like if we expanded our integration. And that was a helpful exercise because it's like on the one hand, yes, this is all doable. And I could have an agent do all the code and it would take maybe an afternoon and testing and all that.

27:05But going through that exercise made it clear to me that like, wow, this is going to radically expand this integration. We're calling the API in a lot more ways now. We have to handle all those failure modes. Anytime you're dealing with external integrations, it's always like, what happens if the HTTP request fails? Do you alert? Do you retry? How often do you retry? What happens if you ultimately can't make the call? So there's just all of these different things you have to consider. And sure, we can have agents work on solutions for all those things, but it's still radically expanding the surface area of what your product is having to do and you have to maintain all that.

27:41So ultimately decided to steer this customer towards Zapier, you know, because you can do all this, you can pull all this off with Zapier like you have been able to for years and left it as like, maybe if we hear enough demand for this kind of thing, we now have a sketch for how we might build this out. But what I found helpful was like going through the exercise because it didn't actually take that much time to see what would this actually look like concretely in code. Nice, so you caught yourself. Yep. Yeah, great. I don't have anything to add. It was a genuine I wanted to ask, since I'm not building a software product day to day, I wanted to hear someone boots on the ground with thoughts.

28:20I'm curious what your thoughts are on this, though, to kind of take it from a different angle. I do see a trend towards a lot of software products getting more ambitious on what they take on in their product because it's so much easier to build. So I guess companies changing their strategy and saying, we're going to be more ambitious more and try to do more things deliberately. I'm just curious what you think of that trend. Do you think that's a good thing? Do you think that's necessary? Well, I think it is for the company. If we were running Drip today, Would we want to add big subsystems, an e-commerce thing, or something that would just have been so brutal to build back in the day?

29:07Or an affiliate system, or whatever else. There were some crazy requests that we were never going to build because it would take too much time, but that we did get. CRM was one we frequently got, right? And we lost some deals to HubSpot because they had the CRM plus the email marketing. I think that for many companies, it's probably the right move. I think for Drip, if we could have built that CRM, remember that you and I had resistance to it because I was like, it's going to take months and months and months. And do we want to focus there? But if we could have built that in a fraction of the time, I think it would have been good for the business.

29:38Now, wouldn't all of our competitors maybe have built it? So there's a thing of would it actually have gotten us anywhere? I don't know. I think the biggest thing is like anything, it's knowing your customers, knowing your market and knowing if it's actually going to move the needle or if it's just let's throw a bunch of all in one crap in here and make this a worthless piece of software basically. I guess it depends exactly on what the ambition is, but I think for most people, having more functionality, especially if you have less technical users who don't want to chain things, they don't want Make or Zapier, and they really do just want, I want to get rid of these four tools and do it all in one.

30:17It's like, I get it. And if that's your customer base, I do think you can chew up more of the, potentially more of the space, as long as all the other companies aren't doing the exact same thing, which maybe they will be. Or if they are, it might gradually become table stakes for someone in your market too. It's like now you're the only one who doesn't have those features. Yeah, it's tough. That's a good question. The next question is about social anxiety. I had mentioned this in one of my emails as well. Someone responded and they said, I'm curious about the anxiety element you mentioned. I'm 29, I'm a software engineer and I love building my own projects, but I also have social anxiety, which makes customer interviews, marketing, and sales difficult.

30:59Obviously, that stuff is all absolutely crucial as a founder, which it is. I chuckle because it is. How did you turn your anxiety around? And I'll go first on this one. For me, it was practice. It just gets better the more you do it. And the anxiety I had when I was shipping the first blog post or recording the first podcast episode was terrifying. The first time I got on stage, I just froze. I was so scared. And now I get on stage and I'm like, yeah, this is what, the 50th time or 100th time probably? I emcee events, blah, blah, blah. I just had to do it over and over, practice. Now, that's easier said than done, but it is a thing.

31:31There are people who take beta blockers. Have you heard of this? It's a pill that can help reduce. I never did that. I probably should have at a certain point. You don't want to do it every day at every sales call or whatever, but it can help you for a bit, I think. The other thing I have known, I'm going to go on other suggestions I've seen. There was a founder we backed in Tiny Seed who had real social anxiety and they would have someone else join them on the call, someone from their team on certain calls. They're like, it's a sales call, I'm going to be stressed. I want you to get on and just kind of be my wing person so that we can do it.

32:06Now, is it expensive? Is it a bad user resources? Maybe. But do you get better at it and then at a certain point you don't need them? Maybe. The other thing I can imagine is actually if it's really bad, like trying to get either a therapist or a book or a course on it. it depends on if you learn from books and courses i do not everyone does and i definitely learn from therapists so i could see if i had really bad social anxiety like trying to get to the root of it i bet there's a root of it and and like everything you learn that it's like oh it's from this childhood belief or this childhood experience that was really messed up and this is why everything you know how everything flows from that and until you get to the you can get over it by repetition and kind of numbing yourself to it not in a bad way and actually a good way or through, I think, more poignant and pointed treatment.

32:53So that's what I would say. You have any other thoughts to add? Yeah, that's pretty much in line with where I was headed with it where I'm a naturally reserved introverted person so doing sales calls doesn't come naturally to me. I get very in my head about it. And if I think about where that anxiety comes from, oftentimes it's like fear of sounding stupid or fear of messing up or saying something that's going to ruin my chances of closing this deal or whatever. But I think a lot of that ultimately comes from lack of experience and I have some of that lack of experience because there's a hesitancy to do it.

33:29So part of it is just getting started and forcing yourself to get those reps in knowing that it's going to suck until you start to build confidence and then the more confidence you build the less anxiety you're going to feel because you've seen some things, you know how to deal with certain situations. Specifically on like the sales call front, something I've been doing, which I'm in general a little bit skeptical to offer this kind of advice, like leaning on an LLM in this way, because I don't think LLMs are great therapists. I think they reflect back what you want to hear oftentimes, which is not often what you need to hear.

34:04So like, I think there's still definitely a place for seeking real advice from like a mental health professional for real issues of that nature, but specifically around coaching yourself or figuring out how to improve on sales call performance. I found it super helpful to obviously use the call recorder thing when I'm doing one and then feed it into Claude or your favorite agent of choice and ask for an objective, what went well, what didn't go well on this, what could I do better? And they're actually pretty good at identifying like, okay, you spoke too much or you didn't speak enough or you should have spent more time on this area.

34:44And just like getting that contextualized advice or feedback about how the call went, when a lot of it is basically reflecting back things where like, yeah, if I think about it, that makes a lot of sense. But sometimes it's hard to evaluate your own performance when you have all of this, all of this like self-doubt wrapped up in it. So just getting hyper-contextualized feedback has been super helpful on me gaining more confidence more quickly, I would say. Yeah, that's great. That's really good advice. So thanks for that question. Hope it was helpful. Our last question of the day is from New Zealand.

35:25Hey, Rob. Aaron here from New Zealand. Love the podcast. I'm in a trades business and I've sort of built a pretty awesome trade specific CRM for myself Started off as a sort of a take off and estimating tool and it sort of morphed into a pretty awesome CRM My question is around trademarking I think copywriting, doing a bit of research is automatic But trademark, it's quite costly I've got a pretty cool name for my CRM I've built and was wondering your thoughts around trademarking. Is it worth the big investment up front to just do it now before somebody sees my pretty cool idea and tries to steal the name?

36:16Thanks, mate. All right. So Derek, there's an interesting thing here. Number one, neither you or I are lawyers, so no one should ever take our legal advice. But we do have pontifications and thoughts as multiple decade-long software entrepreneurs. The other interesting thing is, of course, I went to Claude and was asking it about US trademark law, New Zealand trademark law, and it is different. So that's a whole interesting thing. But I will ask, how many trademarks have you filed for your company names, product names? I think I've attempted to file one, and it got rejected, and I didn't take it any further.

36:54yep I've had that happen a few times tried to trademark drip and it was like nope prior art too generic all this stuff did get I think we have the trademark for microconf and startups for the rest of us but yeah I've tried to file other trademarks and they've all gotten rejected so I think in general well here's the thing in the U.S. if you have a unique name at least the way describes it, you do have a, like, it's a use defense, in essence, that if you can prove that you use it, and then someone later tries to trademark it or whatever, that you can swoop in, but it's more expensive, it's weaker case than if you had just filed it, all that stuff.

37:35So the question is, filing fees, I think in the US are$350, somewhere around there. If you use a lawyer, it's tend to be$1 ,000 to$2 ,000, I think, when I've done it, maybe$1 ,500. And that's if it's pretty easy. It depends on how many classes you're applying for, blah, blah, blah. So that would be the question is, is that worth it to you in the US? Now in New Zealand, again, this is according to Claude, but I'm using like Opus, right? Not like it's Opus five, you know, high, high thinking. So I think it's probably relatively accurate. It specifically says, this is not legal advice, double check everything.

38:08It said that in Claude, but in New Zealand, that use defense, you don't have that. So it's literally the first person that files, even if you've been using it in trade for years, someone else comes along and files it. Yeah, it's crazy, huh? I mean, I say crazy, that sounds not great. You know, I like the idea of like copyright by default. Like I literally don't have to submit a book when I publish it because I put copyright, all rights reserved, that's when it's copyrighted. Now, if I ship it to the copyright office, it is a little better or the PTO, the patent trademark office. It is definitely better and stronger, but that's kind to brutal.

38:44To me, there's more of a reason to file, in all honesty, right? And in New Zealand, I just, again, look it up quickly. It looks like if you do it yourself, it's$150,$200. And if you use a lawyer, it says it's about the same, like$500 to$1 ,500. So I don't know. That's it. Like, I can't make a recommendation on this one because it really is a risk tolerance. And it's like the odds of something happening are low, but if it does, that would suck. And if someone else trademarked it in New Zealand and you just lose it like that, I would maybe lean towards doing it. But I would try to figure out, can I have Manus fill out the form?

39:23Honestly, right? Or can I have AI fill it out now that we're at a place where, I don't know if I need a turn. I've never tried this to do it. I've always just hired, I throw money at somebody, $500,$1 ,000, whatever. I'm wondering if it is less expensive if you could get AI to do it. What do you think? Yeah, and I think that would be, because I think I've tried to use, I don't know if it's LegalZoom or one of those like Rocket Lawyer or something like that where it's like kind of a... Yeah, where it's like not really, you're not hiring a lawyer directly, it's like a legal service where they give you the template or whatever and you kind of fill the stuff in.

39:59And maybe I've gotten rejected in the past because I didn't fill something in quite right and I feel like an LLM would probably have a better shot than me who has definitely no lawyer here to be able to get the stuff put in in the right way where the patent office likes it. So yeah, I think it's for sure worth a shot. And these days, I think it's easy to have the extreme lean bootstrapper mindset of like, no, it's not even worth$300 or whatever. But I think especially with the reality of New Zealand, if that was true here, I think I would be probably more apt to push for it. Me as well. I get these questions, right?

40:42It's like, should I file an LLC or be a sole proprietorship? When do I do that? Or when do I form the company? Sometimes it's a liability thing, sometimes it's other. Should I have E &O insurance and general liability? There's all kinds of cyber blah, blah, blah insurance. And then there's trademarks and copyright and all the IP protection. and these are all, if you talk to an attorney, man, they'll tell you to do all of them day negative 10 before you even think you have a business. Do all the things, you know, and the insurance person says, do all the things because bad things can happen and they've seen bad things happen.

41:15And those are all true, but also you're an entrepreneur and you don't have a bunch of money and like, don't overdo this. That's, I think, the balance we're trying to strike here. Cool, well, Mr. Derek Reimer, thanks so much for joining me on the show today. You are Derek Reimer on X Twitter and SavvyCal.com if folks want to use the best scheduling and appointment booking on the internet. Well, not just a link, but appointments and meetings. Now you do that, right? Yes. So people know what appointments are. So we're talking like medical offices and who else schedules appointments for medical offices?

41:54Lawyers. we've actually been mostly focused on telemedicine has sort of become our niche. Especially if you're building custom flows for a telemedicine app where you don't want to rely on your EHR that's super slow and clunky and doesn't resolve slots very well. SavvyCal can kind of sit in between and unblock your sales funnel for new patients. Yeah, and that makes a lot of sense. At first when you told me meetings which is what we all use SavvyCal for and then appointments is a different thing. I was like, aren't they the same? And you're like, oh, my sweet summer child. You have no idea what an appointment, appointments are complicated and there's workflows involved with them and maybe multiple.

42:37Centralized management of things and office management and things, yeah. Yeah, so it's that. So SavvyCal.com if you want to check that out. Thanks again for coming on the show. Thanks for having me. Thanks again to Derek for coming on the show and donating an hour of his time to help our worldwide community of tens of thousands of bootstrapped SaaS founders. And thank you for listening this week and every week. And as I mentioned, this is episode 850. And sometimes I think, how did I get here? And the way I got here was by recording every week since 2010. Just keep showing up. And I think that's probably the way that you build anything interesting is to do it over a long period of time and show up every day, every week, every month.

43:20Keep pushing the ball forward, whether you're writing books, whether you're shipping software, whether you're shipping a podcast or something else. Thanks for joining me this week and every week. This is Rob Walling signing off from episode 850.

44:08Welcome, loyal listener, to the hidden track of Startups for the Rest of Us. When I told Derek just now that we're doing a hidden track, he said, and I quote, Oh no, yes, no. Oh yes, I meant to say. We are doing trivia about something, sir, I hope you don't embarrass yourself about. Because this is something that I think you should know. Drip Trivia. Drip.com. For those who don't know, Derek and I started a company years ago and we sold it to Leadpages back in some time because I'm going to ask you about those things. I had to look up one of these. Derek wrote every line of code for, I don't remember, eight months, a year, quite a long time.

44:53A lot of early commits from you. And then we moved on to do our next things. But the first question is, what month and year was the first line of code written for Drip? Okay, I'm pretty sure this was, is it November of 2012? So close. It's December. It's December. And the only reason I know this is because I did a talk back in 2013, 14, and I had a slide of your commits, you know, of your git commits. Because I was trying to show, and then it was like, and then we wrote a bunch of code, or Derek wrote a bunch of code, and it was all your commits, and I remember December was the first month. So close.

45:40I'm going to give you half credit. Yeah, I got the year, I got the quarter. You were close, yeah. Pretty sure we sat down at the Iron Bird Cafe in October, November. What do you think it was? October? Iron Bird Cafe in Fresno. I actually, in Idea Detraction, my book's coming out in the next month or two, I have those little, you know, I put in the little, they're not anecdotes, but they're the retellings of the actual moments, right? I have those in SAS Playbook where it's like, oh, I was so stressed and blah, blah, blah. And I have one, I was like, okay, Derek, I want you to build a product for me.

46:15And it's like, I had this idea, he and I were sitting at the now defunct Iron Bird Cafe in Fresno, California. And I was just proofreading the book yesterday. So it'll be fun walk down memory lane. I'm going to give you 0.75, three quarters for that one, I think. Yep. Second question, what month and year did the drip acquisition go through? When did we sign the docs? When did the money get wired? All that stuff. I got this one. My guess was right. I opened the asset purchase agreement to confirm. Yep. I'm going to say, I think it was June 2016. Dude, you are so close. It was July 1st of 20. The APA said July 1st because they announced it on like the 8th.

46:58And I remembered over, well, I remembered over 4th of July, we were all chitter-chattering. So yeah, June would have been, end of June would have been. It almost closed end of June. Oh. Yeah, it was close. All right, this one's a two-parter, and frankly, the first part doesn't count. If you miss it, it doesn't count. So MailChimp's system for identifying potentially problematic email addresses, like spam and senders, had an animal-themed name. What was it? Ooh. Like an animal classification. This one I came up with off the top of my head, and I had ChatGPT double-check me. Did you remember it?

47:35I did, yeah. Mm-hmm. Because we were then, because the second part of this question is, we were going to build the same like engine, centralized engine for spam and bad sender detection. And we never did, but I came up with a name internally and it was kind of a stupid name. Oh my gosh. Do you remember either of these? I should really remember this. I mean, I remember there was a thing. Yeah. I can't believe I've forgotten it. Ben Chestnut used to talk. I know, isn't it? But you can't, but it's like 14 years ago, dude, or whatever. Like it's a long time. So male chimps was called omnivore. That's okay.

48:12Omnivore. And I wanted to call ours carnivore for no reason. It wasn't going to eat meat. It was just to be dumb. All right, so you got a zero on that one. Sorry about that, man. Okay. In a drip workflow, what is the term for the element that can pull a subscriber forward through the remaining steps of the workflow once they have accomplished something. Oh man, you don't remember anything. I remember all of this. You're kidding me. You wrote all the code for this. What is happening? Dude, it's like the trauma. Oh, I'm just going to keep talking. The trauma of that, you're like, I flushed it, bro.

48:54I can't even deal with it. I mean, I can picture the whiteboard where we designed it. Of course you can. And you, yep. and you can probably tell me how it works once I tell you the name of it. Okay, pulls you forward. Think, Derek. Let's see. Hint, it was not a trigger, an action, a decision, a delay, or an exit. Those are all the other types of nodes in a drip workflow. This is catastrophic. I can't believe. Me neither. I'm surprised. There's no shame in this. It's not a go-to. You put so much new in your head that you have to get rid of the old. The cash has been crowded out. It's a goal. A goal.

49:43Yeah, there's a goal.

49:48And you could say goal, and it's like, well, what's the goal? And it's like, they clicked this email, or they hit this webpage, or they purchased this, whatever. What's happening up here, you're giving them 50 emails in a row, but if they purchase, it pulls them down to that goal. It pulls them ahead. Now I remember that. Of course you do. All right, last question. This is the worst you've ever done. I did better on the D &D quiz. I know you did, which I'm surprised by. Immediately after Leadpages acquired Drip, what somewhat crazy price did they introduce for an entry-level drip plan? Yeah. Was it$10?

50:33It was$1. $1, okay. There was a$1 100 subscriber plan maybe? I actually don't fully remember how many subs it had. This one ChatGPT pulled from a blog post that Clay wrote. And then later we moved to, there was a free plan for a while. I do remember that. Yeah, we still ask for credit card because that was such a signal for spam. But dude, for real, you basically got zero out of five is what actually happened. But I gave you... What are we doing? This is, it's a trip. But a 1.5 out of five, because I gave you 0.75 on those two gimme. So you get a 30%. That's a solid F minus or so. Oh my gosh. How do you feel about yourself?

51:21Terrible. terrible I was the guy in school who had to get an A in every class so this is devastating yeah