303. Before you build with AI: what every non-technical founder needs to know

Timestamps:

• 00:00 - Introduction: VC walks away from vibe-coded startup
• 02:36 - Security breach: 5,000 AI-built apps had vulnerabilities
• 05:00 - The iceberg problem: What's hidden below the surface
• 08:35 - Every single app had security issues exposed
• 11:09 - Who gets sued: The platforms or the founders?
• 13:09 - VCs rejecting vibe-coded apps during due diligence
• 15:29 - Apple cracking down on AI-generated apps
• 18:21 - The maintenance nightmare: Adding features breaks everything
• 24:46 - What kind of engineer you actually need now
• 29:53 - Building isn't the constraint anymore - sales and marketing are
• 34:35 - Engineers' role is now strategic, not operational

Free AI Mini-Workshop for Non-Technical Founders:

Learn how to go from idea to a tested product using AI — in under 30 minutes.

Get free access here: techfornontechies.co/aiclass

Follow and Review:

We’d love for you to follow us if you haven’t yet. Click that purple '+' in the top right corner of your Apple Podcasts app. We’d love it even more if you could drop a review or 5-star rating over on Apple Podcasts. Simply select “Ratings and Reviews” and “Write a Review” then a quick line with your favorite part of the episode. It only takes a second and it helps spread the word about the podcast.

Listen to our podcast on:

• Apple

• Spotify

• YouTube

• Audible

• Pandora

Transcript:

[00:00:00] Rags Vadali: There was this VC who went into doing technical due diligence for a startup that they were going to fund. And like many, many startups, that founder had essentially vibe coded an application. They went to VCs claiming funding to build on this. And they basically got told that, yeah, we're not going to fund this because not in this state, because this is essentially vibe coded with lots and lots of issues that you will need an engineer or a team about two months just to fix.

[00:00:34] Sophia Matveeva: Hello and welcome to the Tech for Non-Techies podcast. I'm your host, Sophia Matveeva. If you're a non-technical founder building a tech product or adding AI to your business, you're in the right place. Each week, you'll get practical strategies, step-by-step playbooks, and real-world case studies to help you launch and scale a tech business without learning to code. And this is not another startup show full of jargon, venture capital theater, or tech-bro bravado. Here, we focus on building useful products that make money without hype and without code.

[00:01:08] I've written for the Harvard Business Review and lectured at Oxford, London Business School and Chicago Booth. So you are in safe hands. I've also helped hundreds of founders from concept to scalable product. And now it's your turn. So let's dive in.

[00:01:30] Hello, smart people. How are you today? Last week, I told you about the three stages of the non-technical founder's journey and what to do at each one. And I promised you that this week we would go deeper into exactly what AI tools can and can't do right now and what this means for how you build your product. And so here it is, I keep my promises. And before we dive in, I wanted to share something that just really blew my mind.

[00:02:00] There's an article in Wired that reports that a security agency analyzed 5,000 apps built with the tools that basically everybody is using to build their products with AI. So, Lovable, Replit, Bolt.new and so on. And every single one of them had vulnerabilities, every single one. That's including exposing user data to anybody who could access the app. So this is really serious.

[00:02:36] Security breach: 5,000 AI-built apps had vulnerabilities

Now, this episode is not going to be about why AI tools are bad because I actually don't think that's true. So we use AI tools, we teach people how to use them because you can genuinely do a lot with them. But there is a line between when these tools are super great and when they're not designed to do something. And if you don't know where that line is and you know, why would you, if you're a non-technical founder, basically you are going to find out the hard way, either through a security breach, a lawsuit, a VC walking away or Apple rejecting your app. So basically the stakes are pretty high if you misuse this stuff.

[00:03:16] This is why at Tech for Non-Techies, we have updated our curriculum to reflect both the opportunities of AI and the very, very real risks. And today in this episode, you're going to hear from me, the world's leading expert on non-technical founders, and from our product coach, Rags Vadali. As you might remember from earlier episodes, Rags is a former Google engineer and he's also the product manager at Meta who launched Instagram filters to 600 million people. So basically the reason why we all look hot on Insta is Rags. So he's also led product at six startups and is now the CEO of his own AI company called Floato. And he uses Claude Code and Lovable all day for his own product. He has a master's degree in computer science and yet he still does not vibe code his own startup. And so that tells you something interesting. You'll find out why in this episode.

[00:04:18] So if you want to build a tech venture to fundraise or to charge customers for your product, then this episode is absolutely essential listening. And if you want to get our expert guidance on building your product the right way, then book a call with us. The link to book is in the show notes. And now, here is the honest picture of what AI can and can't do for you.

[00:04:45] So when we were talking about how to update the curriculum, given that AI tools are constantly changing, I was telling you that people have been screaming at me online when I said that actually you can't build an entire product with AI. It's really weird how passionate people are about the subject. And as we were discussing, the tools have genuinely changed. And as you were saying, Lovable is much more capable now than it was a year ago and we use it and we teach it, but capable is not the same as sufficient. And so I'm wondering, you as a technical founder, you've got your own startup. You also were an engineer at Google, you've got a master's in computer science. So you're using these tools daily. Like you're using Claude Code, you're using Lovable as a technical person. What's your view on them?

[00:05:00] The iceberg problem: What's hidden below the surface

Rags Vadali: So what is definitely true is that the capabilities of these tools are getting better day by day. So what seemed like an okay passable prototype, let's say three months ago, now looks like a fully functioned prototype today. You can even slot in things like logins, payments, all of the stuff that make it look more and more like a product. But the reality is that it is still a very good prototype. And there is a difference between a prototype and a product that you can ship. And what has happened, and I think this is kind of like maybe the reason for some of the reaction that you're seeing, is that what is visible about the surface has gotten so slick and almost very complete looking that non-technical founders who are not aware of all of the hidden stuff that engineers would have been building in the product are actually kind of almost in a sense, they're ignoring all of that today because the prototype or the lightweight product that they're building looks fully functioned, right?

[00:06:22] So I think the gap or the delta is actually going to a little bit more of a dangerous place where I think if you as a builder don't know that there are all of these things that you need to do and you actually ship things without building those, you're going to put yourself in a place that is, yeah, that is quite frankly not where you want your products to be because the consequences are actually going to be quite devastating in some cases.

[00:07:05] Sophia Matveeva: So this is actually that iceberg analogy that we were talking about yesterday, that essentially what you see, you know, if you're creating an app with Lovable, now you see the top of the iceberg and you're like, I've got this amazing iceberg. Like I'm so great. I'm going to go and get it out on the app store, which we'll discuss in a minute. But actually, if you don't know that that's literally the tip and the main thing is underneath, well, you're in for a disaster. And so can you tell us, remember, you're speaking to an audience of non-technical founders. So can you tell us what is below the surface of that iceberg that non-technical founders just don't know?

[00:07:44] Rags Vadali: Yeah. So the scary part here is a product today can appear perfectly functional, right? While being fundamentally unsafe. So what do I mean? So for instance, you don't know, you're not aware of what your app is actually being built on to the level of technical detail that you should be aware of. So when you ship some of these things, you will do, you will kind of, these products go out with insecure authentication, right? Open databases, exposed APIs, broken permissions. And as I'm saying this, many people probably don't even understand what they mean.

[00:08:30] Sophia Matveeva: It just sounds dangerous. It sounds bad, sounds dangerous and you don't know what it is.

[00:08:35] Every single app had security issues exposed

Rags Vadali: Exactly. And that's the problem, right? And actually, this morning, there was this report that landed in my feed that there was a security agency that did an analysis of 5,000 vibe-coded apps that were created by using Lovable, Replit, Bolt.new, Netlify, the tools that everybody are using. And they found that every single one of them had vulnerabilities in them, right? Including exposing user data, right? The ability for somebody to kind of actually gain access to your app and do all of these things, right? And the people who published them, well, they published them on all of these platforms where they are being assured that, you just press a button and everything is done, right?

[00:09:22] What's even more interesting is that when asked for comments, the platforms essentially said, hey, these are all settings that are available to the user, they could have turned this on or off at any point of time. Which is fine, except that if you don't know what you need to turn on and what you need to turn off, what you're doing is, A, you're putting the data of the people who end up using the app, if you're actually publishing these as products, at risk. But then more seriously, you put yourself at risk because you have all of these standards like GDPR, there's plenty of these things where you're expected to actually treat user data privacy with a whole lot of seriousness, right? So I think that's the gap, right? Most people don't know how they should actually set up all of these things. And this is where I think, again, the solution is also not that difficult, right? It is to actually get a professional developer or an engineer who understands this to make sure that you are doing everything correctly. So, yeah.

[00:10:38] Sophia Matveeva: You know, as you were saying this, and this didn't occur to me yesterday, but I'm thinking the lawsuits are coming and I'm quite curious who they're coming for. Are they coming for Lovable and Bolt.new because, you know, they're the kind of the original, they're the meta creators, or are they coming for the non-technical founders who basically released a bunch of data onto the internet? That's going to be really interesting to see, but I do predict that as something, you know, that I expect to see those news stories in just a few months.

[00:11:09] Who gets sued: The platforms or the founders?

Rags Vadali: No, absolutely. And I think what's happened over the last few weeks, I mean, is you are seeing that essentially what the platform providers are doing is they are finding vulnerabilities. Well, they're not finding it. People are reporting it. And as and when these get reported, they patch the system. But the story more and more seems to be, hey, we're giving you a whole lot of control. You should have done, I mean, Lovable is a great example, right? When there was their first response, when there was this big article two weeks ago or last week, when they said that they were basically exposing your entire chat history that you did to create your app to anybody who could access your app. Essentially, they said, hey, this has always been the case, or we should have better told you what to expect, right? So I think the net of it, what to expect if you're building one of these platforms is, yeah, you're on your own in a sense, right? You need to take the precautions that need to be taken. Don't rely on the platform to do that for you.

[00:12:19] Sophia Matveeva: We're also seeing, so we're seeing that, you know, the press is now covering it because actually when I was researching this episode, I was trying to look for articles that were a bit more skeptical of vibe coding. And there was an article that I often quote from the FT, which was literally from August, 2024. That was the Wired article that you mentioned today. But in general, there's a lot of press basically saying, you know, you can just basically just breathe onto your computer and then you'll have a full product, which is obviously ridiculous, but it does make for a good story. But I am seeing, even if the media story has literally just started changing today with that Wired article, the market is shifting because VCs are not really into vibe coded apps at all and neither is Apple. So let's talk about that. So first let's talk about venture capitalists.

[00:13:09] VCs rejecting vibe-coded apps during due diligence

Rags Vadali: Yeah, actually, this is also quite, like you said, this is almost like in the moment, right? In the last few days, like you're starting to see these stories. And so I saw another one where over the weekend, there was apparently this VC who went into doing technical due diligence for a startup that they were going to fund. And like many, many startups, that founder had essentially vibe coded an application. And obviously, right, as you know, just to state, restate the obvious, you can make something look very amazing, workable, end to end, right? So as a demonstrator of what you can do, it's a great check mark. But they went to VCs claiming funding to kind of build on this. And apparently, they basically got told that, yeah, we're not going to fund this because not in this state, because this is essentially vibe coded with lots and lots of issues that you will need an engineer or a team about two months just to fix. Right?

[00:14:22] There was this other story I read where I think it was more of a PE house who apparently are kind of just trying to take a look at something and go, if we can just vibe code the functionality of what you're saying you're building, then we're not going to invest because if we can do it, anybody else can do it. Right? So I think the bar is also shifting there. I think just three months ago, three to six months ago, it was new enough that people were early on to kind of create, to push the limits of what these platforms were capable of. They would vibe code something and try to kind of like, you know, get funding for it. But now again, I think the expectation is that, maybe connected to what you said earlier, nobody wants to be exposed to potential data leakages, lawsuits, all of that stuff just because the technical foundation isn't there, right?

[00:15:11] So that's one thing that's happening. The other thing is Apple, which is very interesting, right? Like most of the vibe coded apps today are web-based, right? However, the way the technology is kind of moving, there's lots and lots of, everybody's doing mobile, right? So folks like Replit, I think they also have mobile apps. So what's happening is Apple is starting to crack down on vibe coded apps, right?

[00:15:29] Apple cracking down on AI-generated apps

It isn't unclear exactly if they're going after the app builders, which they certainly are. But they're also going after, but they're also starting to apply much more scrutiny to just purely vibe coded apps that are being submitted.

Sophia Matveeva: They've done that, yeah.

Rags Vadali: Part of the reason is...

Sophia Matveeva: That's the difference. So you can either literally just make an app within Replit or Lovable or whatever, or, which is the second thing you're talking about is you can go to Claude Code and you can have Claude Code essentially create the app for you. And in both cases, those are getting rejected by Apple.

[00:16:08] Rags Vadali: Yes, completely vibe coded apps. They are kind of starting to get rejected by Apple, right? The reason there being that again, all of these vulnerabilities that for instance, when you build a web app, nobody is really checking. You can publish it. Apple is a different ball game. They have extremely sophisticated, they've spent 20 years of building the app store. So every time you submit something, your code is pretty much, you know, analyzed, right?

[00:16:43] Sophia Matveeva: Yeah, that's why Apple is like, Apple is a premium product, not only because their products are pretty, which, you know, I think most people don't know about this, you know, obviously you and I have submitted things to the app store, but most people haven't. So when you submit something to the app store, so essentially what you're doing is you're submitting it kind of like to editors, but not only to editors who look at the content of like what you can visually see, but they actually look at how your thing is made. Yeah, absolutely.

Rags Vadali: They care about users. Correct. They care about user privacy, security, data leakage, all of that stuff. So in as much as you have not considered those when you're building it just because you cared about the user interface and you cared about really quickly getting to an app, you run the risk on the mobile system of running into the gatekeepers at Apple. And all of these are pointing to the fact that actually, at some point there is getting to be a real gap between what is a well-made functional prototype and what is a product you can ship. Right? And I think until now people kind of didn't see that or put it in a different way. This has become more and more prominent now because the capabilities of vibe coding platforms are such that apps are looking more and more like completely done apps functionally. I mean, I should also say it's not just looking right, like you can actually functionally also do things, you can add databases, you can add, you know, payments, etc. But...

[00:18:19] Sophia Matveeva: But then all your data is leaked.

[00:18:21] The maintenance nightmare: Adding features breaks everything

Rags Vadali: You can add all of that stuff. Doesn't mean that you've done it right. And doing it right, you need to know what you're doing to make sure that you're doing it right, to put it simply.

Sophia Matveeva: Well, actually, also, you know, let's talk about the maintenance problem because this is again, this is something I totally didn't know when I released version one of my first app, which was, so in the tech world, when you're, and you know, we all know this when we have apps on our phone and then sometimes they just update without us doing anything. Essentially, you get a new version pushed out to you. And so what we were discussing yesterday is that people got very excited as they created the first version of their product. And I mean, to be honest, it is exciting. Your idea comes to life. You start seeing it. It's really, really wonderful. And then what you do is you create version 1.2 and version 1.2 is going to have some more screens and it's going to have some new features. And that's essentially the way products develop. They basically start growing with new screens and new features. And so, Rags, tell the audience what happens when you start adding new screens and new features to your vibe-coded app.

[00:19:35] Rags Vadali: I mean, one thing to realize here is that these AI coding tools are actually, they are building what you're asking them to build, like you're prompting, right? So they are optimized to get something working quickly. They're not optimized for building something maintainable, right? So what does this mean, right? This means that what you often end up with is there's no real coherent architecture underneath to support the next three or five use cases. It only supports the first use case that you built for. When you come and then say, okay, I want to add a new feature, in most cases, what happens is that your vibe coding app will try to rewrite your whole app so that it accommodates the new use case. Now, normally, if you were just still iterating or building a prototype, this wouldn't matter, right? You're the only user. Okay, sure. Something breaks. You're going to go to the next version. But imagine doing this when you already have, let's say even a hundred users, right? And what happens is that once this change happens, all of the hundred users can't use the app anymore because some data structure, which you don't even know what it is, has broken, right?

[00:20:58] There was no forward compatibility, databases have broken and all of these things are things that you care about. The prompt that you gave them to change doesn't encapsulate any of these things, right? So all you're telling it is yeah, build me a next version and so you run into this scenario where, well, this is very real. I have run into this myself many many times using like, you know, in my projects that I work on, not only with vibe-coded projects, I should say, but even with things that I build with Claude Code. I have personal tools that I build and maintain. And so, for instance, I was working on a CRM and all I said was, hey, I want to add an additional field. And in doing so, it took me 10 more steps after that to get back to the original state because it kept breaking things. And so this will compound. So what starts out as a very nice, tight, end-to-end working shiny v1, the minute you add a new feature, the risk is very real that it starts to break. Right? And the way to avoid this, obviously, is, or the way engineering teams avoid this, is thinking about some of these upfront and building a more, you know, building kind of like system design, maintainable code, et cetera. A lot of that stuff you're not gonna get with a lot of these vibe coded apps.

[00:22:36] Sophia Matveeva: You know, I've been thinking about what has changed since I started Tech for Non-Techies and working with non-technical founders. And that was basically six, seven years ago. What has changed since then and what has stayed the same? And so one of the things that we used to say in our marketing back then was when you're a non-technical founder, you don't know what you don't know, which is true. And basically that's what gets you into trouble because you end up hiring, you know, back then you would hire the wrong people. You would overpay them because you didn't understand what you're doing or you'll try to really scrimp and then essentially just, you know, if you don't know what you're doing, you're kind of a bull in a china shop.

[00:23:18] And that slogan still applies today, but just in a different way. Because if you're a non-technical founder, although prompt writing is available, like you fixed your Claude Code issue in 10 steps, but you knew how to do it. You knew what the problem was. But as a non-technical founder, you can't write those prompts because you don't know what the problem is. You know, if audience, if you've been listening and you've been thinking, well, okay, I understand some of these words, like I know about databases, but when he's talking about authentication and he's talking about security, like that is beyond what I know. Yes, it is beyond what you know. So this is why this whole thing of, you know, you don't need a developer at all. That is not true. But as we were discussing yesterday, the way you work with developers and when you need them and what exactly you need from a developer has changed. So I think we kind of started this episode on a bad note, maybe, which is like, you know what, actually, you still need developers, it's still going to cost you money, you can't do everything with AI, which is a bit of like, that's a disappointment. So now let's make people a bit happy. So yes, you do still need developers, that's what we're saying. But we don't, you don't actually need the kind of team of developers that you used to need. And thus you are not paying the same amount of money. So Rags, tell us what kind of engineer do you need at this stage of the AI revolution?

[00:24:46] What kind of engineer you actually need now

Rags Vadali: Yeah, so I think what definitely has changed is that as a non-technical, non-engineer, founder or app builder, actually you have a lot more control today in being able to develop the app experience yourself. And I think there genuinely you don't need developers, because this is the part that you can see, if you have a sense for what you want to build, you can prompt it and the tools themselves are getting very good in applying the right kind of design, the right kind of like, you know, based on what you want, right? But what, and so what used to, what potentially used to be, hey, get a team of a front end developer and a back end developer and, you know, that team, that sense that people used to have of, okay, now once I do at some point, I need to budget for and go hire a team, is now not a team anymore, right?

[00:25:46] I think what you probably need is one, competent sort of like, you know, technical person. And you probably don't even need them to be sort of like a co-founder type full-time with you on the product. Because it's getting to the place where if I think about when and where do you need them, I don't think you need anybody when you start. For sure. You go to Lovable or any of these tools, you can start it up. You don't even need them until you sort of made a prototype now, put it in front of a few users and gotten feedback. I think where you need to take a pause is let's say you use the prototypes the way prototypes are meant to be used, which is I built a few versions of it, put it in front of my users and figure out, okay, this particular one, I'm getting a lot of like good feedback. I think I want to build it into a product. I think that's a point at which before you go and say, okay, now I'm going to just launch it on Product Hunt or put it wherever, I think that's where you need to kind of take a pause and go, okay, can I get somebody to come in and essentially help me make this prototype into a product? Right?

[00:26:52] I think that's the, that is still the bridge, right? What's the prototype to product delta? And what you will find is in most cases, it is not going to be, they're not going to come and tell you change the app, change the UI, but because you, they're actually going to come and take a look at it and go, okay, either your code is written very kind of structured very poorly. We need to kind of do a little bit of a refactor on this to make sure that like, you know, this is scalable or hey, your databases are open or you need more authentication or user data is being stored in a database with no security, for example, right? Whatever it is, right? I think that's the phase where you definitely need somebody to work with somebody to go from prototype to product. And then I think what you need is somebody who's available for you on an ongoing basis as and when you are kind of continually iterating on it, right? Because every time you get a bug from a user or a feature request, right, you're gonna go and make a change. And periodically, I think you do want people checking to make sure that like, you know, the integrity of what you've built is still there.

[00:28:17] Sophia Matveeva: So one of the things that we were discussing is the difference between a product and a business. And a cool thing that has stayed the same despite the AI revolution is the beginning of your innovation journey. The beginning of that journey is you create a small product that you test. So if you're going to have a mobile app, it's five to seven screens. Even though now with Lovable, you could make 30. That is not a good test. Your test is going to be five to seven screens because essentially like in the scientific method, if you're running lots and lots of tests simultaneously, you won't be able to read the results. You won't be able to really understand what the results are saying to you. So this is why, even though it's now super easy to make a huge prototype for the purposes of, you know, being successful, which I'm assuming you want, you want a five to seven screen prototype, which you then still go and take to people and you get their feedback. So that actually hasn't changed at all in the last seven years that I've been running this company. What has changed is how you are creating that prototype and the speed at which you're creating it. Because what's amazing is that now you can create a version, get feedback from people. And if that feedback is like, okay, we like the general idea, but this design, we don't get it at all. You can literally remake a design that same day and test it again. So you could go through two different versions in one day, whereas before it would take you, you know, weeks.

[00:29:53] Building isn't the constraint anymore - sales and marketing are

Rags Vadali: Yeah, actually. So I think the more broader thing is also. If you can build it, so can now millions of other people, right? This is accessible to everyone. So building and making is not the constraint anymore. Like, you know, we've talked about actual shipping into a product that still remains a bottleneck, right? But when we talk about the early part of it, the people who are going to be successful are not folks who kind of get into the, it's very addictive. I think as you mentioned, it talks to the product. It's awesome to sit in front of one of these tools and start creating stuff that was in your head and see it come to life in really beautiful ways. Right. But the real purpose of this is not that, right. It's actually saying it's the speed of things, right. Like exactly, like you said, instead of now I can do a full fledged prototype that I would have needed an engineer to help me with in the past. I just don't need them anymore. And I can do 20 versions over like a week, right? If I have the users to test it with. I think it's the people who are going to be successful are the people who are going to spend the time upfront trying to really nail down, okay, is there a problem here that I'm solving? And is what I am proposing or how I'm proposing to solve it, are users saying that this is something that I might be interested in. And so that is really how you should be using these tools to get that signal very quickly. And once you do, obviously, let's say the app does need 30 different screens or features, once you've got the kernel of it, you can sit down and build that 30 in three days. And then you've got a full-fledged app that you can then take forward, which we would recommend, obviously, that you definitely get then technicalized on it to make sure that it is actually built the right way.

[00:31:51] Sophia Matveeva: So in terms of our curriculum for everybody listening, the front bit of it has basically stayed the same because the front bit, the early bit is literally, let's find out the problem you're solving and who you're solving it for and do they care and are they willing and able to pay for it. And the way we find this out is not by reading the McKinsey quarterly or sending people surveys that really doesn't work. The way we'll find out is we've, essentially, you build a product which is now really, really simple, but you build something that is testable. And this is another skill set that you really need to learn because actually anybody can open Lovable and write a bunch of prompts and get something pretty. But is that actually going to test your idea? Not necessarily. So an example that we were talking about yesterday was Tinder, right? Like if you're first bringing out Tinder and you want to test whether people would use it, you don't need the full thing. You don't need all of the functionality. You probably want to test people's reactions to the swiping feature and to the match feature. And so you probably just only want the swiping feature, the match feature, and probably the profile feature. That's all you really need.

[00:33:02] So this is why we're still teaching, figure out what problem you're solving, and then let's help you actually identify what that looks like visually. Like that problem, the kernel of that problem, what are the screens? What are those screens actually going to do? Then you very easily create these screens with AI. And then we teach you that testing process, which is all about how do you test properly? So essentially how do you test as an anthropologist where you're watching your users and allowing them to give you their real views as opposed to being a salesperson when you're like, please like it, this is amazing. So that bit is still the same. What's now different is that, okay, now that you've tested this and you're working with professionals, it's, you basically bring in professionals later. You also need a different type of professional. You expect your professionals to use AI and because they are using AI themselves, you know, yes, they are using Claude Code, but they know how to use it. So it's a completely different thing. You know, Claude Code in the hands of Rags and Claude Code in my hands is going to be a completely different experience, right? And so this is what's different. So the first half of our curriculum is still the same and that is the foundation. If you get the foundation right, then actually everything else these days is cheaper and easier, but the foundation is still the foundation.

[00:34:35] Engineers' role is now strategic, not operational

Rags Vadali: Yeah, absolutely. I think, no, I was just going to say it like to close. I think the, it is the role of engineers has actually not disappeared at all. In fact, it has actually just become more strategic, right? And the best outcomes are actually going to be founders, non-technical or technical, doesn't matter, but like let's say non-technical founders who are actually going to use AI to accelerate the discovery and the creation of the first sets of things themselves. And then they partner with strong engineers to turn these prototypes into durable products that will stand the test of time. You don't want to launch something and two months later figure out that this is not working, right? Or it's like, you just cannot maintain it.

[00:35:31] Sophia Matveeva: And I think a positive note to end on for non-technical founders is that because the barrier to building has gone down, so the barrier to testing has gone down because you as a non-technical person, you can just do that with Lovable. And even when you do hire somebody, they are going to be working for you part-time because you don't, essentially these days you don't need a full team straight away. You know, you do, once you become, once you kind of start running a bigger company, you have lots of users, fine, but like not when you're releasing your first real version. So it is, the barrier to the creation of a thing is much lower. So what does that mean? It means that in order to actually have success in any market, you actually need to have commercialization skills. You need to really understand how to sell, who wants your thing. So you need to be really good at sales. You need to be really good at marketing. You really need to have good customer relationships. If you're building a consumer product, you need to be really good at advertising.

[00:36:32] And these are all the skills that traditionally non-technical founders are much better at than technical founders. Because if you're a technical founder, you're generally really, really good at building. Not all, but in general, like that's your forte and that's what you do. Whereas if you're non-technical, you can't build. So generally people focus on the sales and marketing. And actually I would say that given the fact that building is now easier, the real, I think competition, the wild competition is going to be in the sales and marketing realm. And that's exactly non-technical founders' realm. Yeah.

Rags Vadali: That's where the bottleneck has moved to.

[00:37:08] Sophia Matveeva: Well, thank you so much Rags for joining me and telling everybody about our updated curriculum. I highly, highly recommend that you reach out and you talk to us if you are building a tech venture and you want it to be a real success and you want to scale it and you want to go from idea to something that people around the world are using. We would love to help you. And on that note, thank you very much for listening and I shall be back in your delightful smart ears next week. Ciao.

Rags Vadali: Bye.