Episode 605 | Building a SaaS with Little Dev Experience, Using No Code for Your MVP, Bootstrapping a Two-Sided Marketplace, and More Listener Questions

Rob: Today on Startups For the Rest of Us, we dig into listener questions. We discuss building a SaaS with little development experience using no code for your MVP productized services, stair-stepping, and bootstrapping a two-sided marketplace. Really, questions ran the gamut.

There are some great questions today that Ruben Gamez and I cover. You know Ruben as the founder of signwell.com and @earthlingworks on Twitter. I really appreciate him joining me today.

Before we dive into those questions, Steve from Skills DB Pro sent in a video ask. He went to startupsfortherestofus.com. He clicked ask-a-question at the top. He didn’t ask a question this time. He said they do a lot of enterprise sales and he wanted to offer some thoughts and ideas that haven’t been covered on the podcast, but that have helped him and his team scale his company. We’ll roll that here.

Steve: Hey, Rob. Steve from Skills DB Pro coming to you from Bozeman, Montana, a long term listener. I appreciate all your help. I started my business by accident and I think I would be totally lost without you. 

I’m going to talk a little bit about selling to the enterprise. It seems to be a big subject on your podcast. It’s something that we do a lot of, so I have a fair amount of experience with it. We have different approaches to it than you’ve mentioned it in your show before, so I thought I’d share them quickly.

First, what we do is when we’re selling to the enterprise, we keep our dollar-a-seat SaaS model. But then what will happen is, for example, we took on a brand new client in one of the states, who I’m not going to mention their name, but it’s a thousand users. It’s only a $1000 month contract, but what we did is that we added an additional $18,000 or an additional $3000 a month of Project Support Services at the beginning.

It’s an amazing sale because they go, oh, it’s so cheap. It’s only $1 ahead. But then they’ll go ahead and pay the $3000 a month because it’s a separate line item for Project Support Services. It’s such an easy sell because all you have to do is say, well, do you really have time to do this? Almost always, they’ll be like, yeah, we can really use that help.

Inevitably, they almost always renew that service. That service is a very, very high margin item for us. I wanted to throw out the Project Support Services. We keep our SaaS prices lower, but we get a lot of that enterprise-level stuff for all the things that are enterprise. I don’t have time to go through it here.

The other thing that will happen a lot of times is they still ask for custom programming. We always charge for that and we call it expedited updates. If they’re not willing to pay $5000 for an expedited update, they really don’t want it. Anyway, I got four seconds left. Hope you find it helpful. If you want to know the information, reach out.

Rob: Thanks for those tips, Steve. I love the naming most of all, Project Support Services and expedited updates. I think it’s a mental shift like when I went from calling things betas to calling them early access. Having that naming is and can be important, so I appreciate you writing in.

If you have a tip for listeners of the show that you feel like have never been covered, feel free to go to startupsfortherestofus.com. Click that ask-a-question and send in a video or audio snippet. We can pass it along to the listener base. With that, let’s dive into listener questions.

Ruben Gamez, thanks for joining me on the show again.

Ruben: Thanks. Thanks for inviting me.

Rob: Yeah, it’s always good to have you. Folks know you as the founder of SignWell and Bidsketch. You’ve been on the show many times talking about plateaus, talking about rules of thumb in terms of trial to paid, funnel metrics, and of course, answering listener questions. Are you ready to dive into our first one?

Ruben: Yup, let’s do it.

Rob: All right. This first one is from Haibert at simplyrem.com. It is a video question. I should mention, if folks send audio or video questions, they can record yourself on your phone, send me a Dropbox link or a Google Drive link questions at startupsfortherestofus.com or you can go directly to Startups For the Rest of Us. There’s an ask-a-question link in the top nav and then you can just record yourself right on the website on your phone or on your computer.

Those go to the top of the stack. If you send in-text questions, we always get to those as well. They just have slightly lower priority, but Haibert sent in-video questions. We will roll that now.

Haibert: Hey, Rob. My question is, what level of expertise would you say the founders of 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 thoughts are on this.

Rob: I like this question. I think, oftentimes, we get the, do I need to be a developer or not? It’s a very binary way, but Haibert, I think, is asking, how much of a developer do I need to be? I want to be clear, I don’t think he’s asking, do I need to be a developer to start a SaaS or to be a founder? We know a bunch of founders, Craig Hewitt and other non-technical founders we could insert here. Jordan Gall and there are several.

I don’t think we answer, do you need to be a developer in order 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 SaaS? What are your thoughts?

Ruben: It really depends on the complexity 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.

Anyone who’s just starting out with development that has a few months of experience that could do some of the basics would be able to build that out. The problem is, it’s just not going to be good code or probably have to be rewritten at a later time, even the more simple version of it. If it’s the first product that somebody’s building out the first thing, it’s just not going to be very good.

I think it gets tricky when we’re talking about something that’s complex. I think the tough part is that 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 how long something will take to build. Everyone, even very experienced developers think things will take way less time than they actually take. I think there’s real danger there.

Somebody who’s looking to do that should probably consider at least hiring, if they can afford a full time dev or part time dev, it could just be somebody to help mentor them, or coach them on some of the more complicated parts, or outsource the more difficult parts. It doesn’t have to be all one way or the other. That’s what I would say.

Rob: Yeah, I like that take on it. My first thought when I read this was, HitTail, the SaaS app I had before Drip, was kind of just one feature with a bunch of tables. There were some scaling issues because it had a JavaScript tag, so 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 together. The codebase was not great. It was classic ASP and it was a spaghetti mess when I acquired it. Then we rewrote it in Ruby on Rails. That complexity, I think he could pull it off. But then to build Drip, which is exactly what you’re saying, is like simple versus not simple.

The cost of building an app, getting some traction, and then running into performance problems that are literally unsolvable without a complete rewrite of at least a section of your code is pretty easy to do. If you don’t have the experience as a developer, as soon as you get into anything that needs to be performed, you just don’t think about queues, being async, and threading. There are just these advanced topics that it’s years in that you really get your head around these.

We have a couple of questions later about no code. I think low code is super interesting these days, where you learn enough JavaScript that you can take Bubble or Airtable and Zapier, and you kind of time together. You can write some JavaScript when you hit the edge of that platform where Airtable or Bubble kind of lets you down and you can drop into the code and do it.

I think that’s super interesting because then, no code and low code don’t scale that well anyway. One of the drawbacks to them is they don’t scale through production SaaS code. If you can find something to build that you can do and no or low code, I think that’s interesting.

Coming back to the stair-step, a step one app, where you build for the HubSpot Salesforce marketplace, you build for the Zendesk or HelpScout marketplace, you build for Heroku, Atlassian, Cloudflare, or DigitalOcean. There’s a whole list of these. We’ll link it up. It’s at rocketgems.com.

Ramy, who runs Rocketgems, is a fan of the stair-step approach. He put together a list of 68 B2B SaaS marketplaces with opportunities for indie hackers. I didn’t even know 68 existed. You have always heard me say my top five. I’m always like, it’s WordPress, Heroku, or Shopify. There are two others that I sometimes read out.

For there to be 68 of them is pretty intriguing. I think building in a marketplace like that is a lot simpler. I don’t think your code has to be nearly as complex because you’re building an add-on to Shopify or an add-on to Freshdesk to allow a piece. It’s not a full-blown SaaS app. Do you agree with that?

Ruben: Yeah. Generally, I would agree with that. It depends. We know really complicated ones. I like that guideline as doing that and looking into something that you can build with no code maybe most of the way and then using code for 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?

Rob: Right. When you and I say complicated versus not, how do you even judge that if you have never built a production app? In a future solo episode, I had this idea or just this thought of 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 learning to hire people.

I didn’t learn to 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, whether I was the manager, a technical interviewer, or you were doing phone interviews. I did like 100 phone interviews, phone screens, more than that, actually, over the course of two years at this one job.

I was like a tech lead there. I liked doing it. It was 15 minutes. I would ask people to try to dig in other stuff. By the time I went to hire my first contract dev as an entrepreneur, I at least had that experience. 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 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. I think that’s applicable here. Is there an opportunity? I know, Haibert, that you don’t want to go out and 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.

Ruben: Yeah, I agree. It is very different. Before I got a job as a developer and I had a job as a dev at one point, I was doing projects on the side for myself, for people. That was okay, but I didn’t learn nearly as much as when I actually got my first development job and had to basically work based off of other people’s real-world business requirements.

Rob: Yeah, and it’s a trip. It’s weird to be on a startup podcast and tell someone to get a day job. Honestly, I’m just presenting it as one option. It’s just an option that I think works for you and I because you and I both did our day jobs and that’s one reason that we could do it. But then we have tons of examples of folks who never did it at a day job and are still really good.

Derrick Reimer is a good example. He never had a job coding. His job coding was when I hired him to do contract work on HitTail and then hired him to do contract work on Drip, but he already had the skill set. He had self-taught. 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. Even if it’s a few hours a week, whether you pair program or whether they look through your commits and they tell you what sucks about what you’re doing, I think that could be amazing. I think you can make a lot of progress doing that.

Ruben: Huge and not expensive compared to hiring somebody to build it entirely for you.

Rob: That’s right. Awesome. That’s one we haven’t received. We’ve received related questions, but not exactly like that in the past. Thanks for the question, Haibert. I hope that was helpful. Next question is another video question from Jim Huffman.

Jim: Hey, Rob. How are you doing? My name is Jim. I live in Seattle, big fan of the podcast. I have a question for you. I want to launch a SaaS company, but I’m thinking of launching at first as a productized service to test if the value we deliver works and two, if the customers would actually be excited for what we’re offering and have good retention.

For context, we’re a growth marketing agency called GrowthHit. We’re good at driving traffic and growing things. We’re weak in developing software products, so we’d love your advice. Is this a good idea or is this a really dumb idea? Thank you.

Rob: I like this question. What do you think, Ruben?

Ruben: I think there’s a difference between productized service and basically software. What they’re talking about is done for you. Yes, you can kind of test the value that you’re delivering to people, but it’s not the same thing. It’s nowhere near the same thing.

You can get a lot of insights into what you might need to build for a product where somebody signs up themselves and then they use the tool or their team uses the tool to do the work that your team was doing for them, so that they, in the end, get the value that they seek. I’ve known multiple people who’ve taken this approach, then built out SaaS, and had a tough time selling the SaaS.

Generally, often, it’s people who tend to not be as strong building software. It’s almost like, yeah, if we prove this out, then we can build the software almost like an afterthought. In reality, building software involves a lot. If themselves or their team is going to be using this software to try and get this […], there’s a ton there. What do you think?

Rob: I think you’re right. I like the idea of doing a productized service because I think a productized service as a business is very similar to running a SaaS. You just don’t have the software, you don’t have the product. I think the learnings of having the funnel, these folks are already good at it. But the learnings of building the funnel, the customer support, and dealing with essentially feature requests, changes, or whatever, I think there will be something there.

Your point is also very valid that taking that same productized service and trying to spin it into a SaaS. I don’t know. I’m trying to think of a time when I’ve heard that work, actually. I would like it to work.

Ruben: Steli with closed.io, except that we don’t know how many of their existing customers moved on to because it is literally somebody else doing the work for you to, okay, now you have to do the work using this tool. There’s a big difference there.

Rob: That’s the hard part. Yes, Steli, they had built a CRM internally because they didn’t like any of these CRMs. They had an elastic salesforce, basically, where you could add new salespeople. They built their own CRM and then they released that CRM as a product. I think that’s the thing. So much of the value is in the done for you. Here’s a counterexample that is totally theoretical and I’m making it up. I always imagined HitTail.

Again, coming back to HitTail, that was just, tie this thing into your website, it gives the app your keywords that you’re ranking for, then it suggests keywords that you should be targeting, and gives them a 1-5 ranking or something like that. That was an algorithm that could have been run on an Excel spreadsheet.

Ruben: People could have done it, right, exactly.

Rob: People could have done it. I talk a lot about human automation, hiring a VA to do it. That, I think, is interesting because it wasn’t done for you. We didn’t go out and then do the SEO for you. But it’s like, if HitTail could have been launched originally, it’s not software. It could have been built into Airtable or into Bubble to come back to no code. Just the work and the mental grind or whatever, the algorithm is just a human in a spreadsheet.

That’s different from what you’re saying. Most productized services are not that. Productized services tend to be done-for-you. It’s done-for-you podcast editing. It’s done-for-you SEO content. It’s done-for-you cold outreach. The service is the value. The software to do it has much less value.

Ruben: I think it can work if it’s maybe something small in scope, done-for-you keyword research like you were talking about with HitTail. If your software product is really close to the experience that they’re getting with a done-for-you service, I think that’ll work.

Rob: Yup. Here’s the thing. If you’re running an agency now and your revenue is spiky, a productized service will even that out, assuming you have decent churn. You can make it to $30,000 MRR or $40,000 MRR with a productized service in not a long time if you have something that’s a lot of value. There is an advantage to that.

What we’re saying is if it’s truly a done-for-you service, trying to spin that into then build software to do it is really, really hard. We haven’t traditionally seen that work. Versus, if you start with the idea of a service that isn’t done-for-you and it’s just a small lift that you essentially are human automating.

As you said, Ruben, the experience is almost equivalent. You still get those keywords in a spreadsheet. Whether it’s in a web browser or whether it’s a CSV that’s emailed to you, then the value is almost equivalent. Yeah, it’s an interesting distinction.

Ruben: Yeah. I do like the idea of also productized services for revenue early on and maybe fund the building of a tool. But then again, it’s moving over to a tool and all those other challenges.

Rob: Right, that is part of the stair step. I could see someone doing productized like Craig Hewitt did. Productized service with Castos Productions, formerly called PodcastMotor. Then he acquired a WordPress plugin that was podcast hosting and then he built Castos, which is now doing really well.

That’s the thing. If I were doing a productized service, I would start to think about what app can I acquire. Do I then have the revenue to buy something even if it’s nascent? Of course, that’s always my MO. I want to jump to product-market fit if I can, even if I spend tens of thousands of dollars and it saves me 18 months. If I can fund that with another project, that’s worth it to me.

Ruben: Yeah. The Craig example, notice how he didn’t create a product that did what the service was.

Rob: No, and he later merged them in, but they still are two separate products. It’s podcast editing and production, and then it’s podcast hosting. Both public and private podcasting, obviously, castos.com. All right, thanks for the question, Jim. I hope that was helpful.

This week’s sponsor is Trustshoring. Trustshowing helps you find reliable pre-vetted developers or software development agencies. Turn to Trustshoring if you need to build an MVP, scale your team or product, or you have issues with your current developers or code base and need guidance on your SaaS journey.

Trustshoring makes software development and remote hiring easy for all kinds of founders, technical and non-technical. Book a free no commitment call with Trustshoring’s CEO, Victor Purolnik, who I met at many MicroConfs. Visit trustshoring.com to book that call. That’s trustshoring.com.

Next question is from someone who asked to remain anonymous. He says, “I want to thank you so much for all the value you put out into the world. You and Indie Hackers have taught me so much more than I learned in school studying marketing and entrepreneurship.” That was my experience with trying to look at junior college courses of entrepreneurship.

“Here’s my dilemma/question. I work at a VC-backed startup pre-seed that is blowing it. Making all the mistakes at being bloated with VC money lets you make not talking to customers, building tech because it’s cool, not because it solves a problem, and spending way too much money on stupid stuff like offices or PR for a product that’s not ready for PR yet.”

Ruben, this is when we say, more money in the hands of someone who knows what they’re doing can get you there. It’ll save you years. If you have more money in the hands of someone who doesn’t know what they’re doing, it will just burn money like it’s on fire.

Ruben: We’ve seen a lot of that recently.

Rob: Yeah, big time with Bolt. It’s not both, it’s the other one.

Ruben: Fast.

Rob: Fast, yeah. Not just them, we see it in a lot of stuff.

Ruben: Right, all the time.

Rob: This experience has pushed me into looking at independent startups rather than big venture-backed. I fell down the rabbit hole and I came up with my own business idea. I’m planning to solve my own problem with tech, validate the idea, and talk to as many customers as possible.

The idea is a two-sided marketplace. It’s basically a matching service. I’m going to keep it anonymous because he asked me to. He says, “It solves a problem that I had a few years ago, so I built out an MVP using Bubble.” It’s like they’re sponsoring this episode. I think that’s the fourth mention.

The next question or two is about no code as well. He says, “Here’s the issue though, it’s a two-sided marketplace, which is a red flag. Serving a market is notoriously a pain in the ass to serve. They are price sensitive. This means higher churn and fighting two wars at once.”

Yes, I often say it’s like you’re launching two products at the same time. What could be easier? “The question I’m struggling with internally is, do I ditch the idea and all the work I’ve done to start a B2B business with way lower churn or keep going a little further on this one and see where it takes me?”

At this point, I don’t believe he’s launched still. He’s talked to customers. He said, it’s something they want and I think they will pay for. He says, “My take is I should keep pushing, especially because it’s a problem I’m passionate about. I’ve done the hard work. Now I just need to push through this plateau.”

I’m not sure what the plateau is because I don’t think he’s launched yet. Maybe no one is actually signing up. I’m also concerned that I’m overthinking this, but I’d love your thoughts on this generalized problem of sunk costs and when to pivot or persevere/how selective to be with business ideas when getting started. Thanks for letting me rant on here and thanks again for all you do.

Wow. Yeah, there’s something there. What are your thoughts? Everybody knows my thoughts on bootstrapping two-sided marketplaces. Let’s see what you think about his scenario.

Ruben: I kind of liked the higher level question of when to quit and went to continue. Does he say how long he’s been working on this?

Rob: No, it’s light on details. That’s the thing. I’ve talked to a bunch of customers. I don’t know how many that is. It’s something they definitely want. I don’t know how he definitely knows that, and I think they will pay for it. What does he think they will be? I would almost want to know, what exactly this many people have said. With that in mind, yeah, continue.

Ruben: It’s hard to say because a lot of details are missing from this. Two-sided marketplaces are tough. I think everyone who’s tried them or knows about someone who’s built it feels like they’re tougher. It seems like I would not recommend them for people just getting started. I would not go into it myself, unless I felt like I had a clear advantage in one area or the other.

If I’m just starting from scratch and I have no advantage, I would lean against a two-sided marketplace. Besides that, as far as whether to continue or not, I think it kind of depends on whether how much work—there are a lot of things that I wish we had more details on, but it depends on if you’re the type of person who tends to just work on stuff for too long and not switch. We know a lot of people like that.

I think they would lean more towards switching if they’re having those thoughts because they usually don’t and they just stick with stuff for too long. If you’re the type of person who just has a ton of projects in your history and you’re never finishing these projects, maybe not this one, maybe it’s okay to switch on this one, but I would lean towards the other direction.

I saw, recently, there was a good Twitter conversation about somebody asking. I’ve been working on this for two years. I think it was like $2000–$3000 MRR. Should I keep working on it? That’s all they asked.

It was interesting to me how many people were like, yes, continue and keep going because it can take time and all this stuff? My first thought was that two years is a long time. Opportunity cost is real. That’s a real thing. Another two years and then maybe your double at that mark, there’s a lot of context that’s missing from that as well.

Generally speaking, because of my expectations and based off of what I’ve seen, that’s just too slow. I don’t think it’s a good thing that people spend years—this year is off your life—working on things that are moving this slow. 

Now, that said, it also kind of depends on what the expectations are. If this is just something to help pay for some of the bills and they have a full time job. There’s a lot of context, and then it could be totally fine. It could be okay. That much slower pace could be fine because they have other things that they’re focusing on.

I think, in general, we want to be supportive. It’s really easy for people to just say, keep going, but I think more people should not, more often. If it’s that hard and they’re really, truly working on it, and they’re putting in effort in the right areas like marketing and not skipping those areas, I think people more often should move on to other projects.

Rob: I like the point you made about knowing myself. I said that a lot. If you tend this way, then consider the opposite. And if you tend that way, then consider the opposite too. I think that such a big part of me going from being unsuccessful to successful was getting to know my own tendencies better and then fighting against them. Fighting against the negative tendencies, the anti-patterns that come out in my mind.

Some of the entrepreneurs who I see, most of them who aren’t successful over and over don’t have the self-awareness to realize, man, I’m self-sabotaging here or I’m making the same mistakes over and over. We could go down a whole rabbit hole of how to figure that out.

I think on this topic specifically, it’s not that I’d say never start a two-sided marketplace. Mostly, I say bootstrapping a two-sided marketplace is almost destined to fail. I can think of maybe one or two examples. Usually, that person had some type of edge.

As you said, they already had an advantage. Like Dan and Ian with Dynamite Jobs, that’s a job board. You need two sides. They already have a big audience certainly on the candidate side and then on the hiring side because they’re like a sister podcast of Startups For the Rest of Us where they have entrepreneurs and they have people wanting to be entrepreneurs or wanting to work for entrepreneurs.

They already have a chunk of both sides of that. They bootstrapped it out of their current business. They self-funded it. I would say, yeah, go do that. That’s actually using your competitive advantage because they have a moat. They have 12 years, 13 years of podcasts and an audience in their online community.

If I were in the anonymous question asker’s shoes, I think I would be having done the research and feeling passionate about this problem. I would go ask the people. You’re going to charge one side of it. I would go to those people now and I would say, I’m getting this matching service setup. I’m going to charge $50, $100, $500, or whatever it is and just say, I’m going to do this one-off right now.

It’s not a marketplace yet, but pay me the money or commit to paying me the money, and I will go find that you probably pay me the money. I would actually want to be paid if I’m going to go do the legwork. I’m going to go find you an amazing mentor and see who actually ponies up.

This is different from pre-selling a SaaS app that you’re going to build for six months. This is really a consulting service or a matching service. Ultimately, you want a two-sided marketplace. Again, clarity.fm is a good example of that where you get entrepreneurs, experts, and consultants on there. Then you get people seeking to be matched or even to pick them out on a website. Dan Martell hustled like crazy to get people on there to get the experts.

Ruben: The nice thing about a lot of these is that you can prove them out really fast. You don’t need to build software for them in a lot of these situations. I like that advice. I think that’s right. They’re at the place where they should prove out what are the riskiest parts of this. Can you prove those out quickly? You can without software, 100% do that and see if it’ll work.

Rob: Yup. You’re going to prove out both sides of it. If you’ve talked to 5, 10, 15, 20 people and no one’s willing to pay you, probably no one’s willing to pay you. If suddenly, five people write you a check or charge that card on Stripe, then you go look for mentors, and no mentors want to do it, you’ve just disproven that side of it. Great, it’s done. The hypothesis is canceled and we move on to the next thing. That’s how I would think about it.

He built a prototype in Bubble, which is cool. But I don’t even know why you need to do that. It could literally be an email with a few questions to do some matching of what you’re looking for. I don’t know how complex the matching process is.

We do mastermind matching with MicroConf. That’s at microconfmasterminds.com. We do that, I think, every quarter. We do ask for quite a bit of information. It’s basically like reform.app, Peter Suhm’s. It goes into an Airtable and then we mess people up manually. That’s what the service is.

We didn’t build some incredible algorithm. We could long term build an incredible algorithm based on time zones and this and that. Right now, it’s a manual matching. That’s an interesting one where you could call it a productized service, but it’s more just like human automation behind a web form.

Ruben: It almost goes back to that productized service question, where we talked about, what are the ones that are more likely to work if you create a software product for it? This kind of sounds more like that.

Rob: Thanks for that question, Anonymous. I hope that was helpful. Our next question, the last of the day, is actually two questions from two different people who sent their questions within a few days of each other. These are both about no code.

Eddie Larson writes, “I’m curious about your thoughts on the no code platforms and the solutions being built on them. I’m using bubble.io and love its robust capabilities. Is this something you see as a framework that you could use to build an MVP or something that you could sustainably build an actual startup on, you could grow, and not run into scaling issues? Thanks for always being my go-to podcast and providing great episodes.”

Next one is from Carl. In a similar note, he says, “I was wondering what you think of using no code solutions to build and bootstrap SaaS businesses. What are the downside risks other than platform risk? I’m thinking of using Bubble, a no code platform that seems very promising to build a lifestyle business as a side hustle.

I’m unsure if I would then pay someone to create the app properly,” he means in code, “if it proves successful, or if I could use Bubble forever. I’d love to hear your thoughts and experience.” I love the content. All right, sir, how much thought have you given to no code? What do you think about their questions?

Ruben: Not too much. I liked the idea and I was excited about it at one point. I asked a few people that seem to be digging into no code and what their experience was because I was super curious about how it’s working. Are people actually building real businesses with it and what’s going on? Those cases where I asked people what they were doing with it, the answer was kind of the same.

It was interesting. They were doing small stuff, but it just wasn’t there to where they can build a software startup a SaaS, not in the way that we typically know SaaS products. I think it’s kind of related to what we’ve talked about to where, I like this where you can create more simple products, something kind of early to prove out an idea if you truly need the software.

In many of those situations, I question whether you even need to build something and whether you can just run it with people as a service or just behind a form. People are doing the actual work and things like that. I’m not an expert in this, but based off of what I know about it, those are my thoughts on it.

Rob: Yeah, I think we’re in line. I actually did a full 20-minute talk on this called the SaaS Founders Guide to no code. It was for MicroConf Remote about six months ago. You can find that for free on our YouTube channel. We’ll link it up in the show notes, SaaS Founders Guide to no code.

Basically, I went through that. I did a bunch of research, both through Google and talking to some founders I know who have experience with no code, and tried to wrap my head around the use cases that I could see for this. A lot of it was some basic automation.

no code is great for being quick to build, easy to maintain, and not needing to code. I feel like building an MVP, doing simple CRUD, and some internal tools like a line of business apps. When our entire podcast production is now through no code. It’s through Airtable because it’s just easier than building it out into code. But that’s not a product that we’re going to sell to other people.

In fact, let’s say we did take the Startups For the Rest of Us workflow from Airtable and start selling it to other people, I think we could get five or 10 people paying for it. What’s interesting is it would be very, very hard to automate. That was one example that would be hard to automate with humans. Then I would want to have code written and build it from scratch.

Ruben: It would feel very MVP, right?

Rob: It would, that’s it. The scalability would make me nervous. There’s some brittleness because it’s integrated with Zapier. One out of 100 of those don’t work right or one out of 500. Whatever number it is, it’s too much for my comfort zone.

We can’t customize the UI. It’s great for line of business. It’s great that our producer, Ron, was able to put it together using Airtable in a few weeks and he’s not a developer. But to make a product the way that I think we traditionally think about it, longer term, I do think that you have to usually get code involved, unless you’re going to do something like, again, say mastermind matching where it’s a service that you’re offering. It’s like, fill in a form and then we churn through some stuff in some table. Do you know what I mean? That’s a whole different thing.

We’re not selling the product though. We’re selling the end result. The result is the mastermind. We could literally do that by sending you an email, having you respond to it, and just a human matching it. I think that’s where it is.

I think an MVP is not a bad way to think about it. I don’t want to sound down on no code because I’m not. I love that it exists. I love that more people who are nontechnical are able to build technical-sh things to accomplish these tasks.

Imagine the world before Zapier. You don’t have to imagine, we were both there. Remember, to tie anything together, you were doing a webhook, which wasn’t even webhooks back then. It was like this to an HTTP post with a query string, and then I’m going to parse this. It was a mess.

Ruben: It’s a big difference. It’s much better. Yeah, 100%. I agree. I like the idea, that’s why I was so excited about it for a while and talking to people trying to see what is actually being done. I think it’s promising. It’s there for certain things, just not there for building entire SaaS businesses.

Rob: Yeah, but here’s a question. Do you think it ever will get there or do you think it will continue? Because I think each year, no code does more and more. I don’t think no code will replace developers myself, but I do think that it will allow more and more to be done. If we look five or 10 years out, can you build an entire SaaS on it?

Ruben: Tough to say. It feels too big of a challenge, but maybe. I don’t know. I would hope so. That would be pretty cool. What do you think?

Rob: Back again to that simplicity, imagine Shopify or Heroku having their own no code platform that had their domain objects and their domain model built into it. You’re not trying to use Airtable, which is just a generic database to tie things together. But to build a Shopify add-on or a WordPress plugin, now I’m getting back to the same list to build any of those step one businesses, it’s literally building blocks.

The domain is known. You don’t have to build a generic tool. I think building add-ons is probably where I see it going. I cannot imagine building an ESP out of no code and that working. I can’t imagine in 20 years that being possible.

Ruben: Yeah, there would have to be some pretty big advances made in a few areas. It does go back to how simple is it going to be what you’re trying to build on the software side? How complicated does that need to be?

Rob: Remember, let’s say 1999, just to build a website, everything was all custom code, custom HTML, and then these website builders started coming out. There was the Yahoo Builder. Later on, Squarespace was years later, but there started to be these builders, where you could just get more done. And it was like, okay, sweet. I don’t have to worry about that. Now I can build more complicated things. 

I’m going to start doing stuff with the database, making dynamic this and that, and making it searchable. I’m going to build shopping carts. I don’t know how many shopping carts you built, Ruben. But I’ll tell you what, from 2000 to about 2003, I think I built like 15 shopping carts from scratch each time because it was before Shopify and the other carts that are out there.

Because there became these no code solutions or these prepackaged solutions, it didn’t mean, oh, no, we don’t need developers anymore. What it meant was, good, now I can work on really custom-hard problems. We could move on and we could build Basecamps. We could build Mailchimps, and we could build ever-increasing and more complicated software and leave maybe this more mainstream generic software. I don’t say generic in a bad way, but generalizable and highly horizontal software.

That just happened with SaaS, but the same thing might happen with no code where really, early simple problems, little add-ons, and then, oh, there’s a website builder, and then, oh, I can build a whole cart by drag and drop, or whatever. I don’t know if it’ll be the same things in the same order, but I do think it’s from low complexity to high, that just then frees up development resources to then do more complicated things.

Ruben: If it progresses in that way, then I think it would be generally a good thing for what people are able to put there. They’re still nowadays if you think about how much time, effort, and money is spent on a lot of these things, which really do feel like they should be a lot easier, more simple, and already figured out. It just feels like way too much. If those areas could be taken care of with no code, I think that would be a big deal. That’d be great.

Rob: That was a good question, gents, about no code. Thanks so much for sending those in. Ruben Gamez, you are @earthlingworks on Twitter and you are working on signwell.com, which is an electronic signature.

Folks, if you’re currently using DocuSign or HelloSign, you really should head to SignWell and check out what he’s building because like a true indie SaaS founder, you’re innovating and building a pretty cool product over there. We use it ourselves here at TinySeed and MicroConf. In fact, we liked it so much. TinySeed invested in it. Check it out, signwell.com.

Ruben: Yup. Thanks for the invite. I appreciate it.

Rob: Hope that was helpful. If you have questions for Startups For the Rest of Us, you can email them to us. You know the address. You can go to the website. I really appreciate it when folks send in their questions or comments because it helps us know that this truly is a worldwide global community of ambitious SaaS founders.

We have people at all stages. Folks who are just looking to launch a side project, get a couple $1000 a month in revenue, and prove that they can do it, maybe prove it to themselves, maybe prove it to their family members, prove it to the world. Then we have folks running multi, if not deca-million dollar businesses, who have just a wealth of experience. That’s what makes this audience and this community great.

Thank you so much for joining me every week. It’s really a pleasure to get on the mic here and wrap up episode 605. I’ll be back in your ears again next Tuesday morning.