Episode 643 | Feature Flags, Impostor Syndrome, and More Listener Questions with Derrick Reimer

Rob Walling:
Welcome to another episode of Startups for the Rest of Us. I’m your host, Rob Walling, and today with Derrick Reimer I’m answering listener questions. We cover topics ranging from how to implement feature flags in your SaaS app, combating imposter syndrome, whether to use the Stair Step Method and more amazing listener questions from listeners just like you.
But before we do that, I want to let you know about MicroConf US next April 2023. Lianna Patch and I will be MC’ing. We have amazing speakers, Claire Suellentrop, Dev Basu, Patrick Campbell. We have workshops. It’s going to be great. It starts April 16th and runs through the 18th in downtown Denver, Colorado. Head to microconf.com/americas if you want to find out more and buy a ticket. Tickets are on sale now. They are going fast. I’d love to see you there. And with that, let’s dive into listener questions.
Derrick Reimer. You’re back on the show.

Derrick Reimer:
Thanks for having me back.

Rob Walling:
By popular demand, and we’re answering listener questions today.

Derrick Reimer:
Whoo hoo. Let’s do it.

Rob Walling:
What led to this is there’s a lot of listener questions all of a sudden, and I’m not exactly sure. I think it’s the YouTube channel ticking up and just more people getting interest, but a lot more questions than in the past. And the interesting thing is I started going through them and I’m like, “Got to answer the video and audio first.” The first question we’re about to answer, I was like, “Oh, I have thoughts on this, but who know who would answer this really well is Derrick.” And then the second one, I was like, “Oh, Derrick would actually probably answer this better than I would.” So then once I had two I was like, “Yeah, I can build a whole show around this,” so I pulled off several questions and we’re diving into them today.

Derrick Reimer:
Very nice. Yeah, I always enjoy these episodes because I think you always invite me to the board where you’re working on organizing your listener questions and I can see the ones in the Derrick column and there’s just enough volume so all of these, on the one hand sort of easy to answer because they’re things that you know I would have thoughts on, so that’s always fun.

Rob Walling:
Yeah, right in your wheelhouse. So we’ll kick off with our first question from Alan and we’ll roll that here.

Alan:
Hi, Rob. It’s Alan from APIable here. I have a question regarding SaaS products. So we currently only have one plan in our SaaS product and this means when a customer logs in, they get access to all of the features that are there, whereas we look to add a second and third plan to our product. I’m wondering if there’s any software out there that can help us to toggle features on and off, for example, to record which customers on which plan to upsell the customer to a new plan. I can, of course, ask my developers just to program all this stuff, but it’s probably going to take two, three weeks, something like that, so maybe we could do this quicker.

Rob Walling:
So just to be clear, he’s talking about adding plans and these are often we call them pricing tiers, but yeah, pricing plans. And he’s saying how can we toggle features based on plans and record which customers are on which plan? What do you think, sir? You may have done this once or twice, Derrick.

Derrick Reimer:
I’ve done this a number of times, yeah, so I mean I think thinking about structuring your billing engine in a sense and how your billing engine marries up with your SaaS product, my thinking on this has evolved over the years, but certain parts have stayed the same. So years ago before Stripe had a nice sophisticated subscription billing engine where they could track all your plans and all that kind of stuff, we used to build all that stuff in the app and you would own the [inaudible 00:03:40] job that hit the payments API and charged the customer and all that kind of stuff.

Rob Walling:
Those were the days.

Derrick Reimer:
Those were the days. Thankfully we’re beyond those. There’s Stripe subscriptions, or Stripe Billing, I think they call it. There’s Chargebee and Recurly. There’s a bunch of different products that have different strengths and weaknesses that you could delegate that out to.
So these days what I do is use Stripe Billing, keep it simple, put my plans there, and then there’s always a certain amount of state that I want synchronized with my local database. And thankfully Stripe has… I mean their API has definitely gotten bigger and more complicated over time, so that’s one thing to watch out for, but fundamentally they have web hooks that you can set up listeners for and listen for when a subscription activates on a new plan or if you’re using Stripe’s billing portal thing, which I’ve been making use of that with SavvyCal and it’s pretty elegant so I don’t have to write the code, that allows the customer to go in and change their plan level.

Rob Walling:
That’s what I was going to ask. So if I’m in SavvyCal and I go to change my plan level, is there an I frame embedded in SavvyCal or do I actually go to a stripe.com domain and that’s how I change it?

Derrick Reimer:
Yeah, it’s a full redirect. I think people have just gotten used to that enough, you know? Even when you’re buying something on a Shopify website, it kind of redirects from the fully designed thing over to a checkout flow that looks more stripy, looks more stripped down. So, yeah, I think these days using the customer portal is… I don’t hear any customers complaining about it or feeling weird about getting redirected to Stripe. And that has the interface for updating credit card, changing plan, adding their tax ID number, all that kind of stuff so it’s nice not to have to own any of that code.
And then when those changes happen, we receive a web hook from Stripe saying a change happened and there’s products and prices in Stripe. The product would be the basic plan and then prices, you might have one for your annual tier and your monthly tier, say, so I keep a mapping of those. Like basic plan and SavvyCal maps to this price ID and this interval maps to this product or whatever, and then when those changes come in, I just update the record in the database that maps that subscription and then you can use that anywhere you need to. Anywhere where it makes sense to sort of gate a feature, you can just check that flag without having to call out to Stripe.
That’s why you want some of this state synchronizing your database. I always aim for minimal amount of state synchronization so I don’t have their list of invoices, for example in my database because if I need to show them that, I can either send them to Stripe UI or make an API request, and it doesn’t matter if it’s slow, but for things like choosing to show a certain feature, you’re going to want that to be fast.

Rob Walling:
And so when you go, actually in your code, to show a feature or not, do you use any type of… I think of Rails having a RubyGem and there’s a bunch of them for feature toggling, right? And I’m sure Laravel has them and every framework probably has them. Do you do that or are you more hard coding where it’s like if this plan then blah, if that plan then blah?

Derrick Reimer:
Yeah, I have a mix of this honestly. So I have kind of one place in the code base where I can ask the question, does this user have access to this certain feature? And so I have one place where a lot of that logic lives that’s kind of explicitly tied to a plan. Sometimes you have a feature where it’s like normally this is on the premium plan only, but I want the ability to enable it for a particular user without moving them fully to the premium plan. And so for me, it’s always a case-by-case basis. It’s a judgment call when you’re architecting it, but if it’s going to be something that you might want to enable, then I usually opt for the pattern of having a flag on the user record that you can set explicitly so you’re not purely relying on the plan level that they’re on, if that makes sense.

Rob Walling:
Absolutely, because I remember we used to have, let’s say, beta or early access individual features with complicated features, especially in Drip where it’s like this one, it might have a bug or it might be a little janky but it’s a whole new UI or it’s a whole new something, and we wanted to test it out in our own accounts and then we’d get… You know, it was Brennan Dunn or Ruben Gamez, just like a Drip-friendly, friend of Drip, and we would say, “Do you want to check this out?” “Yep.” So we’d feature flag, so that’s how you were doing it at the time.

Derrick Reimer:
Yeah, and so for that, for pre-releasing a feature, currently I make use of a library for doing this. There’s one for Elixir Phoenix called Fun with Flags that is just a little subsystem where, and they even give me a little administrative UI that I put behind special authentication so that just us admins can go access that, and just say for this user ID enable this feature, or you could even do things with it like for 50% of users, enable this feature if you want to-

Rob Walling:
That’s cool.

Derrick Reimer:
… gradually roll something out.

Rob Walling:
Yeah, that’s neat.

Derrick Reimer:
It makes sure that it loads the flags in memory so that you’re not doing a bunch of database calls every time you want to ask the question of who can see this feature. And yeah, I make heavy, heavy use of this. I mean, part of our methodology when we start working on features, we break them up into small chunks and we’ll often start shipping little pieces of functionality into production from day one and set up the feature flags.
So usually that’s the first step is figuring out what flag this is going to be under and then anytime we’re passing a user object around, we have a little object of flags on there so we can just check it wherever we need to and, yeah, that helps us really push forward quickly on things and get it into prod and de-risk things.

Rob Walling:
Right, and that’s the big advantage of that approach, right? Because someone who’s been writing software for 20 years hears that and thinks, “Oh, my gosh, pushing stuff into prod that much. The QA and this and that,” but it’s like, “No, it’s 20 lines of code that I wrote today and I’m going to push it in and we have massive unit test coverage and so the odds of having a regression are not huge.” I remember feeling so good about launching big features back in the day. I’m assuming you feel that way in SavvyCal because it’s like, “No, this code, 90% of this code’s been in the app for three weeks, so it’s like nothing bad has happened,” right?

Derrick Reimer:
Yeah, totally.

Rob Walling:
It’s a real nice way to do it. So Alan, there you go. Maybe even more than you asked for. You were talking about plans, but we also talked about… I mean the whole idea of the Fun with Flags thing where you could roll it out to 10%, 20% or individual users, that is invaluable. And if you’ve never built a SaaS app as a developer or product person, you just don’t think about that stuff, but if you have downloadable software, if you have developer component, if you have an app in an app store, none of that…
I guess maybe an app in an app store would, but the others, it wouldn’t make a difference and so in SaaS specifically, this is where having experience building multiple products is so helpful. So thanks for the question Alan, I hope that was helpful for you. Our next question is from Wyatt and it’s about how to communicate product needs to a technical co-founder.

Wyatt:
Hey, Rob. I’m a non-technical founder that has a technical co-founder that I just brought on board. I’m the one on the team currently that has the industry knowledge necessary to understand our customer needs the best and most deeply. We have early product market fit with our current iteration with several thousand in MRR and we’re starting to build more complicated features that are really going to start to separate us from competitors. And these features I think will be critical to our success, not only from a product side but also leveraging these in our marketing.
I guess my question is how do you build/design/mock up product features where I know the customer best and what they’re going to want, and describing the product interface to my technical co-founder and how it should be laid out the best, is this something where you would draw on the back of a napkin and send to them? Mock something up in, I guess, it would be one of the more famous mock-up tools? I guess, how do I go zero to one best with my technical co-founder on how to start initial designs that end up getting built by him in the end, and kind of communicate that properly with him on what to build, how to build it it in the best way that I know our end user would want.
I’m kind of currently just doing this via our Slack communication or Zoom meetings and I feel like this cannot be the best way to do it because I’m sure he’s interpreting things that I’m saying by just the words coming out of my mouth essentially. There’s got to be a better way I feel like to communicate some of the product needs of our customer better. Longtime listener, first time caller. Appreciate any feedback you might have.

Rob Walling:
Derrick, you are a technical co-founder and also someone who has had to communicate product needs, oftentimes to designers, to developers, to your dummy co-founder over here when we were building Drip, no. How do you think about this question?

Derrick Reimer:
Yeah, so I think I would say generally I’m a fan of the low fidelity mock ups. I think Jason Fried talks about using a sharpie instead of a ballpoint pen as kind of a way to picture this so that way you don’t accidentally get more specific than you intended to. It kind of forces you to keep it more high level. I think there’s digital tools to do this, tools like Balsamiq and I don’t know what other tools are out there these days for-

Rob Walling:
Balsamiq and Figma are the two that I think of.

Derrick Reimer:
Okay, and Figma, I think, oftentimes becomes more high fidelity because you can do pixel perfect designs in there, but I bet you can probably also just do boxes and arrows and stuff. And that being said, I wouldn’t get too bogged down with tool choices in this case. To be honest, mostly if I need to do this, I’m sketching it on paper and taking a picture of it and pasting that picture in the ticket.

Rob Walling:
Remember all the whiteboard pictures?

Derrick Reimer:
Yeah.

Rob Walling:
I still have 20, 30, 40 whiteboard pictures of UIs that we would sketch out and they were terrible. I can’t draw on a damn whiteboard and so none of the lines are… But that’s what you’re saying. It didn’t matter. We used to meet, we’re like, “Well, let’s put a text box here and a dropdown list and then we need something blah, blah, blah here,” right?

Derrick Reimer:
Totally, and there’s one other thing I want to mention because I’m getting a sense from the question that he may have been experiencing some miscommunications with his co-founder because it sounds like whatever they’re doing right now, it’s breaking at times, it’s not working super well. And to me this feels like a case where for some of these complicated features he’s talking about where there’s a lot of nuance and information to communicate and voice of customer to bring in and try to capture it all, I don’t know if they’re mainly trying to do this over Slack or other project management tools, but this feels like a case where a shared whiteboarding session would serve them really well.
We had so many of these building Drip and you get to combine the strengths that you both bring to the table. I’m not sure who’s more of the designer between the two of them because a technical co-founder isn’t necessarily the best UX person on the team so it just depends on who has a better sense for those things, but I would bet you that if you put your heads together and hashed out things and got on the same page in front of a whiteboard, you’d save a lot of time over trying to do that over writing.
The alternative is go asynchronous and just write, write a lot and provide a lot of context, which I know teams like Basecamp are a big fan of that approach, and you write these giant documents where you try to brain dump everything you’re thinking into one place, which is cool for other people to be able to go back and read it so there’s some nice archival benefits to that, but I would say if you’re trying to move quickly and not get too bogged down, a synchronous in-person or virtual whiteboarding or however you want to do it, could be really helpful.

Rob Walling:
I would wholeheartedly agree with that, and I think to take it a step further, once you do that whiteboard session, you take a picture of it or you have your screenshot of it and you slap that into… We used GitHub Issues, but hopefully you have some type of project management or issue management thing that you’re working in, whether it’s Jira or what’s the one you use that’s really good looking?

Derrick Reimer:
Linear, yeah.

Rob Walling:
Linear.

Derrick Reimer:
The new hotness.

Rob Walling:
So certainly… Yeah, the new hotness. Any features, bugs that you’re thinking about should be individually documented, but when you’re this early, I think you should be extremely agile and fast moving, lowercase A on that agile, and you can have a conversation. It’s like, “Oh, we realize that customers want this setting and it requires two check boxes and a dropdown list.” I would log in to GitHub Issues, open an issue and I would say, “We’re going to add two check boxes and a dropdown list.” I mean this is what I’m typing, right?
It was like four sentences tops, and then sometimes if you were going to build it, it was done because you knew the architecture. If you were handing it to a developer who maybe didn’t know, you’d be like, “These are going to pipe into this model and go into this.” I’m using the wrong words, but this aspect of the ORM in Rails, but no, yeah, right? But you’re like, “It’s this database table, blah, blah, blah,” if someone needed the architectural or the technical side. But we would build features that were two sentences, eight sentences. When it got complicated, it was a couple of paragraphs and then a lot of visual.
The ones that were more complicated were workflows where we did this huge visual thing and even that was several pieces of 8.5″ by 11″ paper taped together on the wall.

Derrick Reimer:
I remember that [inaudible 00:17:05].

Rob Walling:
You totally remember this, and I’ll see if I can find a picture of it. It would be great for the show notes. But it was that and then I think we just talked about what each of the nodes did and tried to define them in a sentence or two. That was it. And I’ve been at places where, because I worked at a credit card company, I worked for the City of Pasadena, the specs for those things would’ve been 50 pages or a hundred pages for documentation, for reasons, but not reasons that I ever want to experience again. I don’t work in those environments because you just don’t need that much when it’s two people, three people, four people trying to move fast, trying to ship fast.

Derrick Reimer:
Yeah. I find these days when Taylor and I are talking about a somewhat complicated feature, a lot of times I write a couple of sentences in the initial ticket and then maybe a note that, “Let’s discuss this. Let’s hash it out.” A lot of times it’s a little different than I originally envisioned, so I’m glad I didn’t invest a ton of time describing my grand vision for it, only for a quick back and forth to modify that slightly.
And then what’s nice is a lot of times we’ll talk it over, and since Taylor’s going to build that part, he will then write the tickets for it and kind of summarize what we talked about. I think that that’s just a helpful device for him to confirm that he understands what we both arrived at and write it up and I’ll skim over that and if there’s something off then I’ll just note it and correct it. But that’s a great way to just confirm that are we truly on the same page before we start investing developer cycles into it?

Rob Walling:
That’s a really nice way to do it and collaborate and have the double check, and realize when we are talking about these tickets or this feature description, that there’s kind of three components to it in my mind. There’s the user interface, how it looks. There’s obviously the technical details behind it, and then there’s how it acts and operates, the behavior of it. And sometimes you don’t even need to describe the user interface. Sometimes there is no user interface. It’s just a change in behavior of a scheduling blah, blah, blah, background, whatever. Sometimes user interface is literally, “We’re going to add a text box. It’s going to be called first name.”
You don’t need to say, “Use these styles.” We all know what the styles are in our app. So the UI can be complicated with workflows where you and I talked a lot or it can be non-existent. The technical side can sometimes be obvious, sometimes not. “Oh, you’re going to add a field to the customer table to do this,” or it’s just obvious what we’re using. The behavior, that third one, I think, is the one that I would spend the most time thinking about, how we got to get that right, and that’s usually not obvious, I think. It’s often the most, I think, challenging piece to communicate in a way that I know that it should work this way or maybe I don’t. Maybe I haven’t thought of the edge cases.
That would be the other thing is I’d throw a ticket in. You’d come back and you’d be like, “If we do this, we’re going to break everyone’s unsubscribed links or 10% of the unsubscribed links.” It’s like, “Oh, I hadn’t even thought about that,” so we change the behavior to not do that.

Derrick Reimer:
Yeah, I mean that’s ultimately the most important. I think that when you call that user experience where it’s like it’s not user interface design necessarily. That’s a part of it, but what’s the journey of the user? What problem are we trying to solve? And thinking about it a little more high level and then the details sort of take care of themselves. If it’s something that requires a lot of intricate UI design and the developer is not that great at interface design, then maybe that’s the point you loop in a designer to take care of the visual aspects of it. But all of that is sort of downstream from making sure you’re on the same page about the overall journey. What’s the problem we’re solving at a high level.

Rob Walling:
So thanks for the question, Wyatt. I hope that was helpful. Our next question comes from Bavesh and he’s discovered the Stair Step Method of bootstrapping and he’s asking, should I put my main SaaS on the back burner?
Our sponsor this week is lemon.io. Imagine you have an idea that just might change your corner of the world, but you don’t have the engineers that you need to bring it to reality. It’s hard to find great engineers quickly, especially if you’re trying to reduce your burn rate, unless you have a partner who can provide you with more than 1,000 on demand developers, vetted, senior, result-oriented and unstoppably passionate about helping you grow, all that at competitive rates. Sounds too good to be true? Meet lemon.io.
Startups choose lemon.io because they only offer handpicked developers with three or more years of experience and strong proven portfolios. Only 1% of candidates who apply get in so you can be sure they offer only high quality talent, and if something goes wrong, lemon.io offers you a swift replacement so you are essentially hiring with a warranty. To learn more, go to lemon.io/startups and find your perfect developer or entire tech team in 48 hours or less.
And if you start the process now, you can claim a special discount exclusively for podcast listeners. 15% off the first four weeks of working with your new software developer. Stop burning money. Hire developers smarter. Visit lemon.io/startups.

Bhavesh:
Hi, Rob. Just got a question. I’ve seen your new video on YouTube titled, If I Had to Start Over Here’s the Three Steps I’d Take to One Million.” Now I’ve got a question or kind of a dilemma. I’ve been working on a SaaS project for a couple of months now. I’ve been doing interviews and customer research. I’ve been able to lock down the research and their pains through interviews, polls and everything. I’m now working on a [inaudible 00:22:31] for the solution that I’m going to present to them.
Following the video, I’m a bit slightly lost. Would you suggest I start with a smaller project, say a WordPress plugin or Shopify plugin, rather than continue with the main SaaS project to get my feet wet before I should plow through the main SaaS project? So let’s say the WordPress plugin, I’m estimating five to six months activity, whereas the main SaaS project would be another one to two years to go. What’s your thoughts of this, because I’m a bit lost as to taking your advice in the current situation that I am in with what I should be doing? Thanks, Rob.

Rob Walling:
Well, Mr. Reimer, this is a tough one, right? There’s no right answers on this one, but what’s your thinking? How would you go about thinking this through?

Derrick Reimer:
Yeah, so first off, it sounds like he’s doing the right things to set himself up for success as best possible. I hear he’s doing research, doing interviews, talking to people. Those are all great things. The one thing that’s not totally clear to me, because he’s mentioning maybe stepping back and working on a WordPress plugin or a Shopify plugin or something like that and I don’t know fully if he’s implying that these would be scaled back versions of the SaaS that he’s working on or if it’s just kind of a hypothetical alternative path he could take.
And I think the answer would kind of vary because in general I would say… Another thing that jumped out to me was he mentioned a one to two year timeline on building the SaaS, the main SaaS, and to me there’s a red flag because that’s a really, really long time. I think in this phase you want to be optimizing for learning and the trap that you could easily fall into as a builder is doing what you do best, building product, and not actually learning a bunch from the market or figuring out, “Am I on the right track? Is this going to work?”
This is kind of the age old problem that plagues us so often and I think that’s the biggest risk with working on a SaaS where if he feels pretty confident it’s going to take that long, then I would seriously think about either trying to cut scope to shorten that or just think a little bit differently about the process for developing the SaaS. Or potentially if these plugin ideas are speaking to the same market, the same idea generally that he has, but they’re a little bit more scaled back and easier to get to market quickly, then I think that would be something really interesting to think about doing to validate.

Rob Walling:
I’m not sure how much I have to add to your analysis, honestly. I feel the same way about it. These are hard decisions, really incomplete information, but when I saw one to two years I was like, “No, no, don’t do that. No matter if you’re talking to customers or not, it’s just too long.” By the time you’re a year in, it’s just a slog. You have to have some type of traction by that point, whether it’s customers using it, some money coming in. I’m not saying it needs to be 10K a month, but it just pains me to think of someone working probably nights and weekends, I might be guessing. Certainly you wouldn’t do one to two years full-time. That’s a lot of person hours before you get something into the wild.

Derrick Reimer:
That’s my assumption too is that this would be probably something on the side, and I do sometimes hear founders talk about being okay with it taking a long time because it’s just a side project. But I think something that’s really important to think about is your own motivation for the idea. There’s an element to trying to build some traction in the market even before you launch the thing. Hopefully you’re building an email list and these conversations that you had, you want to be able to follow up pretty quickly with something, at least some form of progress to keep the people that you’ve talked to interested in the idea.
And all of that’s going to wane a bit if you’re just slowly plotting along, making progress on the side, and I would bet that your own motivation for it would wane as well. And then what have you learned from that process? I mean, maybe you’ve learned some new technology or something if you’re experimenting with that while building, but have you gotten closer to making progress on the stair step and ultimately becoming independent, if that’s your goal? And so I think that’s an important thing to keep in mind.
It’s one thing if you just want to build something on the side and you’re just interested in doing that in its own right, then that’s cool, but you need to make sure. If you want to be making progress on building skills to bring products to market, then you’re probably going to want a tighter feedback loop.

Rob Walling:
To piggyback on what you just said, funded startups fail when they run out of money. Bootstrap startups fail when the founder runs out of motivation, and that’s what you’re saying is you grind for six to 12 and you start losing. Let’s say if you were to launch after 18 months, that’s the starting line. You’re in a hundred meter dash and that’s like you’re 10 meters in, so how do you then have the years it takes to grow that to replace your full-time income?
I think, in summary, if you were to just say, “Rob, if you were in Bavesh’s shoes today and you didn’t have any network, any audience, any funding, you couldn’t self fund and you haven’t had a success, you’ve never really launched anything, what would I do?” That’s how I like to think about these things. I would not spend two years on a SaaS app, and you said scale it back, which I think is interesting, or I would look at a more step one business. That is what I would do. Yeah, even though I’m a few months in, there’s a sunk cost fallacy there where you potentially are going to throw good time after bad.
But I want to be clear, Bavesh. I’m not telling you what you should do. I’m telling you what I would do in my shoes, knowing what I know, because these are hard decisions. The information’s obviously very incomplete and each of us has to make those for ourselves. So thanks for that question, Bavesh. I hope it was helpful. Our next question is from Matt about developer imposter syndrome.

Matt:
Hi, Rob. Matt here in the UK. I was just wondering if you’ve got any advice for any developers like me who are struggling to get past a mental barrier of not thinking that anything we develop is going to be worth other people paying for?

Rob Walling:
What do you think, Derrick? I’m curious if you ever felt this. Do you remember ever having this type… Because look, we’ve all had imposter syndrome. Let’s be clear. But this particular one where I think no one will pay for something that I’m building.

Derrick Reimer:
Yeah, I do think it’s curious the way he worded it. I was trying to think of the same thing, can I relate to this feeling? Because for me, I think, if there’s one area that I’m confident in as a developer, it’s my ability to build a product and take some pain point and solve it with software. And I think Matt should probably feel confident in that as well. This is our craft, this is what we do, this is what we’re good at, and I have zero doubts that he could build something that is worth paying for that solves a pain for a customer.
I think the bigger thing to be worried about, not to potentially add to the list of things you might be stressed about, but the bigger risk us builders have is skimping on the other side of it. It’s all the things outside of building the product. It’s figuring out how to talk to customers and how to reach them and how to position it in a way that people want to buy it. That’s where things get trickier.
And so I think certainly I experienced that, a ton of imposter syndrome around am I actually capable of being an entrepreneur in the full sense of taking something to market and selling it and putting a salesperson hat on when I need to and putting a marketer hat on when I need to? Those are all skills that are pretty far outside of the builder-developer skillset that, I think, a lot of us developers take pride in honing.
I guess if I had a word of encouragement, it’s try to foster that growth mindset. Recognize that these are all just skill sets, they’re learnable, there’s a lot out there, so there’s a lot of things to study, there’s podcasts to listen to, there’s books to read, but a lot of your best learning’s going to come from doing and so that’s the other thing. It’s like, well what’s the most effective way to get past feeling like I can’t do it is by proving to yourself that you can.
And I think that’s the power of the stair step approach is getting small wins to validate to yourself that like, “Oh, I actually can do these things,” and, yeah, it’s really difficult to build a SaaS app out of the gate and have all of those hundred variables that you have to get dialed in just right. Getting them all dialed in right out of the gate is incredibly difficult, and so that’s where there’s a lot of value in gradually building up your skillset and convincing yourself that, “No, I can do this,” and I’m confident that anyone who puts their mind to it can.

Rob Walling:
I am, as well. I mean at bootstrapping especially, it’s just such a great equalizer. It’s such a platform that does the tool solve a problem that’s worth paying for? Then people will pay for it and they usually don’t care who you are in most cases. They don’t care where you’re from and they don’t care about your background. They just care that this tool solves this problem, and so I love the advice you’ve given, Matt. I think the thing that I would add to it is it sounds like it is maybe a deeper…
I say this as someone with experience of this, of maybe a lack of self-confidence. And I remember feeling, especially in my twenties, feeling very, “I don’t know if I can do this stuff. I don’t know if I’m cut out for…” insert anything. Insert anything entrepreneurial because I didn’t know any entrepreneurs, none in my family. The only business owner I knew was the guy my dad worked for. There was just no history there of this is possible. Especially hadn’t seen it in software, especially hadn’t seen it in anything except Silicon Valley raising funding because I grew up in the East Bay Area.
And so it took me some, I’ll say, personal work working through that on my own. I went to therapy about a bunch of stuff, but that was one of the things. Was like, “Am I cut out to do this?” And you’ll find out you have a lot, all of us have limiting beliefs based on our upbringing. Upbringing or there’s a bunch of different reasons why these things happen, but they’re complete blindsides that you just don’t see, and this one feels like that to me.
And so whether it’s a therapist or whether it’s a mastermind group or a co-founder or just someone who’s in your corner and willing to think this through with you, I think that’s what worked for me. I’ll put it that way. And it wasn’t Sherry, it wasn’t my wife who helped me get through this. It was a third party, even though my wife is a psychologist. The irony runs deep, but that’s not what helped me. It was having some successes along the way as I stair stepped up. I think that’s our third shout out to it but, no, it was little things where I was like, “Oh, [inaudible 00:33:10] voice. Oh, now I’m making $900 a month on this little downloadable invoicing software.” That was what convinced me that I could build something people were willing to pay for because they paid me for it and then that proved it and I was like, “Oh, well if it could be $900, it could probably be 9,000, couldn’t it?”
And then the first dollar you make online is amazing, and then you figure out how do you make $2 and then how do you make$ 2,000? The other thing I would say, Matt, is if you’re not in a mastermind group, that was another game changer for me, both the mastermind with you, Derrick, and Phil back in Fresno, and then another mastermind with Ruben and another person that’s been remote for years and years. Those were less about building up my confidence because actually by time we were in masterminds, I was doing stuff and I was pretty confident I could do it, but you have ups and downs even then.
Whether it’s a lack of self confidence or latent belief that people aren’t going to buy it, it’s going to rear its head in different ways month to month, quarter to quarter, year to year. That’s going to come back. You’re never going to be through it. And so having folks around you who are in it for long term with you who can help identify that and as you talk through it, be like, “You know what, man? I’m going to call you. That’s bull (beep). That’s actually not true. That’s this other voice talking. That voice is not welcome here, because it’s just not helpful.”
And so I think having a person or a couple of people in your corner who can help sanity check… We all have thoughts and I’ve gotten better at it. I think everyone does, but you get better at identifying, “Huh, that thought today is because I’m really tired or I’m really depressed because there hasn’t been sunlight for five days and that thought about this not working or me not being good enough is really an external factor, so don’t believe it today. But if I feel this in a month, maybe that’s true.” And so I give myself time and space to have these negative thoughts and not dwell on them, and if they keep coming back, then I figure out other ways to handle them.

Derrick Reimer:
Yeah, the community piece is really important because we pour so much of ourselves into our endeavors, especially when you’re kind of staking your career on it, it feels like at times. So it takes a lot of emotional energy for sure, and when something doesn’t work, it’s so easy to come to the conclusion that, “I’m just not good enough or not capable,” when a lot of times the answer is maybe there are some things outside of your control that affected that, or maybe there was a tactical error or maybe there’s just something you haven’t thought about, some playbook that you could try running.
There’s usually other ways to problem solve and it’s basically never that I’m a fundamentally flawed person, incapable of getting past it. It’s just you need other people in your corner who can have a different perspective and help assure you that it’s just something to work through. It’s not that you’re incapable.

Rob Walling:
And if you never have these thoughts, then you’re a robot.

Derrick Reimer:
Right, yep.

Rob Walling:
Right? I mean, everyone I know who I like as a human being has these thoughts. There are probably people that are so confident in themselves, it’s called narcissism, where you never have these doubts and I don’t hang out with those kind of people. I’ve met them and they are hard to be around because they’re just so in their own world. Derrick Reimer, you are @DerrickReimer on Twitter. Are you still on Twitter?

Derrick Reimer:
I am still on Twitter these days, yeah. It’s getting to be an interesting place but, yeah.

Rob Walling:
That’s a question we have to ask, yeah. Thanks so much, man. Thanks for taking the time to come on the show. I’m sure the audience really appreciates your insights.

Derrick Reimer:
It was a blast, as always. Thanks for having me.

Rob Walling:
Thanks again to Derrick for joining me today and thank you for joining me this week and every week as we dive into topics for ambitious, bootstrapped and mostly bootstrapped SaaS founders about building, launching and growing startups. I hope the new year has been amazing for you so far. This is Rob Walling signing off from Episode 643.
Do you not use Chrome anymore?

Derrick Reimer:
I use Firefox. I’ve just used it as my [inaudible 00:38:00] couple of years.

Rob Walling:
Did you always use Firefox?

Derrick Reimer:
I think I started four years ago or something, yeah.

Rob Walling:
Okay, what made you switch?

Derrick Reimer:
Honestly, it was at one point there was an update, a Mac update that broke font rendering. It made the letter spacing all tight and I think it was a bug that got fixed. It took two months or something for it to get fixed, but it was messing with my… When I’m paying attention to pixels so closely, it really messes with my design stuff.

Rob Walling:
Yeah, that’s interesting. So if Apple wanted to totally screw Chrome’s market share, they could just do that every couple of months accidentally.

Derrick Reimer:
Yeah.

Rob Walling:
What a trip. Hadn’t even thought about it, but only for really picky UI people.

Derrick Reimer:
Right, right.

Rob Walling:
Because I didn’t notice.

Derrick Reimer:
Probably most people didn’t notice. Well, maybe it was early stages of SavvyCal. I can’t remember which app it was where I was really getting core patterns built out and paying a lot of attention to the spacing of tool bars, nav bars and it all looked extremely jacked up, so I was like…

Rob Walling:
Cracked it. Yeah, that makes it tough.

Derrick Reimer:
And then Firefox, it’s been actually nice. The UI used to be kind of ugly and it’s gotten much more chrome-like and they have syncing between phone and desktop. They’ve caught up on a lot of stuff, yeah.

Rob Walling:
That’s the big thing for me. Yeah, that’s cool. All the bookmarks I have, and I remember years ago when you have to transfer them manually to export and then import. I mean, I know they have all my (beep) data because I have to log in, but I don’t care. It’s so much better when I get on a new machine. I’m like brand new Mac, I install a few apps, I log into Dropbox, I log into Google Chrome and it’s not much [inaudible 00:39:44]. It’s like, “Oh, I got to get my ftp.” I have four or five SFTP things I got to move over, but compared to the old days when I’d spend eight or 10 hours, literally a full workday, just getting a machine set up.

Derrick Reimer:
I know, I know.

Rob Walling:
It’s so nice.

Derrick Reimer:
Yeah, now these days I’m relying almost exclusively on all the Apple migration stuff that’s built in. Like just do it for me, and it generally works out fine. The one thing I didn’t do, I just upgraded my phone finally and forgot that Google Authenticator doesn’t transfer over.

Rob Walling:
Yeah, that is rough. And you know what, dude? I actually switched away from Google Authenticator to LastPass Authenticator because of that, because it does, and I don’t know who… Some of them do and some don’t. I don’t care which you do, but pick one that does because that happened to me once.

Derrick Reimer:
1Password has more and more support for one time password stuff, and it’s magical when it automatically inserts the one-time password. So I have a few… Obviously some Google accounts and stuff were in there and I’m banking on being able to use the recovery codes when I need to.

Rob Walling:
When you need them. Ah, that’s such a bummer. That’s surprising that Google is doing that, A, and B, there are just still a few edge cases in this whole get a new phone, get a new laptop thing, and I don’t think you can get them back once you lose it.

Derrick Reimer:
No, I don’t think so. I mean, it must be baked in, intertwined with the fingerprint of the device or something. There’s something about it that just will not transfer, but Apple doesn’t warn you about that. They’re like, “Cool, you got a new phone? You want us to migrate all the stuff over?”” Yeah, let’s do it.” And then it finishes and it’s like, “We’re done. Should we wipe this?” And I’m like, “Yeah, wipe it, man.”

Rob Walling:
Of course.

Derrick Reimer:
“Do it.”

Rob Walling:
That’s terrible. Such a bummer.