Rodrig Naska: How to Build Your Startup's MVP without a Technical Co-founder

Hey everyone, how's it going? My name is Deanna Isaacs, I'm the head of global growth for the Founder Institute. Super excited to welcome everyone, super excited for today's event. We've had close to 700 people sign up, so I'm expecting a pretty large crowd. I think, you know, we usually get about 40 to 50% people to attend these events, so let's kind of get things started. Like I said, my name is Deanna, I'm the head of global growth. Today we have Rodrik Naska, He is the founder of Forvito. It's a product studio that specializes in no-code. He's going to be talking about how to build your startup's MVP without a technical co-founder, specifically using no-code. We have a very, very interesting agenda out today. I'll kick it over to Roderick in a second, but before that, what I wanted to do is just go over some housekeeping rules. As you can see on the right-hand side, if you, if you're joining on a laptop or tablet, there's a chat button, please use it, we'll be asking questions, you know, let us know where you're coming in from, that's always a great question to start, I saw like Tunisia, Canada, Brazil, Vancouver, Montreal, Brooklyn, New York, Montreal again, Malaysia, Serbia, so Poland, Belgrade, Texas, Nigeria, Essex, Cairo, so very, very international audience, so super pumped for for this. Thanks to everyone taking the time out for us and to watch this amazing webinar. In the meantime, so like I said, we have the messages on the right-hand side. Underneath that, there's another button called the Q&A button. We'll reserve some time towards the end for Q&A. Please use the Q&A button to feed us questions and we'll bring them up on stage, right? And then we'll end today's session with open networking. So as you saw when those who were here earlier, there's all these virtual tables. I'll jump on a table, Rodrik will have his own table, and then you guys can chat with us. All right. So just to recap, Rodrik's going to do a presentation followed by a live building workshop, then followed by doing like maybe 10 minutes of Q&A, and then we'll wrap up with open networking. All right. That being said, would love to introduce Rodrik. Rodrik, before you do that, I actually want to put this poll up. So we were curious to know, like, why do you want to build an MVP? We had some people already— Roger, can you see the poll?

Uh, yes, it's visible.

Perfect. Uh, awesome. So yeah, folks, if you can like start getting some votes, and we have 180 people live, I think that number will go up to about 300 over the next few minutes. That's why we like to kind of start this out like around 5, 6 minutes after, but in a minute we'll get things started. Okay, so, uh, MVP, you want to build it? Okay, very interesting. Um, A lot of people here, Roderick, about 63% want to build an MVP for customer development purposes or get feedback or validate an idea. I hope that's useful for you. So, all right, do you want to get things started? Do you want to maybe introduce yourself, tell everyone what they're going to— what you're going to be building in real time in front of them? And then whenever you're ready, you can do a screen share.

No, I think that sounds good. I'm actually very glad to see the responses here because most of the clients that we got do it to validate their idea. And then they understand if they want to raise or not. So guys, very happy to be here. My name is Roderick. You can call me Rod. I've been running a low-code product studio for the past 3 years where we, we work with mostly very early-stage startups that want to build their MVPs in a way that is first, faster than a traditional development so that they can test out the market and also cheaper because it takes less time to do that. So I think I'm just gonna jump straight to it and share my screen and we can—

Yeah, before I guess, yeah, sorry, one thing, two things I forgot to mention before you do that, Rod. So at the bottom of your screen, folks, you'll see like some emojis. Please click that if you, that's the only way we can really get feedback feedback on whether or not Rod's sharing good content. Okay, so Rod, you're already getting some thumbs up and you haven't even done anything, but I guess that's good. Uh, and then the second thing, which is pretty important, is, uh, we're running a no-code bootcamp at the Founder Institute, I believe, in August. Uh, yeah, August 9th and August 16th. Roderick is going to be the one leading it. I'll drop the link in the chat. Uh, you know, today's session is really just a sneak peek of what he's going to be doing. Everything is live. Live building. He's going to walk you through some amazing framework stuff that he's done in real time for some, uh, I think he's built over 35 different, you know, digital products. So I hope to see everyone there as well. I'll throw the link into the comments, but you know, for the— I'll kick it back over to Roderick because he's the one who's going to be leading the show. I'm going to disappear from stage, so I'll jump on back for Q&A.

So, Roderick, okay, thank you, eh, so just to to kind of show some visuals that should make it easier to follow. The goal of this presentation today, which will also be a workshop for the second half of it, is to show you guys what we at Urvido think is the most efficient way to build an MVP without code. And just to give a disclaimer, we, I think we're pretty good at building products And the way that I actually got into no-code and low-code is by trying to build my own startup. I was very bad at marketing, so that startup didn't go well, but was able to build it really quickly. So that's what we're doing nowadays with founders. We're working with them to get user requirements and then turn them into a product as quickly and easily as possible. So just to give you guys an idea as to what I was planning to talk about today is, first of all, the introduction that we already went through. What is no-code? Maybe some of you know about it, maybe some of you don't. Next, how we go about building a very simple doc about product requirements, which I think even if you're using no-code, then are iterating really quickly, it's important to know who you're building for and what you're building. And then the next two steps, which will be part of the workshop, we are going to work to do it live here where we're going to build a very simple AI-powered personal assistant, especially for fitness, who can give you nutritional tips, etc., etc., and how to do that. And then at the end, as Ehan said, we're just going to do some Q&A where hopefully I'll be able to provide any useful insights. So the, I guess the main question to provide some context as to why we are, you know, talking about building an MVP with no-code or low-code. I just wanted to give an overview of what no-code is. So in principle, no-code is a way to build digital products without coding. And usually that means, you know, visually doing that, just dragging and dropping things into a screen. There are a lot of platforms where you can do that for static sites, mainly let's say WordPress, Webflow, etc. What we're going to actually focus on here is the tools that allow you to build web applications rather than just websites with this. So basically any, any sort of no-code, low-code tools that will allow you to actually build a SaaS app, a marketplace where you have multiple user accounts, interactions, etc. And one of the things about no-code is it's easier to learn, right? So not everybody has had the chance or the career path to actually get into coding, and some people might feel like that will take a lot of time, and it will take more time than no-code. Then I guess it's, it's good to go over some Pros and cons of no-code overall. The main thing over here is speed and efficiency. You can really move faster because a lot of things are already done for you and you really just can drag and drop them and then connect those with each other to actually get a working prototype or product. One of the things that would be a con over here would be limited customization. So, uh, I I think this should be expected if you're using a no-code platform, let's say like Bubble, which we're going to talk about more specifically in this presentation. You can build a lot of things with it, right? But any no-code tool will have already predefined ways on building a frontend or building logic that will give you less customization options than raw code. However, we do think that for most MVPs, as long as the ways that are predefined in these tools are up to, you know, the main industry standards, it's good enough to actually have an initial product and validate the idea. And then if you see here for scalability and maintenance, we have this thinking phase, and that's on purpose because no-code and low-code, it's harder to make it scalable than code at some point, especially if you have an extremely intensive app data-wise. But the point is also that if someone gets to that point, they'll usually have a lot of traction and they'll have the resources to move to code. But then we have this thinking phase, because maintenance-wise, we could even argue that it's easier to maintain a no-code app because there are less moving parts. So now I wanted to jump into Why Bubble specifically? And the reason for this question is because we will use Bubble as the no-code platform that we're going to talk about. You know, we're going to build the app in this workshop. And Bubble is, in our opinion, and it's actually a lot of people who in the space who think this, probably the most complete tool out there. It's not the easiest to learn, but it's the one tool that will help anyone to basically have all the logic and the backend and the database of an app in one place, as well as allow you to build a really capable frontend and basically implement any designs in it. And it's, it might be one of the top 3, I think, and I don't have numbers to support this, but I think in terms of the mass of community that it has and the support that you can get about it online. So I won't show Bubble right now because we're going to jump to it pretty soon. But I wanted to jump to how you can build your product requirements before jumping, you know, into actually building something. Because I've done this mistake early in my career very often where I just want to build something without defining a vision for it beforehand. And we have By working with clients, working on multiple projects and making mistakes and also seeing what worked, we've come up with a simple framework on how we think product requirements should actually be built. So I'll stop sharing my screen for a second so that I can share the right tab with you guys because I wanted to actually start the workshop here with you guys by building the product requirements of the app that we're going to build. Together. So this is a variation of what we actually use at Revito as a, what we call, a pre-scope or discovery template. And before we start filling this out, very simply. Just wanted to go over what we think are the main items that someone should conceptually define before actually jumping to building something. So the first one, you know, we need to have a goal for what we're building and just a vision that is concisely, I'd say, described and set up. So what I was thinking we should do for this one is We'll build an AI-powered fitness trainer. So since this is a live workshop and I wanted to do this live with you guys, maybe this will not be the most concise way to put it, but I'm going to do my best here. So the goal is to build a Text-based fitness instructor that uses AI to provide personalized tips to its users. So for the sake of time, I'm not going to fill everything out, but below, you know, if you're using this template or whatever, you can at some other place elaborate more on this. And then before jumping into other things, one of the main items is actually you should know who you're building it for. And you can define those as user personas, or if we're talking about, you know, just in terms of, let's say terminology for developers, just user roles. So in this one, let's just keep it simple. Let's say we're not building an interface for the app owner or the admin. So we'd have a not logged in user, the person that we want to use the app and convert that is seeing the landing page. And then let's just call the other user, the person that is using the app. And let's assume this is a SaaS where they subscribe, the subscriber. So, you know, after we have also described them, then it's time to actually build the user stories. So different product teams will go will use different ways. Some can use initiatives, some can just define their product in features. We like to use user stories because it makes it easier to also collaborate with non-product people and non-product teams. So let's say that we'll put a couple of user stories for each. So if we wanted to know what we should build for the subscriber, we'd say we'd use a simple formula As a type of user, I want to achieve X goal so that, well, I want to do X things so that I can achieve X goal. So let's say as a subscriber, I want to be able to ask any questions to the AI about fitness so that I can get responses for my fitness inquiries. So if we were, if we had a lot of time and if we were doing, you know, this in a more detailed way, user stories would be more specific than this so that we could actually, you know, have a more well-built app and well-thought-out project. But this would be mainly the idea. For the user stories. And if we were to also think of the marketing side, let's say as a not logged in user, I want to be able to quickly understand the benefits of using, of subscribing to the app so that I can make an informed decision. Or, you know, whatever your goals will be to achieve for any, any user type. So let's assume that we have all of this. I'm going to go over the other parts as well, and then maybe we can elaborate more if we have time. But the moment that we have the user stories here, one of the things that we do then is we need to think then also visually what screens and elements do we need to support up all the functionality that our users will need. Okay, so I'm getting feedback that I need to zoom in into the screen, so I hope this will be better for you guys. So if we go to the screen and elements, these are a few things that we put as default for every element. An enter screen is something where we group together sign in and sign up. We have account settings, of course, we have billing, Here in this app, we'd have a landing page, and then let's make this a screen instead of an element. And then this would be visible, well, I guess to all the user roles, but especially to the not logged in. And then this would be relevant with the user story of understanding the benefits. So I will put this template out there as a public resource, and it's a It really helps to have relations between user stories, screens, and elements, etc. But I'm not going to go too deep on those. And then I guess the, the most crucial part of this app would actually be the chat assistant. So if we want to build this as a chat-based app where you can actually chat with the AI to get different tips. We do this and I'm gonna call this an element so we can put it on a page. We can put it as a pop-up or anywhere. And then this would be related to the user story for being able to ask any questions to the AI. So this, you know, of course would be expanded even more in a long-term project. When you dive even deeper, you would prioritize things as well so that you know what to jump to first. But let's go even further. So another thing is, after we have defined what we want to build and then we kind of know how it should look like, and then imagine, you know, we have expanded on all these items here, we need to make a decision about using the best tech stack and then also understand what are the Technical feasibility. Any potential— what is the technical feasibility and any potential issues so that we can mitigate any roadblocks in the way? So for this one, from our experience, a tool like Bubble would be really good to use. And the main reasons for that is it allows you to work fast because it allows you to have frontend and backend in one place. And more importantly, if we are thinking about what we need to do this, we need to integrate with an existing AI model. So let's say part of our stack will be, you know, OpenAI's GPT and we add it here. It's really important to take all of this into consideration because Bubble makes it very, very easy to integrate with external tools via APIs. And as I'll go in later, we also have a lot of plugins that allow us to really quickly integrate with these external services even without needing to, you know, actually code a lot ourselves. And if we are still thinking of our tech stack, our users will need to pay us if this is a SaaS and a subscription-based model. So let's add here as well the tool of choice usually for online payments, which would be Stripe. So if we take another look at this, you know, let's just say here also another user story to support Stripe. It's not logging users. I want to be able to subscribe to the app so that I can use the AI fitness trainer. So assuming that you actually have spent a lot of time thinking of these tools and how they— if they can actually help you achieve the user stories that you've set out to complete, then it's, it's time to see are there any technical feasibility issues or other potential issues. This is a placeholder. You usually, when we work, let's say, with medical apps, there is a framework called HIPAA that might be a problem. This wouldn't be an issue here. If you are in Europe, you might need to add something like, you know, let's say you need to make sure that we're GDPR compliant, etc. I'd say depending on whether you're doing just getting feedback and not launching publicly, you maybe don't care about solving this right away because you just want to have a product out there. But it's good to have this in mind because you don't want to be in a situation where you've chosen tools that you're working with for, let's say, 2 or 3 months, and then, you know, those tools cannot bypass whatever you need to bypass in terms of, or, you know, be compliant with in terms of regulations. So if we have all of this in order, it's so It's good to have a set of milestones set out for your team or yourself on what you're trying to achieve. They would be usually very fluid and they're supposed to be very fluid because with you getting feedback and understanding the market more, they should change. But we always try to do what we call a sprint zero or— and a sprint is basically milestone in terms of agile software development where we do discovery, we complete more about this, and then we keep building a prototype. As we build the prototype and test it internally or with, you know, any early testers, then we keep improving this document and discovery, and we keep adding what we think should be the next milestones. So let's say if we did discovery and prototype here, we'd have something Hey Rod, sorry to, I don't usually jump in.

I want to jump in because I think there's one really important question Seb is asking. How do you identify technical feasibility if you do not have a technical co-founder? Do you maybe just want to quickly address that and get back into it?

That's, that's a really good point. So for that, I think if you start getting more acquainted with the space that you're building for. You should at least become aware about the— if there is any legal frameworks that you need to adhere to. Like what I said about HIPAA compliance and GDPR, etc. However, if we're talking about technical feasibility regarding technical issues and scale, you might miss some of those. And I think that's more than okay. And it also happens even to technical people that you do not get everything down from the beginning because it's an experimentation process. So honestly, the main question about that, if you do not have the option to consult someone who is technical, would be to just try and do as much research as possible and try and get that. And the main goal of this is to actually help you build an MVP. And if you can find out about the technical feasibility items upfront, that will help you down the road. But even if you face some of those that you did not foresee beforehand, I do think that building something that allows you to test even with a few users will still be very usable if you have to just refactor a few things or redo some of the work. And I see a comment about Bubble. We will, guys, just touch directly on Bubble and build a Bubble app. Right after this. So for, you know, let's just call this milestones. I think this is the last part and, you know, everything above this is more important. But then it's actually important to set out some milestones and split the work into milestones where after every milestone or block of work, you actually are able to test something from which you can get feedback and iterate on. So let's say, you know, we'd have discovery and prototype. Okay, we build the prototype and then the next milestone would be AI assistant chat. And okay, cool. We build this, we think, okay, this is working and then we get some feedback and then we think, okay, after we've done this, then it might be the time to work on monetization. And this is an overly simplified version, but the idea is you can build something that you can test on that will give you enough information so that you can modify or iterate or tweak the next sprints. So without building the AI assistant chat first, you don't have the real-life knowledge and practice of seeing people use the app so that you can know enough what features they'd be able to pay for from this if you want to run a freemium model. Let's say. So you can add timelines for this. I don't want to go into very much detail. As Ehan said, during the bootcamp there will be much more time for that. But another thing, if you're working with a team, we use this to set up internal meetings and also external meetings with clients to use them as, well, to keep us more responsible on what we're doing, but also as accountability checkpoints that things are coming up up to a certain point, we should have something to show. And we also really like to have a section with questions when we work in teams. And we add questions that are answered and unanswered, then they can be related to the project overall. Here, just because we want people to have access to what was, you know, a question in the beginning and not have to actually scroll through, let's say, WhatsApp messages, Slack messages. Etc. So I think, uh, Ian, I don't know how we're doing with time. I think it sounds like it might be a good time to jump to the Bubble app in the workshop.

Yeah, we're just at 30, so, you know, we're about halfway through. So maybe, I think, let's do 20-25 minutes of, um, the workshop, and then we'll leave a little bit of time, maybe 5 to 10 minutes of questions, and then we'll leave it up for networking. We might go over in the hour So like, I just want to make sure by the end of the hour people see the workshop and whoever can stick around for the questions and networking, we can go over.

Okay, sounds good. So guys, I'm going to stop sharing again and then I'm going to share my whole screen because we're going to need to jump through different tabs to do this. Okay, so now I'm excited. We're actually going to start to build an actual app with Bubble. So the goal here is now to— well, let me show you what you first have to do. I have done some of these things already, but the first step if you want to use Bubble, which I'm going to use right now, would be you'd go to Bubble, uh, you would click sign up, and then you'd see something like this after you use Google SSO or you put your email. Then you would click create an app If you don't have any templates, you don't see this. You put a name for the app, you click get started, and then you'll see the Bubble editor, which will look something like this. So I'm going to go a bit over— I'm going to delete everything so you see a black canvas in here. Here is where you can visually drag and drop elements into the page to create the functionality. In this no-code tool, you can also use workflows.

Yeah, sorry to interrupt, man. Can you just zoom in just so everyone can—

Oh yeah, sorry, my screen is way too big. And is this better?

Yeah, that's good for me. If you're in the audience, can you give me a thumbs up? Like, is this better? Okay, yeah, that's better for me. Cool. All right. Thanks, guys.

Okay, perfect. So this is the Bubble editor. This is a design tab where you can visually drag elements like buttons, text items, icons, etc. And then here we have workflows where we can have triggers if someone clicks on an element, etc. Here we have the database that we build with all, you know, the information and how that's stored and organized. And I'm not going to jump into styles, but it allows you to also have, uh, things in style so that everything can look very consistent. So just going back to the discovery template, we know now that we're gonna build for two main user roles. So the easiest thing to do is to build for the not logged in user role. So let's just really quickly do a landing page here in the index page. So let me just zoom out just a little bit and I hope this is still visible. You can give me messages if you cannot see this and I'll zoom in again. So if we're doing a landing page and then let's call this AI Fitness, the name of the page, and let's leave the page white. We're gonna do this as a column page so that we can show things, you know, stacked vertically. So if we were to, let's say, put a group here for the hero section, and the easiest way to go about this is always using columns so that they're always vertically stacked. We do this, uh, appearance-wise, we just want to make sure that things are not, uh, next to each other. So we're just going to give it some padding on the sides, and then let's just call this an H3, maybe Heading 3, and then let's call this your personal AI Fitness trainer. So there are some quirks where you need to, you know, set the width of things, etc., but you can drag and drop those and then specify these things here. So then let's say we want a couple of buttons, or let's say one main button over here, and then we're going to put some space between this so they don't look pretty weird. And then let's say "try it for free" if we want to, you know, have a free plan or something. So let's say we have this and then we want to add another section below, so we would add a group and then maybe we'll call this "benefits," that's why you should use this, and then let's do column again to make it easier. So we do this, let's just add the padding again, So we'd add some text items, right? So let's say here we're gonna use body heading 5, so it doesn't take as much attention as this one. Actually, let's put a different background color here to make it more visible, and let's use white. For the text. So let's say, "Cheaper than a €300 a month trainer." And then we can put things here, you know, just a disclaimer, here at Revito we're not conversion experts. But just want to show that how you can build a page that then you can work with people to make it highly converting. So then let's say accessible 24/7, and then let's say satisfaction guarantee. And then, you know, we can go on, we can add different things, and we can actually make this a proper landing page. But I'll jump to actually building the chatbot right now, and if we have time, maybe we can edit this more at the end. But before we do that, if you click preview over here, you'll see a preview, preview of what you're actually building. So what we want to do now is let's try and have people try this app. So I want to create another page that when the user clicks here, they're taken to that page and actually try the chatbot. So let's call the new page just chat for the sake of keeping it simple. Over here, we still want to use column, and we're gonna add a section where we want to keep the chat in. So let's center this column again. As a chat, we don't want it to take the whole page, so let's just put an arbitrary number, 800 pixels wide max. And before I jump to building this, We need to choose a model, an AI model from where, you know, that which is going to provide the answers and going to act, is going to act as the fitness structure in this place, in this case. So the easiest to work with in our experience is OpenAI and their GPT-3.5 is really capable. So what I've done in this case is I have added a plugin called ChatGPT with Real-Time Streaming. Here, this plugin is actually paid. I think it's $10 a month to use it or $80 once, but there are also free plugins that do the same thing. Of course, the premium ones like this are actually faster and work better, but this is the one that we're going to use to test this out. So before I put this plugin in, I want to make this into a nice interface to use. So one of the things that we want the user to be able to do is we want the user to be able to have an input or a message. So group user input would be this one. And then let's use colon again to make it easier. Let's make this here. And Bubble has an element called input. So let's put this over here and then let's give the user easy way to understand what's going on. We want this to be able to take the whole screen, so we do this, and then we can put a button. If we put some space, it would be nicer. And then let's say "send." So let's make it more naturally Looking one. So we have this, we want to put this at the bottom. So now if I preview this page over here, this is all that we have, right? We need to put the actual messages up top, but this is where the user would type, hey, what exercises should I do for apps and then they would click send. But let's now really quickly put the actual chat where people can type in messages. So in Bubble, so these are groups what we put before, we put something called the repeating group which can hold a list of items and in this case what were the messages would be coming in as a list and being saved in as a list. So We're going to use the column again over here. We're going to make this be able to take the full width of the screen. And just so I understand what you're doing, let's say repeating group messages. The type of content here would be text. And just to— we want to display this within what we're building, so we put something like this. And then we'd show here the text from the current cell. And just to make this look like an actual message, we can basically change the appearance. Let's make it like this. And now I wanted to jump onto how you can implement actually the OpenAI stuff in here. So let's make this have some space. So we have the visual structure, we just have to actually put dynamic data into this. So the plugin that is installed over here, this one specifically, We'll provide a few elements and the element that we need is ChatGPT data container. So this is an element that will not be visible in the page, but will allow this page to access the data that we get from GPT when we're actually working with it. So the main thing that we want to do is we want to add the workflow here. So that when we click send, we want to send a message to GPT via this. So then we're choosing that, and then the history, we refer to the element that is holding this information. And this is the cool part, by the way. So ChatGPT allows us to give it a prompt and to ask it, you know, to tell it to behave as something specific. So here we would say, okay, this is the system, and to the system we're telling, you are a personal fitness trainer who is an expert in their field. You will Assist the user with any fitness-related questions and you'll provide actionable items in your answers. So you can really do this for any case. We've done this to build social media assistance, to come up with captions for social media apps, etc., etc. And then here we'd have the user, and when we click the button send, what we want to do is we want to grab what was inputted from the user in that input that you created as the value that we send here. So once we do this, let's make sure that the data source here actually comes from this. So from display messages, because we're going to display these messages. So we send this and then let's test it out. Let's see how this is going to work so far. So, as we can see, we need to take a couple more actions to attach. The messages here. So what we would do is, so we would basically merge what we cut from here. So once we get the message back from ChatGPT, then we take this action where we add this message to the list that we're trying to show in the user, to the user in the screen. Okay, so I'm afraid we're running out of time, so I think it's probably best if I just share an app very similar to this for another use case. And we can see how this is basically done and we can all preview it. But the logic is exactly the same. There are just more steps that I think would take a lot of time, probably 40 minutes to put together here. But if we preview this app, well, actually let me just duplicate this for you guys and we can see it here. With the prompt that we— So in that same button of workflows, Here we sent the prompt. So let's copy the prompt that we built here. And let's preview this. And let's get rid of this debug item over here below. Sorry, just the last thing. And basically Bubble is communicating via the plugin with the OpenAI's, I think, GPT-3.5 for this one specifically. It's not GPT-4. And it's just bringing in the data directly from that. So this is, I thought like this was going to be developed faster here. But I hope that even though we didn't do it all from the beginning, it can kind of give an idea on how this is implemented. So, Eihan, I actually think it might be best to get specific questions. If people have any questions about this rather than maybe, you know, going over details that might be irrelevant on how to use such tools.

Yeah, for sure. I think first of all, like, Rod, this was pretty impressive. You managed to do all of this. I think for anyone who's done product development knows that doing it already is stressful. Doing it live in front of 300 people is even more stressful. So I think this is really cool. You have a bunch of questions here, so we can kind of start going through that. But I think before We do that everyone in the audience, like, again, this is not the most ideal environment to be building product, but yeah, you're getting a lot of great feedback on this, Rod. So yeah, thanks for doing this. What I'm gonna do is I'm gonna stop sharing your screen and start bringing up these questions 'cause there's a bunch here. So like, I think what we'll do is maybe we have 10 minutes left. I'm gonna skip the networking. I'd rather go through all these questions. So here, let me stop sharing your screen and let's kind of get through this. All right, so the first question, I'm gonna bring it up. Eve is asking from Seattle, why Bubble? What's their competitive advantage? There are several people in the chat as well and in the Q&A asking like what's the pros and cons of Bubble? Do you just want to maybe go over that at a very high level?

Yes, for sure. So I don't think that Bubble is the best tool out there and I don't think there is one tool which is the best, but Bubble, what it does really well is that it does a very decent job at everything, uh, having the frontend in one place, having the backend, and having the database in one place. And usually that is quite important to move fast. There are other tools out there, like for example Webflow, uh, will be really good for building a frontend, but you'll need to connect it to another backend with a lot of workarounds. Other tools like Xano, which is really, really good at the backend, but it's only a backend. And I'd say Bubble is usually our tool of choice because it allows you to do everything in one place.

Okay, awesome. There's a lot of questions here, so let's try to burn through as many of these as possible. And folks, if you have questions, dump them into the Q&A, look at other people's questions, upvote it. I'm just going to be going after the ones that are are kind of the most popular and then we go from there. So Rod, like maybe let's do lightning round before we burn through as much of this as possible. So Ed is asking, from a technical standpoint, what kind of apps does no-code itself, can you build in no-code and what kind of apps can you not build on no-code? You know, you've built 30 of these, like what is the limitations here?

So I think it can be good enough for almost any sort of MVP. The only apps which we think no-code is not the best tool for are instant collaboration apps. For example, if you want to build an app like Google Sheets or like Notion, where— or even Figma, where a lot of people are collaborating in one space at the same time and you need that to be super instant, we have not found a tool out there that can do that yet. Or it can be done with no-code, but you'd need to link so many no-code tools together that it's almost like if you take that effort, you might as well just learn how to code, I guess. But we get, I'd say, like 80% of the people that we work with are building B2B SaaS apps. And it's, I think, we haven't found the use case yet for a B2B SaaS app that wasn't in some collaboration where it didn't work. Perfect.

That's a good thing, folks. I threw it also in there. I forgot to show it earlier, but, you know, again, Roderick's doing the bootcamp. If you want to go join the waitlist, go to that link I just shared. But all right, let's kind of move on. So Ola is asking, you know, the cost of no-code, low-code versus full-fledged development at a very high level. What type of savings are you seeing? What type of level, like, I guess also what type of time savings are you seeing to push to ship features and ship the product or ship your MVP?

That's a pretty good question. I would say that from our experience, anywhere from like 1/4 of the time to 1/10 of the time. And then savings, your hosting will be more expensive with no-code because you're actually, you know, paying for the tools to do the hosting. And a lot of other things. But whenever developing, I don't think hosting is usually the main worry about the cost. It's usually the labor cost. So in terms of saving money, we've had clients that reported to us that fully code agencies asked for 10 times the money. And, you know, even if like hourly they could have been 2 times as expensive as us, that still would have been, let's say, 5 times of the money being asked. But that's, that's a very, it's also a hard question to answer specifically because it also depends, you know, how skilled is the coder, how skilled is the no-coder. So it's not like we can give like an exact number as to how much faster you can build.

Great. Stefan is asking, this process that you did requires that you already went through the problem validation stage, isn't it? So, Where would you find building a no-code MVP? Is it pre-validation, post-validation, when you've just identified the problem? How would you think about that? Maybe reference also your discovery template because I think that was really helpful.

That's, that's a really good, good point, right? Because the, the thing is, with you being able to move faster with no-code, you can also afford to do experiments that can help you validate, right? So this, a very toned-down version of this, you know, can be built even for you to help validate and to come up with different iterations and prototypes to show to different users. So we work with people from all stages. We've worked with clients who already had a a tool, let's say even coded sometimes, but it was just expensive to maintain, or with another no-code tool and then they wanted to move to Bubble. And I think the speed of development and ease of it compared to code actually makes it a tool that can be used throughout the development lifecycle, not just, you know, at the end or the beginning.

Perfect. I think this is a great segue to our next question. Do you just advise to work on your MVP on Bubble or when would you, or doing the seed run and then go into full code service?

That's a good question and there is no single answer to it. It really depends what you're building. We've had clients that started with Bubble and then this actually is a case study on our website. They're called Swap and they do, they're kind of like a channel for returns and exchanges for e-commerce so that they can handle it through them. And you can imagine they have a lot of traffic that goes through them. So right now they haven't been working with us for 5 months. They took off and then they had their internal team, etc., did really well. But right now they're actually converting to fully code because they have so much traffic that they need custom solutions. But on the other hand, we've had other apps like, let's say, job boards that we've built that came to us with the idea, okay, we're going to use Bubble just for an MVP. But because a job board, the user only goes in once, applies, and usually leaves, and the traffic is not too high, something like Bubble, it's been now almost a year working on that project, and the client was thinking, I'm gonna switch after 3 months, but Bubble is handling it really good. So I think it, it will depend on a case-by-case basis.

Okay, great. Let's just continue, keep burning through this. Um, Alberto is asking this from Mexico City. He's building something on Wix, a marketplace on Wix, and he wants to, well, you already talked about the pros and cons of Bubble. Bubble looks complicated. Can you clarify why to switch to Bubble and start from zero? I guess maybe on this question, can you just add, one of the reasons Bubble is so good is just 'cause of the community, the resources, the education. So maybe if you wanna dive deeper into that, I think for the audience that'd be helpful.

Yeah, so compared to Wix, uh, and I'm not an expert at Wix, have— I think we've, we've had to work with it because some clients already had it. Uh, it's— I, I think the learning curve is way smaller. So Bubble would take considerably longer to learn, and, and I think with Wix you can probably just have something that you can show way faster than with Bubble. But to my knowledge, not something that you can actually iterate on and expand. So I'd say that probably it's time to learn something like Bubble once you know that marketplace is needed. And you can probably keep with Wix if you, you know, if Wix allows you to validate that. But something else that might be really easy to use that does, let's say, like 30% of what Bubble does but better than Wix at that is something called Softr. And if I send a message here, will everyone be able to see the link?

Yeah, in the chat, Softr.io. Yeah, perfect. It's a great no-code tool. Guys, there's a bunch of, just answer some of these questions. I've been also answering them. There's so many no-code tools out there. Rod's just, he's a specialist in Bubble. He's built apps on it. So that's kind of the reason he's advocating for it. But there's just so, I'd highly encourage you all to like, The idea of this webinar is to introduce you all to no-code technology and just getting your brains to think about it. But there's just so much out there. You should really investigate and see what platform is best suited for your product, right? Rod, are you okay to go to the next question?

Yeah, yeah, I think so.

Okay, so Adam is asking this, you know, consider Bubble's walled garden, would it be better off using an AI coding assistant like Copilot? Copilot, CodeWhisperer, Tabnine. What would the advantage/disadvantage be in deciding between bubble, no-code, and an AI coding platform? That's interesting.

So I'm probably not the right person to ask to answer this because I'm not a coder myself, but we do have coders in our team who have, you know, been trained then to use low-code, no-code tools. My understanding of it is that you could use such, you know, AI coding assistants if you know already how to code, and they, you know, they can make you more efficient, but you'd need that base knowledge in order to know how to implement the code that you're getting from it. And I think then Bubble, you know, it's easier to understand even if you don't know coding at all. You just, I think, need to probably have a analytical thinking skills to get started with it. So yeah, I guess the, the answer to your question would be it depends on how comfortable you are in implementing code.

Yeah, I think the way I would tell people to approach this is like think about like how Bubble has that workflow builder, like what are all the different logic, logical requirements around everything. All right, let's do one last question because we are exactly on the hour. And Frank has been a trooper and been sharing quite a lot of questions and participating in the chat, and he's a developer. So I think this is a good question. What does the end code look like? Can it be accessed? Is developer friendly? Can a developer expand it further if needed?

That's a good question. And by the way, we do use different no-code tools, but Bubble is one that we use mainly. Different no-code tools have different policies around this. Bubble specifically, you cannot export the source code, but it allows you to inject JavaScript if you want to using Node.js and allows you to connect, you know, to external APIs if you have an external server where you have custom code. So that's, I guess, technically how you could expand Bubble, but you cannot really export it. I saw also a question in the chat asking which is better, Bubble or FlutterFlow. And it really depends what you need because, for example, FlutterFlow will allow you to export your code. But then FlutterFlow, even though it can build web apps, it uses Flutter and it's one of the tools that's the best out there for building mobile apps with low code. So I would say we did showcase Bubble here because we've seen it to be the most useful for most use cases. But you should, you should do your own research for all the tools out there if you need to use a no-code tool and are not technical. As to which one is the best for your use case specifically.

Okay, perfect. Rod, man, thanks so much. We're just exactly on the hour here. We still have about 200 people live. Let me just check. I think at one point we had 400 people at one point here. So pretty large audience. We had 750 people sign up. So not bad. For ShopRate, again, everyone, you're gonna get this recording. You're gonna get access to the resources that Rod shared. What I wanted to do is I just want to be respectful of everyone's time. Let's break out. Yeah, you know, audience, please show Rodrik the love, you know, connect with him on LinkedIn. Hopefully you'll stick around a little bit for the networking portion. You know, I'll also stick around for a bit, but yeah, Rod, any final words for the audience here before everyone hops off?

No, this was awesome. Thanks a lot for making it, guys. And yeah, as Eihan said, happy to connect with on LinkedIn with anyone. I did go through the struggle myself when getting into no-code to find the best tools, so would be happy to connect and if possible even, you know, answer any questions that you might have.

Perfect. Yeah, thanks everyone. All right, so I'm going to end the session here. Let's break out the networking, Rod. I know like I don't know if you have a hard stop, but if you have the time, feel free to join your table. I'm sure there's some people who wanna chat with you. And then once again, let me just share it out once more. Again, Rod is hosting a bootcamp, so if you guys wanna go join the waitlist for that, I saw already a few more people already signed up. We're gonna be giving more details on that shortly. All right, I pinned it to the chat. You guys can access it later. I don't know how to reshare this. All right. Thanks everyone. I'm gonna end this session. We'll see in the networking component and then we'll go from there. Thanks everyone.

Thank you guys.