# Do B2B SaaS Founders Need to Be Good Developers? 👨‍💻

Channel: Rob Walling
Video: https://www.youtube.com/watch?v=NZ_x5zDWUMQ
Duration: 8 min
Language: English
Words: 1725
Transcript page: https://viewrankai.com/tools/youtube-transcript/NZ_x5zDWUMQ

---

[0:00] The most learning I've ever done, the fastest I've done it in terms of being a developer, is once I started doing it 40 or 50 hours a week for someone else. Hey, this is Rob Walling. Today, I wanted to answer a question from our community. I brought in my friend Ruben Gamez, he's the founder of Bidsketch and Signwell, to get his input as well. If you have any questions you'd like to ask, drop them in the comments and we'll see about answering them in a future video or maybe a live stream. And with

[0:23] that, let's dive in. Hey Rob, my question is, what level of expertise would you say the founders of a B2B SaaS should have in order to create a successful product? Would you say that they need to be senior developers or would you say even if you're a beginner and as long as you know how to get by, you should start and there's a chance you might get somewhere. I just want to know what your

[0:43] thoughts are on this. So, I like this question. I think oftentimes we get the do I need to be a developer or not and it's a very binary way, but Hayburn I think is asking how much of a developer do I need to be? And I want to be clear, I don't think he's asking do I need to be a developer to start a SaaS? I think specifically he's asking how good of a developer do I need to be to code, to actually build the

[1:05] SaaS. What are your thoughts? It really depends on the complexity of the of the app. It's hard to generalize when it comes to something like this because you could have SaaS products that are relatively simple, more CRUD-like, even certain parts might be people-powered so that there's really nothing complicated to build out and those I think who's just starting out with development that has a few months of experience that could do some of the

[1:27] basics would be able to build that out. The problem is it's just not going to be good code, it'll probably have to be rewritten at a later time, even the more simple version of it. It gets tricky when we're talking about something that's complex. Not only potentially could there be some really bad bugs and things like that, but it can drag on for a very long time, way longer than you expect, especially if you don't have experience like estimating projects and

[1:51] how long something will take to build. Everyone, even very experienced developers, think things will take way less time than they actually uh take. Somebody who's looking to do that would probably consider at least hiring, it could just be somebody to help mentor them or, you know, coach them on some of the more complicated parts, outsource like the more difficult parts. It doesn't have to be all one way or the

[2:13] other. Yeah, I like that take on it. My first thought when I read this was HitTail, the SaaS app I had before Drip, it was kind of just one feature with a bunch of tables. And, you know, it there were some scaling issues cuz it was it had a JavaScript tag, right? And so, it would it would send a request back every time you got a search engine hit. But, realistically, you could have hacked it together. In fact, it was hacked

[2:34] together. The code base was a not great. It was classic ASP, and it was a spaghetti mess when I acquired it. And we then we rewrote it in Ruby on Rails, but that complexity, I think you could pull it off. But, then to build Drip, you know, this which is exactly what you're saying is like simple versus not simple, right? And the cost of building an app and getting some traction and then running into performance problems that are literally unsolvable without a complete rewrite of a at least of a section of your code, it's pretty easy to do. If you really don't, you know, you don't have the experience as a

[3:04] developer. As soon as you get into anything that needs to be performant, you just don't think about queues and being async and threading. I mean, there's just these advanced topics that it's years in that you really get your head around these. I think low-code is super interesting these days, right? Where you learn enough JavaScript that you can get take Bubble or an Airtable and a Zapier, and you kind of tie together. And you can write some JavaScript when you hit the edge of that platform where it doesn't, you know, Airtable or or Bubble kind of lets you down, and you can drop into the code and

[3:33] do it. No-code and low-code don't scale that well anyways. You know, I mean, that is one of the drawbacks to them is they don't scale like true production SaaS code. And so, if you can find something to build that you can do in no- or low-code, I think that's interesting. Or, coming back to the stairstep, like a step-one app where you build for, you know, the HubSpot Salesforce marketplace, you build for

[3:53] the Zendesk or Help Scout marketplace. Or you build for Heroku or Atlassian or Cloud Flare or Digital Ocean. There's a whole list of these. We'll link it up. rocketgems.com. Remi who runs Rocket Gems, he is a fan of the stair-step approach and he put together a list of 68 B2B SaaS marketplaces with opportunities for indie hackers. For there to be 68 of them is is pretty intriguing. And I think building in a marketplace like that is a lot simpler. You I don't think your code has to be nearly as complex cuz you're building like an add-on to Shopify or an

[4:22] add-on to Freshdesk to allow a piece. It's not a full-blown SaaS app. Do you agree with that? Generally, I would agree with that. It depends, right? We we know really complicated ones. But I kind of like that guideline as doing that and looking into something that you could build with no code maybe most of the way and then

[4:40] using code toward the rest of the stuff. The other thing that I was thinking about is if they don't have experience, how likely are they to know that something is complicated to build or not. That would be probably really hard. When you and I say complicated versus not, how do you even judge that if you have never built a production app, right? And this is where I had this idea or just this thought of like working for other companies and working for whether it's startups or big companies, I think that experience is so valuable. Not just as a dev, but becoming hiring learning to hire people. Like I didn't learn to

[5:12] hire people when I was running my own startup. By the time I was there, I had already been part of 30 or 40 people's hiring process where I whether I was the manager or a technical interviewer or something you're doing phone interviews. I did like a hundred phone interviews, phone screens. More than that actually over the course of two and a two years at this one job. So by the time I went to hire my first dev, I at least had that experience. And similarly, by the time I went to write my first line of production code that I owned, I had been doing it for several years. And I think

[5:39] there's a trade-off. I wished I didn't have to do those things because I didn't like working for other people, but I did come into it with certain skills that I learned during the day job and I think that's applicable here. Is there an opportunity? I know, you know, Heybert that you don't want to go out and and

[5:53] get a day job, but it is interesting. The most learning I've ever done, the fastest I've done it in terms of being a developer is once I started doing it 40 or 50 hours a week for someone else. It is very different. Before I got a job as a developer, I was doing projects on the side for myself, for people, like that was okay, but I didn't learn nearly as much as when I actually had my first development job and had to work based off of other people's real world

[6:19] business requirements. And it's a trip. You know, it's it's weird to be on a startup podcast and tell someone to get a day job. And I'm just honestly, I'm just presenting it as one option. Cuz you and I both did it at our day jobs and that's one reason that we could do it. But then we have a tons of examples of folks who never did it at

[6:32] a day job and are still really good. Derrick Reimer is a good example, right? He never had a job coding. I mean, well, his job coding was when I hired him to do contract work on Hit Tail and then hired him to do contract work on Drip, but he already had the skill set that he had self-taught. So, you can totally self-teach this as well. I do like the idea that you talked about like hiring a more senior dev to mentor you and to look through your code, whether you pair program or whether they look through your commits and they tell you what sucks about what you're doing. I think

[6:56] that could be amazing, you know, I think you can make a lot of progress doing And not expensive compared to yeah, hiring somebody to build it entirely for you. That's right. So, awesome. Yeah, that was a good question. And we've received related questions, but not exactly like that in the past. So, thanks for the question, Heybert. I hope that was helpful. I hope you enjoyed that. As a reminder, if you have any questions that you would like to see me answer on video or live stream, please leave them in the

[7:19] comments below. Thanks for watching.

---

About this transcript
Read from YouTube's own caption track and laid out by ViewRank AI (https://viewrankai.com).
ViewRank AI finds the videos already beating a creator's own average on Instagram, TikTok and YouTube Shorts, transcribes them from the audio itself in more than 60 languages, and turns what worked into new ideas and scripts.
Free transcript tools, no account needed: https://viewrankai.com/tools
How to read any video this way: https://viewrankai.com/llms.txt