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

Rob Walling: Welcome 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, and the dangers of doing that. We 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, we touch on trademarks. Hope you enjoy this episode. Before we dive in, if you are a founder doing more than a million in ARR, odds are pretty good that you have at least one decision, probably more, in front of you that really matters.

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 ten steps beyond you, or people just getting started. So 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. It’s built around round tables 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 SaaS Institute coaching program, our year-round community for founders past a million. Ricardo Lasa of Clicken will be there [VERIFY: “Clicken” – unsure of spelling]. So will JD of Senior Place, Colin of Status Gater [VERIFY: unsure of spelling], Adam Macria of Judoscale [VERIFY: unsure of spelling], and Karen Delaney from Flat Plan [VERIFY: unsure of spelling]. If you want to get in a room with some incredible founders to solve your toughest problems, I hope you’ll join us, because I’m going to be there too. I think it’s going to be small, like fifteen to twenty founders, so it really is a premium retreat. You can get all the details and apply to attend at tinyseed.com/tinysummit. I 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 wanted to let you know about. 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 to 275 bootstrapped founders with real businesses. About 32 to 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. You can email him at sponsors@microconf.com. And with that, let’s welcome Derrick Reimer to the show.

Backed by popular demand, it’s Derrick Reimer. How you doing, man?

Derrick Reimer: I’m doing well. How are you?

Rob Walling: I’m good. How does it feel to be the guest that I chose to be on episode 850 of this very show?

Derrick Reimer: That is a nice round number.

Rob Walling: Is that an accolade for you? Yeah, good. I handpicked it because there’s a handful of guests people really, really dig, and they keep asking me to bring back on. You, of course, are one of those. Today we’re going to answer listener questions. We have some really good questions today, and I think we’re going to dig pretty deep into them. The first one is from Michael, and he’s asking about hiring his first developer.

Michael (Listener): Hi Rob, long-time listener here. Thank you so much for your podcast. I founded an accounting SaaS for Swiss freelancers four years ago, and I’m currently at around $10.4K 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 for in the first developer you hire, so that person can actually take things off my plate, free up my time, and hopefully take ownership of the codebase in the long run? Also, how do you effectively onboard someone onto a codebase you’ve been the sole contributor to? Would you try to create some sort of documentation, 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 the person can get effective as soon as possible?

Thank you so much for any input. 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.

Rob Walling: So Derrick, I’m going to kick this to you first. He has several questions, so let’s 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 codebase in the long run?

Derrick Reimer: As I was thinking about this question, I pulled up my most recent job description from when I was hiring my latest full-stack dev, who replaced my first developer for SavvyCal.

Rob Walling: 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 SaaS apps. That’s why it’s a good question for both of us.

Derrick Reimer: Yeah, totally. So running through the list of things I was listing, because I sort of use the job description as my spec for the things I’m going to be evaluating against: I guess the first piece is experience. Obviously, if you’re a technical founder handing off control of the codebase, or part of the control of the codebase, to somebody, you want them to have a decent amount of experience, 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.

Rob Walling: That’s something I would recommend avoiding, if you can.

Derrick Reimer: Yeah. So I was looking for someone with a minimum of five years of experience as a software developer. It’s kind of an arbitrary number, but senior level, and someone with a full-stack skill set. This was 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. When we were later stage at Drip, we started hiring backend engineers and JavaScript developers, people who were hyper-specific in their skill set and could really own part of the stack, but that’s going to work against you if you’re trying to offload any and all development tasks to a number two. I put “thrives 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. As the founder, you probably 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. Some people just really thrive on a team and don’t work so well independently. So I think that’s another important one, assuming 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 a tamed perfectionism. You want someone who pays attention to the details and cares a lot about quality, but is also willing to accept better done than perfect, and just get stuff shipped. On larger teams, where there’s maybe less of a sense of urgency or just more hands involved, you can spend weeks on one small task, making it perfect and making sure it checks all the boxes.

When you’re a tiny, startup-phase company, you don’t really have the luxury of being able to do that. So someone who’s very biased toward action.

Rob Walling: I think the other thing I would add, tell me if you think this is still accurate, but there’s something to me about general agreement on the ethos of how you, as the founder, code. Back in the day, you may have been doing TDD, whether you’re test-first or whatever, we wanted tests in the codebase. There were folks who were like, “Nah, I don’t believe in that, don’t want to do that.” I would not have hired them if they weren’t willing to do that. Tests are just one example, but there’s also tabs versus spaces. There are a bunch of things, right? For some people, they’re just super flexible, and they’re willing to 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 anyway.” You didn’t have a reaction to that?

Is that not a thing anymore? Because I thought you were spaces.

Derrick Reimer: Oh, I use spaces. Yeah.

Rob Walling: Yeah, spaces all the way. 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, waiting for the reaction, but whatever. Tabs, spaces, and tests are just examples of this, but there’s something about being in alignment, and having some flexibility and willingness to change. Let’s be honest: if you hire a senior first developer, you’re working with them alongside Cursor, Claude Code, Windsurf, all these tools. I know Windsurf’s old news now, but when these tools came out, there were devs out there who refused to use them. So what do you do then? Do you want that person on your team? There’s some flexibility and willingness needed. It’s fine to have opinions, because they should have opinions if they’re senior, but they need to be willing to go with the flow, let you make the final call. There’s a collaborative nature to it. Do you feel like that’s something you look for?

Derrick Reimer: Yes, for sure. And I think it can be hard to pin down exactly, because on the one hand, you don’t want someone who doesn’t have any opinions or 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 get hung up on it. So I think this is something that would come out even more if you did a test project with someone during the hiring process, like, “Let’s work on something together for an afternoon or a few hours,” and see how they react to encountering something that isn’t done the way they would’ve done it, but is the norm established in the codebase. Are they willing to go along with those norms, and maybe recommend shifting pragmatically in a new direction if something is truly better, while also recognizing you can’t stop the world and rewrite the codebase, or fight against established conventions in a way that makes it confusing for anyone coming into the codebase?

So yeah, that’s a tricky one. What you don’t want is to find yourself arguing about small things all the time because opinions are too strong.

Rob Walling: You know the person, we all do, we’ve worked with them, and a lot are developers, some are not, there are people in other parts of the company too. The other one I thought of, whether they’re a developer or not: when hiring at even TinySeed or 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, let’s say, a sub-50-person company, because TinySeed and MicroConf are 10 people, and in this case we’re talking about a two or three person company. It’d be great if they worked at a 10 or 20 person company, but if someone’s only worked at, say, a Fortune 500 or Fortune 1000, the change of mindset is so dramatic, it’s such a big deal, that it’s something I absolutely screen for. Do you ask folks about that?

Derrick Reimer: Oh, for sure. Similar criteria, where I’m just not willing to entertain it if someone exclusively has big company experience, like you said, because dev teams operate so differently. Even watching Drip grow to a team of, what was it, 20-plus when we left?

Rob Walling: 20, 25, somewhere in there. That was just the engineering and product team.

Derrick Reimer: Yep. Even watching how work gets organized, the pace people work at, it morphs into a different thing. That’s not necessarily a bad experience to have, but exclusively having that can be a culture shock. Some people have a harder time adapting to it, and it can be a lot to reorient someone toward the smaller company mindset, and maybe you don’t have the luxury to do that if you’re hiring your first dev.

Rob Walling: I remember hiring someone, and on their first day they were like, “So what’s the process for da da da?” I was like, “There isn’t one. You ask me. Do you have a form to fill out because you want a new mouse and keyboard?” And I’m like, “No, just buy it on Amazon, tell me the total on PayPal, I’ll Venmo you out of the company account, or come to my computer and put it on the company card.” That’s the process, it’s just a different mindset. So his next question was: how do you effectively onboard someone into a codebase you’ve been the sole contributor to? Do you try to create documentation, or dive in and teach them on the go? How have you handled this? And I’m sure this has changed over the years with AI and all that.

Derrick Reimer: Yeah, I think this has changed almost completely from my first iteration of hiring, pre-AI versus post-AI. Before AI, I recall drafting some documents giving a high-level lay of the land of the codebase, like, these are the major subsystems. I don’t think I put too much in writing, though. It was more like on calls, walking through the codebase together, showing them in the editor where things are and how they fit together at a high level. But these days that’s squarely in the sweet spot of an LLM. It’s so much easier in general to get onboarded into a codebase, because you can fire up an agent and start asking questions about it.

Rob Walling: I was going to ask that, because I haven’t done much with it. I’ve used Claude Code for some small projects, like indexing podcast episodes, but I haven’t tried this. You can just ask it what the major subsystems are? That is incredible.

Derrick Reimer: Yeah.

Rob Walling: It’s like we live in the future. All right, so at this point you’d just ask Claude Code, or your coding tool, and obviously give it an overview. We used to pull people in for an hour at the whiteboard: “Here’s some boxes, here’s some stuff, here’s the general orientation, here’s the servers,” whatever.

Derrick Reimer: Yeah, and you’ll get a kick out of this too. It’ll of course read Git history, so it can look at a file and know this was introduced by Derrick in 2023, read the Git commit comments and the surrounding pull request it was attached to, and read the surrounding tickets from around that time. Its ability to gather context is just insane. It’ll say something like, “This was put in during 2023 as part of a work stream to optimize this part of the slot calculation engine.”

Rob Walling: Right, because that’s always the thing, we’d be like, “Why does this code operate this way?” And we’d say, “Nobody remembers,” or we’d have to dig back through notes. Holy crap, that’s amazing. Remember when you were starting to code Drip, we had a conversation, and I don’t know how we got here, but it was about adding code comments. You used to add comments to code to say what it does, and you said, “I’m not going to do that, because it’s Ruby on Rails, and it’s supposed to be written so simply that you can read it, and comments go out of date.” We had this whole conversation, and I said, “Fine, I believe you.” And with tests, it’s less brittle anyway. Now it would be laughable to write comments in your code.

There’s just no reason to.

Derrick Reimer: Yeah, but it’s funny, even these days, just writing a commit message by hand feels archaic, because these days you’re building with an agent generally, and the agent has so much context, it can summarize so much better what we did and why we did it. It’s crazy how much better the commit history has gotten at capturing context.

Rob Walling: And his last question was, 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. We kind of just answered the onboarding one. How about this: would you pair program an hour or two a day for the first week or two with a new hire?

Derrick Reimer: 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, getting some of those particular patterns we like to follow infused into that person, which is really crucial early on. Some of that can come from an AI agent reading the codebase and trying to discern that, but there’s also the element of building rapport, building “here’s how we work together on things, here’s how we disagree and resolve those disagreements.” There’s a lot of human-level collaboration value in spending time together pairing. So yeah, I’ve always spent a couple of weeks, an hour or two each day, pair programming.

Rob Walling: And in terms of not choosing the wrong person, this is the big risk of hiring anybody, and it’s tough. A couple things come to mind. When I’m looking to hire developers specifically, I think about technical acumen, interpersonal dynamics, which includes, do we get along, are they flexible in their thinking, are they a good team player, there’s a ton of stuff wrapped up in that one. Then the third is reliability, which is true for any employee: do they ship stuff on time, do they do what they say they’re going to do, do they show up to work and not call in sick all the time? There’s a consistency and reliability piece, because I’ve had folks who are great technically in different roles, whether dev, copywriter, or marketer, great technically, great interpersonally, and super flaky.

So you need all three. The one you can’t test is the flakiness, you just have to work with someone, whether that’s a probationary period or whatever. The other two you can test in conversations and pair programming. When you and I started hiring engineers for Drip, remember it was a take-home project? Now that’s laughable, because they’ll do it with AI, which they should, but you can’t rely on that. 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 was like when they were challenged. You’d usually challenge them with one thing, like, “I’m going to throw them for a loop here and tell them to suddenly use spaces instead of tabs, and see if they completely go postal.”

So those are my thoughts. We’d have one or two conversations, usually two, after an initial HR screening. Then we’d bring them in person, because we were hiring in Minneapolis, but now you do it remote with Tuple or something for, what, two hours of pairing? I don’t remember.

Derrick Reimer: Yeah, something like that. I ended up going maybe three hours on my last one. It went really fast in my recollection, I thought we were going to make so much more progress, and we didn’t make a ton of progress on what we were doing, but it was still a high-value exercise.

Rob Walling: Yeah, here’s the thing. By this point I’m basically like, “Yes, they’ve said all the right things, I like this person, I think they’ll be a good fit for the team, as long as they’re a good coder, they’re in.” This is the last step for me before hiring 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 one or two you paired with and you were just like, “No,” and that was great, it saved us a ton of time. But most of the time, by the time they got there, we ended up hiring them.

Derrick Reimer: Yeah, I’ll say using a recruiter was super helpful on this last round of hiring, because ideally you’re promoting it widely to get it in front of a good number of people so the right fit can emerge, but then you have so many applications to wade through, so much sifting and initial screening.

Rob Walling: Especially with AI now, generating applications and all that. I often recommend Remote First Recruiting, Dan and Ian’s recruiting service, I think it’s a flat fee, and a lot of TinySeed companies use them. There are other options out there. I’m curious who you used.

Derrick Reimer: I used them. Yep.

Rob Walling: You used them, okay great. So folks know, they hire around the world, they hire developers, they hire any role at a SaaS company, customer success, sales, marketers, freelancers, all kinds of stuff. So, Remote First Recruiting, if you’re interested. That’s the end of the questions for Michael. Thanks for sending that in, Michael. If you have a question for the show you’d like myself, Derrick, or another guest to answer, head to startupsfortherestofus.com, click “Ask a Question” in the top nav, and that takes you to our video ask. Now, Derrick, have you clicked “Ask a Question” and watched the fancy video I recorded of myself in my very living room, where you eat pizza every other week before D&D?

Derrick Reimer: I have not. No.

Rob Walling: Oh, well, you need to, because it’s cool, it’s just me talking to a camera. I had the same video of myself in a baseball hat, unshaven, no facial hair, that I recorded in 2018, up until about three months ago. I was like, “Ron, we have to fix this, this is catastrophic.” So I recorded a new one. It’s not really that great, nor worth watching, but I wanted to ask. My next question comes from my email list, robwalling.com/subscribe, if you want to receive an essay every week or two. I’m going to keep this anonymous, because I sent an email and often people reply with an anecdote or story about what they’ve done related to it. In this case, the essay was “Why You Shouldn’t Build Everything Customers Ask For.” I was talking about weighing.

It’s actually a conversation you and I had on the show, about product decisions, when do you decide to build something, when do you decide not to. 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. That 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’ve 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.” I 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 it, because I could see doing this myself.

Derrick Reimer: Oh yeah, I’m nodding along strongly, because I’ve been trying to reflect. My job has completely changed on the product side over the last year, and one of the things that’s 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. The economics have radically changed in many respects. I’ve found it a struggle at times to evaluate whether something is worthwhile to build, because so many things feel so much cheaper now to build. There’s definitely this vibe going on right now, I don’t know if you’ve seen the DHH posts about his operating system on Twitter, where he’s like, “We can fix everything.” That’s sort of his mantra right now, very high on AI productivity, like every problem is solvable.

Don’t worry, this will be the greatest thing for everybody, is sort of the vibe. I think a lot of people are latching onto that, feeling like we can conquer any task now, therefore make every single customer happy. I think that’s still a fallacy. But for sure I’ve felt the temptation. Thinking back over the last few months, trying to come up with an example of me falling into this trap, there was one I could think of: I was talking to a customer, a decent-sized customer for me, who had a somewhat complex, nuanced HubSpot integration they were trying to get working. SavvyCal already integrates with HubSpot, we have a basic integration that matches other players, where you can sync to contacts in HubSpot and record the meeting when someone books.

Or 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. This customer wanted deal creation, and some logic around when someone books through one of 40 different links, it should create a deal and attach it to the right party, and make sure the deal isn’t duplicated if the person books with someone else. There was some complex, nuanced logic in there. I did see it as a potential opportunity to have an even more powerful HubSpot integration we could bill as a differentiator. If you’re doing anything complex with a sales workflow involving HubSpot, SavvyCal could one-up everyone else, potentially. I went so far as to spend a session with an agent mapping out what this would look like if we expanded our integration.

That was a helpful exercise, because on the one hand, yes, this is all doable, an agent could do all the code, and it would take maybe an afternoon plus testing. But going through that exercise made it clear that this was going to radically expand this integration. We’d be calling the API in a lot more ways, and have to handle all those failure modes. Anytime you’re dealing with external integrations, it’s always: what happens if the HTTP request fails? Do you alert? Do you retry? How often? What happens if you ultimately can’t make the call? There are all these things to consider. Sure, agents can work on solutions for all of that, but it’s still radically expanding the surface area of what your product has to do, and you have to maintain all of it.

So ultimately I steered this customer toward Zapier, because you can do all this through Zapier, like you’ve been able to for years, and left it as, maybe if we hear enough demand for this kind of thing, we now have a sketch for how we might build it out. What I found helpful was going through the exercise, because it didn’t actually take that much time to see what this would look like concretely in code.

Rob Walling: Nice, so you caught yourself. I don’t have anything to add, it was a genuine question, since I’m not building a software product day to day, I wanted to hear from someone with boots on the ground.

Derrick Reimer: I’m curious what your thoughts are, to take it from a different angle. I do see a trend toward software products getting more ambitious about what they take on, because it’s so much easier to build. Companies changing their strategy, saying, “We’re going to be more ambitious and try to do more things deliberately.” I’m curious what you think of that trend. Do you think it’s a good thing? Necessary?

Rob Walling: 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 an affiliate system, or whatever else that would have been so brutal to build back in the day? There were some, I’ll say, crazy requests we were never going to build, because it would take too much time. CRM was one we frequently got, and we lost some deals to HubSpot because they had the CRM plus the email marketing. For many companies it’s probably the right move. For Drip, if we could’ve built that CRM, remember we had resistance to it, because I was like, “It’s going to take months and months, do we want to focus there?” But if we could’ve built it in a fraction of the time, I think it would have been good for the business.

Now, wouldn’t all our competitors maybe have built it too? So there’s a question of whether it would’ve actually gotten us anywhere. I don’t know. I think the biggest thing, like anything, is knowing your customers, knowing your market, and knowing if it’s actually going to move the needle, or if it’s just throwing a bunch of all-in-one stuff in there and making the software worthless. It depends exactly on what the ambition is, but for most people, having more functionality, especially if you have less technical users who don’t want to change things, don’t want Make or Zapier, and just want to get rid of four tools and do it all in one, I get it. If that’s your customer base, you can chew up more of the space, as long as all the other companies aren’t doing the exact same thing, which maybe they will be.

Derrick Reimer: Or if they are, it might gradually become table stakes for someone in your market too. Now you’re the only one who doesn’t have those features.

Rob Walling: Yeah, it’s tough. That’s a good question. The next question is about social anxiety, and I mentioned this in one of my emails too. Someone responded and 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. Obviously that stuff is all absolutely crucial as a founder, which it is, I chuckle because it is, how did you turn your anxiety around?” I’ll go first on this one. For me, it was practice, it just gets better the more you do it. The anxiety I had when I was shipping my first blog post, or recording my first podcast episode, was terrifying. The first time I got on stage I just froze, I was so scared. Now I get on stage and it’s like the 50th or 100th time, probably, at MicroConf events.

I just had to do it over and over, practice. That’s easier said than done, but it’s a thing. Some people 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, but it can help for a bit, I think. The other thing I’ve seen, other suggestions: there was a founder we backed at TinySeed who had real social anxiety, and they’d have someone else join them on calls, someone from their team, and say, “This is a sales call, I’m going to be stressed, I want you to get on and be my wing person so we can do it.” Now, is it expensive, is it a bad use of resources? Maybe. But do you get better at it, and at a certain point not need them? Maybe.

The other thing I could imagine, if it’s really bad, is trying to get a therapist, a book, or a course on it. It depends on whether you learn from books and courses, I do, not everyone does, and I’ve definitely learned from therapists. If I had really bad social anxiety, I’d try to get to the root of it, I bet there’s a root cause, something like, “Oh, it’s from this childhood belief or experience that was really messed up, and this is how everything flows from that.” You can get over it through repetition and numbing yourself to it, in a good way, or through more pointed treatment.

That’s what I would say. Do you have any other thoughts to add?

Derrick Reimer: Yeah, that’s pretty much in line with where I was headed. I’m a naturally reserved, introverted person, so sales calls don’t come naturally to me. I get very in my head about it. If I think about where that anxiety comes from, oftentimes it’s fear of sounding stupid, or messing up, or saying something that ruins my chances of closing a deal. But a lot of that ultimately comes from lack of experience, and there’s a hesitancy to do it because of that lack of experience. Part of it is just getting started and forcing yourself to get the reps in, knowing it’s going to suck until you start to build confidence. The more confidence you build, the less anxiety you feel, because you’ve seen some things, you know how to deal with certain situations.

Specifically on the sales call front, something I’ve been doing, and I’m in general a little skeptical to offer this kind of advice, 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, which is often not what you need to hear. There’s still definitely a place for seeking real advice from a mental health professional for real issues of that nature. But specifically around coaching yourself, or figuring out how to improve sales call performance, I’ve found it super helpful to use a call recorder when I’m doing one, then feed it into Claude or your favorite agent of choice, and ask for objective feedback: what went well, what didn’t go well, what could I do better? They’re actually pretty good at identifying, “You spoke too much,” or “You didn’t speak enough,” or “You should have spent more time on this area.”

Just getting that contextualized advice or feedback about how the call went, when a lot of it is basically reflecting back things where, 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 this self-doubt wrapped up in it. Getting hyper-contextualized feedback has been super helpful for me in gaining confidence more quickly, I’d say.

Rob Walling: Yeah, that’s great, really good advice. Thanks for that question, hope it was helpful. Our last question of the day is from New Zealand.

Aaron (Listener): Hey Rob, Aaron here from New Zealand. Love the podcast. I’m in a trades business, and I’ve built a pretty awesome trade-specific CRM for myself. It started off as a takeoff and estimating tool, and it morphed into a pretty awesome CRM. My question is around trademarking. I think copyright, from a bit of research, is automatic, but a trademark is quite costly. I’ve got a pretty cool name for the CRM I’ve built, and I was wondering your thoughts on trademarking. Is it worth the big investment upfront, to do it now before somebody sees my pretty cool idea and tries to steal the name? Thanks, mate.

Rob Walling: All right, Derrick, there’s an interesting thing here. Number one, neither of us is a lawyer, so no one should take our legal advice, but we do have thoughts as multi-decade software entrepreneurs. The other interesting thing is, I went to Claude and asked about US trademark law and New Zealand trademark law, and they’re different. That’s a whole interesting thing. But I’ll ask, how many trademarks have you filed for your company names, product names?

Derrick Reimer: I think I’ve attempted to file one, and it got rejected, and I didn’t take it any further.

Rob Walling: Yep, I’ve had that happen a few times. Tried to trademark Drip, and it was like, nope, prior art, too generic, all that. We did get, I think, the trademark for MicroConf and Startups for the Rest of Us. But I’ve tried to file other trademarks and they’ve all gotten rejected. So, in general, here’s the thing: in the US, if you have a unique name, at least the way Claude describes it, you have kind of a use defense, in essence, that if you can prove you used it, and someone later tries to trademark it, you can swoop in, but it’s more expensive and a weaker case than if you’d just filed it. So the question is filing fees, I think in the US it’s $350, somewhere around there. If you use a lawyer, it tends to be one to two thousand dollars, 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, and so on. So the question is whether that’s worth it to you in the US. Now, in New Zealand, again, according to Claude, but I’m using Opus, Opus 5 high thinking, so I think it’s probably relatively accurate, it specifically said this isn’t legal advice, double-check everything, it said that in Claude. In New Zealand, that use defense doesn’t exist. It’s literally the first person who files, even if you’ve been using it in trade for years, someone else can come along and file it. Crazy, huh? I mean, that sounds not great. I like the idea of copyright by default, I don’t have to submit a book when I publish it, because I put “copyright, all rights reserved,” and that’s when it’s copyrighted.

Now, if I file it with the copyright office, or the PTO, the patent and trademark office, it’s a little better, definitely stronger, but that’s kind of brutal. To me, there’s more reason to file, honestly. In New Zealand, again, looking it up quickly, it looks like if you do it yourself it’s $150 to $200, and if you use a lawyer, it’s about the same, like $500 to $1,500. So I don’t know, that’s it, I can’t make a recommendation on this one, because it really comes down to risk tolerance. The odds of something happening are low, but if it does, that would suck. If someone else trademarked it in New Zealand and you just lost it like that, I’d maybe lean toward doing it, but I’d try to figure out, can I have an AI agent [VERIFY: “Manis” – possibly refers to the AI agent “Manus”] fill out the form?

Honestly, or can I have AI fill it out now that we’re at a place where, I don’t know if I need an attorney, I’ve never tried to do it without one, I’ve always just hired someone, thrown $500 to $1,000 at it, whatever. I’m wondering if it’s less expensive if you could get AI to do it. What do you think?

Derrick Reimer: Yeah, and I think, I’ve tried to use, I don’t know if it’s LegalZoom or Rocket Lawyer or something like that, where it’s kind of a, where you’re not really hiring a lawyer directly, it’s a legal service that gives you a template, and you fill the stuff in.

Rob Walling: Trademark Engine is one, yeah.

Derrick Reimer: Yeah. Maybe I got rejected in the past because I didn’t fill something in quite right. I feel like an LLM would probably have a better shot than me, since I definitely don’t have a lawyer here, at getting the stuff put in the right way, so the patent office likes it. So yeah, I think it’s worth a shot. These days, it’s easy to have the extreme lean-bootstrapper mindset of, “No, it’s not even worth $300 or whatever.” But especially with the reality of New Zealand, if that were true here, I think I’d be more apt to push for it.

Rob Walling: Me as well. And I get these questions, like, should I file an LLC or be a sole proprietorship, when do I do that, when do I form the company, sometimes it’s a liability thing, sometimes it’s, should I have E&O insurance and general liability, and all kinds of other insurance. And then there’s trademarks, copyright, and IP protection. If you talk to an attorney, they’ll tell you to do all of them ten steps before you even think you have a business, do all the things. The insurance person says do all the things too, because bad things can happen, and they’ve seen bad things happen. Those are all true, but you’re also an entrepreneur, and you don’t have much money, so don’t overdo this. That’s the balance we’re trying to strike here.

Cool. Well, Mr. Derrick Reimer, thanks so much for joining me on the show today. You’re Derrick Reimer on X/Twitter, and savvycal.com, if folks want to use the best scheduling and appointment booking tool on the internet, not just meetings, but appointments too. You do that now, right? So people know what appointments are, we’re talking medical offices, and who else schedules appointments?

Derrick Reimer: Lawyers. Yeah, we’ve actually been mostly focused on telemedicine, it’s 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, which is super slow and clunky and doesn’t resolve slots very well. SavvyCal can sit in between and unblock your sales funnel for new patients.

Rob Walling: Yeah, that makes a lot of sense. At first, when you told me meetings, which is what we all use SavvyCal for, and then appointments as a different thing, I was like, “Aren’t they the same?” And you’re like, “Oh, my sweet summer child, you have no idea.” Appointments are complicated, there are workflows involved, maybe multiple.

Derrick Reimer: Centralized management, office management, things like that. Yeah.

Rob Walling: Yeah, so that’s it. So, savvycal.com, if you want to check that out. Thanks again for coming on the show.

Derrick Reimer: Yeah, thanks for having me.

Rob Walling: Thanks again to Derrick 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. As I mentioned, this is episode 850, and sometimes I think, how did I get here? The way I got here was by recording every week since 2010, just showing up. I think that’s probably the way you build anything interesting, doing it over a long period of time, showing up every day, every week, every month, pushing the ball forward, whether you’re writing books, shipping software, shipping a podcast, or something else. Thanks for joining me this week and every week. This is Rob Walling, signing off from episode 850.