Can AI Really Build Enterprise-Grade Software?

[00:01:04] Guy: Hello everyone. Welcome back to the AI Native Dev. Uh, today we have a really fun episode where we'll talk a little bit about sort of startups and entrepreneurship. We'll talk about, uh, building, uh, in, in sort of AI-powered ways and vibe coding and kind of this brave new world, but also how do you actually build a company, uh, and uh, and use AI to, uh, to make that a possibility and to talk about all of that.

[00:01:26] Guy: We have Maor, who is the founder of Base44. Cool. So let's get started, uh, with just understanding Base44, uh, for a sec. So you said that you had, you know, a different idea to how vibe coding and such, uh, was being done. Tell us a little bit about what Base44 is and what was different about how you built it Or not how you built it, but rather the thing that you built.

[00:01:38] Moar: Um, Base44 is, is an AI app builder. Uh, kinda like the text to app that you see a lot these days. Uh, I think we're taking a very different approach, a very opinionated approach, which is. Uh, help people build actual full stack functional applications.

[00:01:57] Moar: So sometimes the way I like to, uh, put it in perspective is saying vibe coding has been awesome at first, um, for building websites and building user interfaces and some MVPs, like mainly front end. Um, and then Base44 was. I think the first one, but maybe one of the first ones to introduce this concept of, uh, batteries included app builder, which means that when you build a web app in Base44, you already have everything you need to make it functional built in.

[00:02:29] Moar: So user management, a database, integrations with like sending emails or leveraging LLM and analytics and logs and all those kind of things that you need when you're actually building a fully functional or even complex application. Uh, and that's what Base44 basically does. It's helping users create software that either they or the users or customers are going to use day to day.

[00:02:54] Guy: And is it, is it more about the choice of. Uh, the opinionated stack. Hey, I chose a database, I chose, you know, all these other aspects. Uh, or is it, uh, about the continuation? 'cause I know you also, you know, you deploy an application, you kind of handle the operational aspect of it. Uh, do they have to go hand in hand?

[00:03:15] Guy: Is it, uh. I guess, how do, how do you see the, uh, the interaction between like the choice of stack and managing the operation of it as well?

[00:03:24] Moar: Yeah, I think it's, to some degree both. I think the choice of stack will become less important throughout times. So like I can see that with our developer community as they gain more trust in like, uh, what Base44 does.

[00:03:40] Moar: And like the fact that it's becoming slightly less and less important. Like what's the stack stack that you're using and how you're gonna handle deployment and those things. Uh, because vibe coding is getting better. It's not perfect yet, it's still how to build production applications. I think on Base44 it's slightly easier, but there's still a long way to go.

[00:03:59] Moar: Um. I think it's like this opinionated approach is basically trying to correct the actual experience of how you want vibe coding to look like. Like you don't wanna start stitching together different services and say, oh, you know what, now I want to connect an LLM, I need to go to Open AI, bring my API key, fit it into the vibe coding platform, and I want to connect the database.

[00:04:25] Moar: I need to look at the tables and run migrations and stuff like that. Things that. Nobody really wants to, uh, to deal with, or at least in the future, I'm imagining a future where those things are, are entirely being handled, uh, behind the scenes. And you can just literally build what you wanna build and literally program in English without needing to understand again, what an API key is and so on.

[00:04:50] Moar: Um, obviously to do that, we had to take a lot of like opinionated decisions on the tech stack and so on.

[00:04:56] Guy: And, uh, I'm, I'm still curious on how much is it that you are, uh, uh, picking specific stacks that, uh, you have seen the LLM to be good at or that you've just really invested in making LLMs create well with versus where is it things that you've just taken out of the LLMs Uh, domain?

[00:05:15] Guy: You know, like, I'll give an example. Like in in, in Tessel, you know, when we create software, you know, for a while, we actually don't need that now, but used to be that, you know, the, the LLMs just wouldn't stick to the dependencies we told them to do. It's like, Hey, create this code here. Yeah, use library A and B, and it would just sort of use B and Z and whatever.

[00:05:32] Guy: It would invent things. Uh, and until eventually. Uh, we said like, okay, you're not allowed to choose dependencies anymore. We'll, we'll put the import a, import B over there and you, you fill in the rest. Yeah. Uh, we've since removed that 'cause they got better at it, but, uh, but that was like, to me, like commandeering control.

[00:05:48] Guy: Like I, I guess is it similar, like the LLM just has nothing, has no choice, has no say in the choice of a database. You just have to use what you've been given? Or is it about choosing a database that you made it use Very, very well?

[00:06:00] Moar: So I think one of the advantages of building Base44. Uh, I would say late to the game is the fact that, uh, we really designed a lot of the things around the LLM.

[00:06:15] Moar: So basically for obviously employees, uh, concept called backend as a service, uh, which is like for, for the devs probably familiar with like Firebase or SuperBase and so on. Um, but those are like products that were built pre the LLM era and had their own like endpoints and syntax and so on. And so when, when I started Base44 and started kinda like building the first couple of apps, and so you see what the LLM uh is trying to do.

[00:06:45] Moar: And in some places like you try to like limit it further. So you tell it like, Hey, don't use those packages. And it tries to use those packages. So, so you like try to, I dunno, write in the prompt. Important exclamation point, exclamation point ex, but like don't do that. Or when the other way around, which I think worked really well for us is like.

[00:07:05] Moar: Just, uh, uh, run with it, like see what the LLM is trying to do when it gets confused and build it almost in the same syntax that it's using. So, for example, if it's constantly using like one package over another, uh, you trying to use the other, but there's no real difference between those two. Maybe the, the tech stack will be, should be built with package A.

[00:07:28] Moar: So in some places, sometimes it's better to just, uh. Go with whatever the LLM was trained on. 'cause it'll likely bring you better results. And I think a lot of the design of our SDK, our backend services, the packages, the tech stack was more around, uh, what LMS are really good at doing and ID code with.

[00:07:53] Moar: And I think this was an important decision. 'cause again, when you are looking to create like really complex software using LLMs, which obviously as we all know in the space LLMs are struggling with. It's important to take away as much of the complexity from the LLM as possible. And if you can make it easier, so think about it as like, think, uh, if you would need to give like a very long and complex speech right?

[00:08:20] Moar: Obviously it'll be easier to speak at your native language. And so that's what, that's what they try doing with the LLMs like trying to understand what's the easiest way for the LLM to create functional software. And then build the tech stack, design SDK, design the endpoints around that.

[00:08:37] Guy: Yeah. Yeah, it makes a lot of sense.

[00:08:39] Guy: And it sounds like it's a bit of both of the things that I talked about. There's some backend service that is outside their, the scope of the LLMs decisions, at least as you build a Base44 application. And then on top of that, you have the, uh, the, the sort of the choice of stacks that, uh, go with, uh, go with the flow or go with sort of the, uh, uh, I guess kind of prevalence and knowledge and the,

[00:09:02] Guy: uh, and you've, uh, we're gonna talk about your own tech stack, but you've chosen Python, for instance. Yeah. And I, I'm, I'm guessing that's sort of a similar logic of like Python was the language the LLMs are most proficient at..

[00:09:13] Moar: Yeah. For backend. Yeah. Um, for frontend, there's also some, uh, controversial decisions that I've taken.

[00:09:22] Moar: So one of them is, uh, LLMs are having an easier time using, uh, writing JavaScript and writing TypeScript. Uh, they get confused, uh, so like some of our, a lot of our frontend still reading only in JavaScript, which could, uh, can shake, can shake some.

[00:09:42] Guy: There are, there are firm opinions about this in, uh, in the, amidst the technologists.

[00:09:45] Moar: Yeah, I'm sure.

[00:09:47] Moar: But also, like things change, right? Like, um. I think, uh, if we get back to like, uh, in the places where you actually limit LLM or you say Okay to L okay, this is the building block that you should and, and can be used, uh, uh, like you should use, and nothing else be besides that. So, yeah. So as you mentioned, uh, what you guys have seen in Tessl is like LLM get better and better or change and adapt.

[00:10:10] Moar: And in some ways, like, uh, even in that. The tech stack that people build up in Base44 these days, like as LLMs progress, we take away some of the, some of those guardrails to allow the LLM more flexibility.

[00:10:25] Guy: Yeah. Yeah. Makes a lot of sense. And the, uh, maybe let's just sort of. On Base44 still kind of as a user base.

[00:10:32] Guy: So the target audience of that is, is what? Is it non-developers? Is it developer adjacent, but technical people? Or is it none of the above people that are entirely non-technical. Who did you build it for?

[00:10:44] Moar: Definitely for the non-technical people. Um. First couple of users, were like a restaurant manager, a marketing guy, like some of my best friends, right?

[00:10:55] Moar: But I have no, their connection to code was, uh, something distant. Yeah. Um, but I think what's surprising to me is that at as time goes, I see more and more like there's like big community of like developers using Base44. And obviously as same goes, we we're developing more features for like semi developers, people who do understand.

[00:11:18] Moar: Like, uh, some technicalities. Uh, but I see a future where, where it's like it doesn't matter anymore. It's like, um, if you look at like building a landing page or a just a landing page, right? Mm-hmm. Uh, think about it before the age of LLMs, right? Um. Obviously at some point, even if you are a developer, it would be easier to use Wix than to code a landing page, even if you do know like HTML, PHP, whatever and host it and deploy it and whatever, like nobody wants to do that.

[00:11:52] Moar: Um, me, myself, even before, like, before LLMs and vibe, coding was a big thing. I've built my, uh, my girlfriend's website using Wix. Right. And I think in some ways for a large portion of software that that's what we'll see. So even if you're super technical, it'll be an advantage when you are vibe coding stuff.

[00:12:13] Moar: Mm-hmm. Um, but it won't matter that much. Like, it, it will be clear that, that that's an easier choice than to open up a new GitHub repository, start writing code, right, deploy it, run tests.

[00:12:26] Guy: And why, but how do you, how do you think about, so for the non-technical user, trying to think about the sort of the lines, right?

[00:12:33] Guy: So if you're, uh, a developer, I think a lot of vibe coding, whether it is in platforms like Base44 or if it's things that you do more locally, the Cloud code sort of, uh, Cursors of the world. Um. You in, in those worlds, you have a very tight relationship to the code. Uh, the LLM modifies, the agents, modify the code, but when there's a problem, your sort of supervision happens on the code.

[00:12:57] Guy: I think in Base44 you can see the code, but it is, it is a, a kind of a hidden entity or it is not, it's not designed to put the code in your face too much. How do you, how have you seen and what maybe there's like learnings, learnings about how you have built for people who don't understand codes to be able, you know, to, to interact and get the system over the hump when it fails to deliver something.

[00:13:23] Guy: Right. When it fails to accomplish something, is it all just like, give it more guidance? Give it more guidance and, and hope it gets it right?.

[00:13:34] Moar: Not only, I think the interaction when you are building an app in Base44 versus, for example, if you're building an app using Cloud code or Cursor, it is a different interaction and, and many times it's a different user and a lot of times currently it's a different piece of software.

[00:13:50] Moar: So I'll start with obviously the way that, um, Base44’s users do iterations and experimentations and so on. Has a lot to do with visual. Like you see the app in front of your face, you know, if something is wrong, you'll see that in the interaction or you'll see a bug being thrown away or something like that before you even look at the code.

[00:14:12] Moar: Um, I think platforms like Base44 still, there's obviously like a limited. Set of software that they can build. Um, and this, this set is gonna expand further and further and further as time goes. And that's what we're working on. But it's still important to be very honest and say there's a set of software that you'll be better off building using Cursor than, than, than using Base44.

[00:14:48] Moar: Um, so for example. Base44 itself, put aside the font end, which is obviously built using Base44, but the backend for Base44 is not built using Base44. Right? It's like built using Cursor and Cloud Code and so on. Um, because you need to look at the code and you need to understand the code. And so yeah, this whole thing, like this is the situation and reality right now.

[00:15:00] Moar: I think this, this will aggressively change in the next few months even. Definitely few years, again, as, as you'll be able to visually or, or like forms only, uh, without looking at the code, you'll be able to build an increasing percentage of the software that you're currently building,

[00:15:23] Moar: Um. Yeah, so the tools that we're giving our users are a different set of tools to how, how they experiment and iterate with those software.

[00:15:33] Moar: It has to do a lot with visual. You have to see the, the, the application all the time. It has to do a lot with trying to explain better what's going on. So for example, we have this, uh, small feature, but people really love it. Well, when you prompt something in Base44 and it starts coding, so obviously we.

[00:15:52] Moar: Like, most of our users don't wanna see the code. It's just, it's terrifying for them. So they don't understand what's going on. And so we have another small LLM that basically watches the coding agent see what it does and kinda like explains to you in real time, like, what's the coding agent currently doing?

[00:16:10] Moar: And like a small, like now it's, uh, changing the. Uh, a UI from light theme to dark theme and whatever. And so yeah, we're building a set of tools to help people build software without the need to look at code.

[00:16:23] Guy: Yeah. Yeah. That's so smart. Uh, progress indications, it's a, and, uh, and engagements are sort super important.

[00:16:28] Guy: So I think that makes sense to me. If I echo this back, I feel you're saying, um, there, there's sort of the two domains, maybe that Base44 today is most helpful are cases where. A lot of the validation and a lot of the decisions are much more product oriented and a lot more visual, specifically oriented.

[00:16:45] Guy: Uh, and, uh, as opposed to sort of technical and how did you implement. And the second is that maybe a lot of them are, are places where that visual is also the innovation. Like a lot of the technology, you're not looking to, uh, make a product that sort of works. That's not some sort of the world's. Fanciest progressive web app that, uh, does a lot of things.

[00:17:04] Guy: A lot of your, your creation is a lot more about the content, uh, the navigation and all that might be sort of. Similar and common. And so the LLMs know how to do it well, and you can do it very efficiently, but you're innovating on sort of the, the content and the looks, uh, more, uh, is that, does that sound fair?

[00:17:20] Guy: And then it will expand over time.

[00:17:25] Moar: Definitely. But I'll add on top of that. I think it has more to do with the type of software that you are building, right? Mm-hmm. So if you are building nowadays something that that's like, performance is super important. Right. Like you can't vibe code your way through it.

[00:17:41] Moar: Like it's like if you're building, I don't know, a VPN software, let's take this for example. Um, yeah. So obviously like it's, it's gonna be really hard or something that relies very heavily on like backend and stuff like that. So yeah, a previous company probably can't vibe Code Snake. Yeah. Uh, at least not yet.

[00:18:03] Moar: Uh, I think for other set of applications, it's not necessarily the visuals, but more of like if you are building an application that. That can do what it needs to, to do with a database set of integrations, APIs, and so on. Um, I think like you, you'll be like, you can do a really good job using Base44 and it'll likely be a, an easier experience and try to code it via Cursor.

[00:18:31] Moar: Uh, so it has to do with like. The low levelness of stuff and complexity on the backend side. Uh, but we are getting better at that.

[00:18:41] Guy: So, uh, I have one more question on Base44, but maybe let's first switch to how you built it. We'll talk about your stack and then we'll combine a little bit. I'd like to, uh, touch a bit on, on longevity, like building a disposable app.

[00:18:55] Guy: I think you're creative doing it versus what do you build for long term, but take us behind the scenes. It like, so you've built, you know, like single person build substantial llatform and also scaled it. Uh, I guess tell, tell us a bit of the, uh, of the tips and tricks. I heard you shared a few of, you know, what, what helped you, uh, create that?

[00:19:13] Guy: And maybe start it with like, do you think you could have done this? I know you used ai, your creation, like, was that critical? Do you feel you could have pulled off a Base44 without AI dev help uh, as a builder?

[00:19:27] Moar: Uh, showed and so is definitely not. uh was least not in the same structure and way that I did it with Base44.

[00:19:35] Moar: So when I started Base44, even before. Knowing what I was gonna do, I knew that we're in a different era. I've been like leveraging ai, working with AI in my previous company, both as like AI inside the product and also coding with ai. Mm-hmm. Um, and I felt like I felt strongly that we're in a new era where it doesn't matter the number of people building software anymore or matter about, like if you have a unique take Unique product, kinda like,

[00:20:06] Moar: uh, and you can design well, like design software. Well not,. I'm not speaking about like UI design then It's not anymore about like, Hey, throw as many people at the problem as you can. Those people will write more code faster and that's why you get to, so I was like, I'm gonna do this alone.

[00:20:24] Moar: From day one. I'm gonna set up the repository. And spend 20% of my time content constantly on how can I further, uh, increase the velocity and speed. So a lot of what I did is like experimentation with how will the lamp write, uh, code better. Obviously I did it for Base44’s product as well, right? But. But even for my own repository, right?

[00:20:48] Moar: So I find those tips and tricks as like what I, I've spoken about, like JavaScript versus TypeScript. Maybe now it's changing with Cloudflare and so on. But back then it's like I could write, uh, front ends, like the speed of light, uh, just because of the setup. Uh, another thing is, is I've built this from the backend side.

[00:21:11] Moar: I've built this very high level, uh, infrastructure. Uh, that handles like the database and user management and so on, so that even if I would've pivoted to a completely different idea, 80% of the code would stay the same. And so I had this like, really good infrastructure. Um, that stayed the same. And tho that's what those were, like the parts of code, that it was slightly more me than the AI actually writing and making sure that it's perfect and form that once you have those infrastructure, right?

[00:21:43] Moar: And so now adding a new feature that I don't know has like a new table in a database and has some intera, some interaction with, uh, with other parts of the platform became super easy. Uh, the way I would measure that is for the LLM to implement a new feature. I wanted to write at, uh, at the least code possible to implement the feature end to end.

[00:22:04] Moar: And so I built a lot of like those things obviously, and, and the rules and so on into the repository so that I could run on my own but still keep the same velocities, my competitors, if not even better, faster. And I think, I think to some degree I've done that. Like I think that the competitors in this category are super heavily funded.

[00:22:28] Moar: Um, and in many ways and aspects there, Base44 executed, uh, extremely fast, if not faster than, than a lot of the players in the, in the category. And I give a lot of credit to the AI, like most of the credit is to to AI of like getting, uh, yeah, I wanna thank it,

[00:22:49] Guy: It's like a nose car. I get the. I think, uh, so, so, so I love that.

[00:22:45] Guy: I guess, again, kind of echoing back a little bit, I think, you know, the first thing you're sort of touting is like the value of a good architecture, uh, where you anticipate, uh, what would be future changes. And you write the ability to write compartmentalized code. And I guess I'm, I'm hearing something that is almost similar, like.

[00:23:10] Guy: To hiring either junior developers or outsourcing, you know, places in which if you build the right architecture, then you can have clear instructions to someone else who's maybe a little bit less trustworthy, uh, to write pieces of software within it, uh, and be able to assess whether they've done their job well and be, uh, I guess can be able to, to guide them.

[00:22:34] Guy: Does that sound like a, a fair analogy?

[00:23:36] Moar: Yeah. Yeah. Exactly. 'cause also one, one other thing that like I've noticed is like when you are leveraging AI for coding, so think about it this way, like you, let's say you are building like a simple. Full stack web app, right? So, uh, you tell, hey, I want it to be, um, a to-do list up or whatever.

[00:23:55] Moar: So the AI implements like some of the routes and connects the frontend and so on, and then you open up a new chat writin carousel or something and you wanna implement another features like write an admin panel, so on. Uh, so it'll look at your code and it'll do the task, but, and AI is really good at that, but AI is not.

[00:24:14] Moar: Really good at stop and saying, oh, you know what, there's actually like common concepts here that I could like, uh, combine to like, uh, this infrastructure or package that I can later use in other features. And, oh, I'm writing the same code again and again. Like, let's stop. And before I do, like the, the task that you gave me, let's kinda like implement that.

[00:24:36] Moar: yeah, let's refactor the code so that I won't need to write as much code and so on. So I think this is something that a lot of developers currently don't notice about ai. Like it will, it'll implement the task as you told it to, right. But it's still lacking the, Hey, let's stop for a second.

[00:24:50] Moar: We need to refactor the code because I find this common layer or whatever. Uh, and I think that's, that's, and so those, that's nice.

[00:24:58] Guy: that's something you still did manually. Like you would observe what the AI has built and you would kind of go off and, and modify.

[00:25:05] Guy: A lot of, a lot of what we see with AI, which I think touches on the topic you said right now, is. It's about the initial creation. Right. And it would go off. Yeah. And even there you sort of see this sort of reward seeking, right?

[00:25:15] Guy: It might burn down the house to sort of be able to accomplish this thing that you've just like break all the other features, you know, just to be able to make Yeah. This feature you just asked it to, to make it work. But, um, but, but the other aspect is indeed maintainability. It's indeed code duplication.

[00:25:30] Guy: It's all these things that are sort of bad practices. Uh, when it comes to sort of quality software creation. Um, so I guess I'm asking, uh, like I, I think you've, you, you did it on your own in Base44 for your code base. How do you think about that in terms of building applications that are built by Base44, um, to, to have longevity?

[00:25:32] Moar: So in two ways. One, when you build an up in Base44 these days, like. There's a lot of infrastructure and setup that happens before the LLMs even writes code. That in some ways limited, but not really. Not in terms of like what it needs to, but it's kinda like, it, it, those are guard rails that the LLM should keep.

[00:26:15] Moar: And as long as it, it keeps that, then, then it should be fine to some degree. Um, so again, we automatically create the entire, uh. Uh, read, update, delete, uh, kinda like the Crud SDK. And, and we make it like really good and we implement like rate limits on top of that and things like that, that LLMs wouldn't really care about.

[00:26:18] Moar: And when you leverage, um, I don't know, APIs and integrations and so on, like we keep a very strict schema. There's like a lot of things that we implemented built into the application. So did LLM. Won't kinda like be this reward seeking of like, I'll do whatever, but I'll, I'll keep your app exposed and, and so on.

[00:27:00] Moar: The other one, the other thing is yes, at some point, uh, we automatically feed back the LLM, whether the user knows about it or not, that it needs to refactor something. So for example, uh, one of the things that makes LLM confused the most. Um, and people feel that it, like, cause the, the, the vibe coding category is, uh, when they're saying like, Hey, I asked it to do something.

[00:27:28] Moar: It didn't do it, it did the opposite. It deleted a feature or whatever. Um, is when code files are are getting too long. Uh, right, right. If, if like you've implemented, so you ask it initially or early on, Hey, implement this page, create a to do list up, and it did something simple. It's like a very simple to do list up, like in any other react, right?

[00:27:50] Moar: And then start layering in features, right? So LLM does. What, what he asked it to. And, and it start adding like, uh, AI features to write the tasks, the description, and then uh, user management to like assign different teams and both and whatever. And at some point you have like, if you are not careful, you might have like this very large code file, right?

[00:28:11] Moar: So one of the things is like we are running behind the scenes. Refactoring tests, uh, to maybe tell their LLM, Hey, like, you passed the threshold, you should now refactor this file. Even if like, okay, the user ask you something first, refactor the file, then implement what the user has asked you to. And I think like there's a lot more to do there.

[00:28:30] Moar: But yeah, it's somewhat of like this, uh code quality agent that that's keep nudging the LLM at some points. If it finds that it's best efficiency threshold of like, hey, like there's this code here and this code here, like do something refactor that.

[00:28:46] Guy: Yeah. Yeah. It makes sense. I think, um, hey, a couple of questions about specs and tests.

[00:28:52] Guy: So we, uh, you know, we talk a lot about specs here. It's kind of Tessl’s, uh, uh, kind of a claim for existence of it, you know, products coming soon. Uh, and, uh, and you know, we, uh, I think in general there's also like growing appreciation in the, in the world of AI development that you want to capture knowledge that's outside your code or summaries of it.

[00:29:16] Guy: And then test as guardrails. I guess how do you, how have you used maybe tests for sure, and maybe specs, uh, as part of creation in Base44, people start with tests even, right? Like how do you, how do you think that tests?

[00:29:31] Moar: Uh, I think just like. Like, the way you guys think of Tessl, I think is like software is changing, right? So some of the paradigms that we've built, uh, throughout the years are not really relevant anymore. Uh, some of them become like more relevant, but even if, like, if you look at, uh, test driven development.

[00:29:54] Moar: It'll likely look like, look very different. So in the first few months of Base44, there were no unit tests. Um, there were like very different tests. Uh, so a lot of the tests were an actual. Agent going into a browser, opening up a local host, like a local version of Base44 tries different features. And the way that I write tests would be like prompts saying like, Hey, when a user first logs in with a new like, and that's a first user.

[00:30:27] Moar: Make sure this popup exists. Uh, go into the, like, go into the homepage, write a prompt, uh, run it. Then, uh, you should see in, in less than three minutes, you should see like this and that. And so a lot of the tests that I built early on inside, even before Base44, to keep velocity high, but still maintain a quality piece of software or like end-to-end tests.

[00:30:51] Moar: Um, they are not even, like, they're not written with code. It's like more high level tell an agent going to a browser and test it.

[00:30:59] Guy: Interesting, is there a reason for tha, was that just sort of reality you needed the end-to-end tests anyway and then, so you might as well spare yourself the uh, the needs to, uh, to create the unit test?

[00:31:10] Guy: Or uh, or is it sort fundamental like, I don't think units has the right for it 'cause I don't care about the implementation as much.

[00:31:17] Moar: So, yeah, 'cause implementation changes and so I was changing the code so much throughout the day that like keeping a set of unit tests would've been more of a headache than like, uh, that you constantly need to refactor or, and you constantly, and so what you wanna, like, at the end of the day, what you wanna make sure is that your code works and when, when it doesn't.

[00:31:39] Moar: That you can easily get to the, like, what doesn't work, right? That's some of the power, some of like, the reason behind unit test is like, it's easier like to understand, oh, this unit fails so we know where even in the code is a problem that you're having. Because otherwise, like, okay, just write as as many end-to-end flows and if those worked, then your, your software does what, what it should be doing.

[00:32:02] Moar: Um, and so I think that's why a lot of, like at the first few months when I was refactoring so much. I was like, I found this way of like doing end-to-end test that really is scalable almost as if you had like a team of like manual QA engineers. Uh, that you could go into your software and change things.

[00:32:22] Moar: Obviously if you wanna scale and you wanna work inside a team. Unit tests are important. They're like, they're, they're explaining some of the things that that should happen with your software, and especially when, when backend becomes like really, uh, large and complex. Um,

[00:32:41] Guy: so, and, and these are this way that you found to sort of run the end-to-end test. Was that also AI powered? Is that sort of

[00:32:45] Moar: Yeah. Yeah.

[00:32:47] Guy: Browser based. Uh, hey, find a button and press the button and such. Yeah. As opposed to telling it whatever the dom id

[00:32:55] Moar: Yeah. And, and when you Absolutely. And when you're changing the UI A lot and so on. And it's more around the logic. Mm-hmm. And AI agents running browsers nowadays are, are pretty good with the logic.

[00:33:07] Moar: So even if, like, I remember, like, I remember UI testing used to look like, uh, you'd have like this, um. HTML selector like, like a jQuery selector. Well to find a button, then you change something, the whole test would break and you'd spend like 20, 30, 40% of your time just, uh, refactoring the tests right after you change the UI a lot.

[00:33:27] Moar: And so, yeah, I think I'm still wrapping my head around this. I'm not sure that we're doing a great job with like rethinking how, uh, things change as AI is writing more and more code. Yeah. I think also part of it is like. Um, part of like, the reason why we haven't, I haven't built a lot of like unit tests. Uh, starting on is, is again, AI does a really good job with also identifying.

[00:33:54] Moar: If you tell it what the bug is, like it'll search and it'll try and understand and you'll get really fast. You like. Where does this happens? I think that's also part of the reason why I haven't invested a lot of time in unit test. Yeah. Uh, but I'm not sure this is like the right, yeah. I will tell I'm more like I have stronger opinions on, on other stuff.

[00:34:14] Moar: I'm not sure we've yet to correct. Uh, testing. Uh, yeah. And how it looks like in this new.

[00:34:21] Guy: And how, uh, how have you, how do you think about specs or sort of, I guess docs are the sort of, the more core, did you find, uh, that you got benefit from creating documentation in a more standard way? Uh, I guess what, uh, what has been the experience?

[00:34:37] Moar: Yeah. Um, this is really interesting. I think angle and space, as I see also a lot of, like the, a lot of like Base44’s users users. Sometimes I see what they're doing is like, they'll. Go and chat with chat GPT. They'll build like some sort of like a PLD or, or something like that, or a spec of like what they're looking to build.

[00:35:01] Moar: Um, and only then they'll upload it to Base44, because Base44 is slightly more. Uh, tipping towards action, I'll say. So even if you say, Hey, like, let's chat a bit about the app that, that we want to build. Maybe. We'll, yeah, yeah. Maybe. We'll, we'll add this stage before creating an app. Like if you want to just chat about it before and create some, uh, spec, and then make sure that throughout time as you build your app and adapt it and whatever, like the LLM constantly sees and validates that the spec.

[00:35:36] Moar: Is still like, still happening in reality. Uh, I think that's also one of like the top requested features that I've yet to wrap my head around as to how to approach it is like, have some sort of like a spec of what your app should be doing, and then even if you, like, when you ask the LLM to make it pretty or change the button or add functionality or whatever, it should constantly get back to the spec and make sure that it's not, does not override or changes anything.

[00:36:03] Moar: Because obviously as many people know, this is the biggest pain right now with vibe coding. It's like you ask it to do one thing, uh, it might not entirely understand you and, and it did it, but messed up another thing or it didn't do what exactly what you, you wanted. And so yeah.

[00:36:20] Moar: It does, yeah, again, two places, tests and, uh, and specs that I feel like we could be doing a better job.

[00:36:28] Guy: It’s still horizon, you know? Uh, yeah, both, uh, both on Base44 is its own app and, and in the apps created on top of it. Let me, you, you, you actually, uh, touched on something I wanted to ask, which is about team members.

[00:36:40] Guy: And so, uh, this has been sort of super interesting. You built them, uh, also. You can zig and zag because you know, you're just you. And so the LLM changes, you change your opinion, you feel like a thing. You don't need to convince anybody else or align them. Uh, now, you know, post-acquisition, um, I guess maybe first it's a question like how, what do you anticipate will happen?

[00:37:03] Guy: I say anticipate you, you have a plan probably in terms of growing the team. Do you still think, Hey, we're gonna be three people, you know, we'll triple the size of the team, or, uh, or do you think you're gonna be 30 and then you know how much. How much is the methodology that you've described viable when it's a team that, or multiple teams that need to collaborate versus a solo developer

[00:37:25] Moar: My code thesis is that, uh, for building great software, now you need way smaller teams.

[00:37:35] Moar: It is not actually that, like it's actually that if you are smaller, you'll be like, it'll be easier because when you're smaller, you have more context. Right. I'd rather have someone that knows entirely the repository so that they can change multiple things at once. Um, well the way I'm structuring the team right now, so is, is keeping very lean and efficient in terms of like team member for every, I don't know.

[00:38:03] Moar: Million or two or $3 in ARR, um, and then having those team members. With as wide context as possible. So I don't want any more of like this, Hey, I built this part of the back and now I'm gonna hand it over to the other person that will build the user interface. We'll hand it over back to build like a different thing.

[00:38:25] Moar: Oh, now we have an info problem, so we need the third guy. Um, and so I'm trying to build a team very small. All of them have like a lot of context. And the way that I'm trying to manage the tasks is isolate as much as possible and like, have every person to walk, almost like as an individual. So take like big chunks of your product, hand it over to this person, this person's gonna walk mostly alone.

[00:38:54] Moar: Um, it's like, I don't want, I wanna see very few team meetings of like syncing on something because like. It can. Now, again, every person becomes, like if you hire 10 X engineer, nowadays there are a thousand X engineers because Yeah, they can. Like Throw as many AI coding agents as, as, as they want. And it's not anymore about, oh, this, this task is really big, so I should be putting like four or five people on it.

[00:39:21] Moar: 'cause again, it's not anymore about the amount of code that every person writes like cause AI can write as much code as you want to. Right?

[00:39:27] Guy: It's probably still a case for like, uh, for pairs. Uh. In, in the sense, at least for a single, like someone goes on vacation, right?. Or leaves the company or One, one person sounds, makes me like a little bit uncomfortable, but, uh, but I get the point about tiny teams, you know, that's a, that's,

[00:39:48] Moar: I agree. And also, like it's very hard to find some people also. They'll ask them with backend, but they also understand some design and they also understand some like front end concepts and so on.

[00:40:01] Moar: Uh, but as much as I can, I'm trying to like keep a small team and then the way they operate is like divide and conquer.

[00:40:11] Guy: Yeah. So, so, and you anticipate them working in the same fashion, give or take. Uh, and the solution to that is, is architecture. Uh, and, and just And setup. Yeah. Yeah. Which, uh, again, is actually not new.

[00:40:27] Guy: It's actually, you know, the way that you would scale, you know, the Amazon sort of two pizza teams. When I think about how we build Tessl, it is about okay, having software boundaries, having data model boundaries, and eventually even aiming to, to allow timeline independence of being able to ship whenever it is that you ship.

[00:40:44] Guy: And all of those are never perfectly correct, but they are, um, they, they are aspirational. Like you want to invest in ensuring those lines are are there, if that makes sense. Um. Let's maybe be off. So we're, we're kind of like tight on time here on it. Maybe we, uh, should we talk a little bit futures, like where this, like, we talked a lot about sort of, you know, past and present and I think we talked about like near future.

[00:41:09] Guy: Um, maybe I'll start with the big question of like, what do you, what do you envision developers being, you know, in, in, in one year, three year, or five year horizons? Like what, um, what is still in the realm of a developer? Um, you know, what do you think? Just entirely goes away.

[00:41:27] Moar: yeah, obviously I, I measure it as like the percentage of software. That could be built today with tools like Base44 and, and other tools in the category. Um. Again, I wanna differentiate between the, the Cursor and Cloud code of the world mm-hmm.

[00:41:51] Moar: That are obviously targeting developers, semi developers, uh, versus like the Base44s of the world that, that are targeting like the everyday architect, lawyer, physician,

[00:42:02] Guy: You're taking coding as literacy to a different place. And it's not coding as literacy, it's software creation as literacy. It is about making it available to everybody.

[00:42:11] Moar: Yes, absolutely. So I think then, obviously the percentage of, of software that could be built, uh, is going to increase tremendously. Um, two places that I find that, that really, at least I'm putting a lot of focus on is on the enterprise side. Uh, so again, if I'm putting it on like a timeline, so Vibe Coding has started building great websites.

[00:42:34] Moar: It was really fun to see that you can build a landing page, maybe some interaction, but great with front end. Um, and then Base44 targeted a lot of like, build a functional app, like project management tool CRMs, invoice management apps, stuff like that. Um, seeing now more and more organizations.

[00:42:55] Moar: Adopt Base44 to build like internal tools to build back office systems to build like things that they used to like pay a lot for like custom software. Um, and then, so there's two vectors that we really need to get better at, like as a category. One is the enterprise side of things like. Build enterprise grade applications, uh, that can really transform the way organizations are being built.

[00:43:20] Moar: Every large organization has tons of software needs, and I think like a small percentage of it is like customer facing. But a lot of it is like, think of an organization like, I don't know, uh, Pepsi or something like that. Like how much software do they need? Internally to run this, uh, to this business.

[00:44:40] Moar: And the more the merrier, right, the model that you build tools, the more that you build automations, uh, the more that the business becomes more efficient. Um, so there's a lot that yeah,

[00:44:40] Guy: Uh Challenge, like I don't actually wanna challenge that. I agree with it, but I think there is a thesis that says. Um, yes, a lot of like the, uh, enterprise automation is a massive opportunity.

[00:44:02] Guy: Just think about how much grunt work happens and how much inefficiency happens that you, if you could just easily create software to create, we'll make it go away. But there's, there is a thesis that says, uh, well, you wouldn't create applications, you will just delegate those tasks to agents. And so you wouldn't create code that, that lives as an application the way we perceive it today, you would more outsource it to AI.

[00: 44:26 Moar: So that's the second thing, which is, um, lately I've been telling the team that, uh, vibe coding is awesome. Obviously made me rich, but, uh, it's constantly great at building software the way it used to look pre 2022, 2023 when Chat GPT came out. Um, it's still very hard to build Agent applications. Um, and I think a lot of like the value in software and the latest like groundbreaking software, and Base44 is a good example of that.

[00:45:03] Moar: is gonna become like agentic software. Um, and I think we'll find that it's not only chat and like connect tools. There's like something to connect them. Uh, you can see that in coding agents in the UX and whatever is like, um, there's some interaction, but it's different kind of software. And so the second thing that, that, uh, Base44 is gonna invest a whole lot in, and we'll see a lot of like updates in the near future is helping everyone.

[00:45:32] Moar: Build agentic software. Uh, an agentic software could be a software like Base44. It could be that the CRM that you just vibe coded now has an embedded agent that can research leads, can send you some updates before a meeting can enrich some data. It can be that the support ticketing system that you've built internally for your SaaS company will now have an agent that auto replies and gets trained on like human responses and you'll be able to actually vibe code.

[00:46:01] Moar: Uh, this whole application. And so, yeah, I agree with you. Definitely. I think there's like a combination of like things that, like enterprise grade you need either way, whether you're building a nice looking, uh, uh, web app or an actual agentic Web application. Uh, but yeah, the other thing is like taking vibe coding to the place where you can build, create agentic applications

[00:46:23] Guy: So with all of these advancements and all the capabilities that Base44 is building, like what's your prediction about how long does it take till you can build a Base44 with Base44?

[00:46:36] Moar: Hmm. Um, that's a good question. And it also has to do with like how. Like how much will we, we will be able to correct this agentic application thing.

[00:46:50] Moar: Um, my guess is like a fully functional Base44 app with like payments and credits and like actually coding agents without coding like websites inside and so on. Uh, about six months. Six months, maybe less. Yeah, I'm looking like, I'm looking at sometimes it's like, uh, I'm looking at the state of where Vibe coding and Base44 specifically was at six months ago and it was just terrible.

[00:47:23] Moar: Yeah. And so I think six months, maybe less. Uh, definitely I would say not more than a year.

[00:47:29] Guy: Yeah. Yeah. I mean, it's a good, it's a, it's a bold claim, but it's, uh, it's one that I can, I can get behind. And I think, I also think that, uh, it, it, not anybody could create Base44. Like you, you'd need certain sort of skills and competencies to be able to achieve it, but maybe you can use it with those tools.

[00:47:48] Guy: Um, and I, I guess in that context, like what is, uh, the long-term differentiation, you know, for a platform like Base44. Given this prediction.

[00:48:03] Moar: You know, yesterday, I, I think yesterday, two days ago, I tweeted about something that, that was like insane to me where we changed like one line of code, it's like change the string and we moved 400K.

[00:48:16] Moar: Uh. Workload for like $400,000 from one LLM vendors to another. And I was like, where's the moat? Like this is insane. 'cause like you see those companies and they're really growing like nicely, but where is this all headed? If, if everything becomes a commodity and maybe models at some point become a commodity.

[00:48:36] Moar: So I think the model layer is in slightly more problematic way. I wouldn't even, I wouldn't actually call it problematic. It's just, it's very easy to switch. So there's no real moat but the top players are just printing cash.

[00:48:50] Guy: Yeah. Uh, so I think it's hard to enter that group now. Yeah. And move between the group.

[00:48:54] Guy: But it's harder to imagine someone entering the group now. Yeah. But it's gonna be, it's gonna be a very interesting, um, market. 'cause it's unlike, uh, the cloud.

[00:49:06] Moar: Uh, let's say vendor. So obviously it's also a very hard, uh, uh, ticket to get in, but, but it's also very hard to switch between clouds, right? It's very hard to take your entire setup from Microsoft Azure to AWS. This won't be the case between models. 'cause, uh, like, uh, when a new model comes out and it's slightly better than for me, it's like, yeah, I'm gonna spend like five minutes and change to, and move like hundreds of thousands of dollars a month.

[00:49:33] Moar: Uh, and probably in the future, even more from one vendor to another. Um, where is the Moat? There’s many places. So one just being ahead, right? If you’re four months ahead of the competition these days, it's, it's very important, right.

[00:49:50] Moar: So I, I know, yeah. I know that some of the, some of Base44’s competitors are gonna come up with like a built-in backend and batteries included, kind of like approach of like seeing, uh, kind of like what it does to Base44’s users,

[00:50:04] Moar: But at that point we'll already be like further ahead. Um, and so yeah, just velocity is the, I think the number one, um, moat, but there's also brand distribution community. I think Base44 is likely to have the strongest community that I've seen, uh, it's like users are absolutely fantastic and they help each other.

[00:50:26] Moar: Um, and yeah, there's still some places where. A unique product take that's hard to replicate, um, is insanely important. Uh, so if you can, like, again, for me, and not to sound too cocky, but like, I was like, okay, there was this problem with building functional apps in vibe coding and for building for like the non-technical person, I can.

[00:50:58] Moar: envision, how this experience should look like. They should just type something. They don't need to understand what a database is or whatever. Everything will be built. And then translating that into how to implement that from a text perspective, uh, and in a scalable way. 'cause like people build, I think tens of thousands of apps nowadays.

[00:51:17] Moar: And so how do you scale that and, and hold this whole thing and the backend and whatever, like, how do you do that? There's still some technical mode.

[00:51:25] Guy: make good decisions. Yeah. And execute on them fast.

[00:51:28] Moar: Yeah. And and it's the same, same thing, right? Yeah. It's the same thing. 'cause if you make good decisions and great decisions from an architectural standpoint, then your velocity will be. So I think that's a, that's a big Moat.

[00:51:40] Guy: Yeah. Yeah. Yeah. That's good. Sounds like a. Uh, a great kind of, uh, equal cry, almost like you do have the brand, you do have the distribution, so especially now within weeks. And so it's not, um, it's not an equal playing ground, uh, yeah, but it is, uh, more equal maybe than ever before, uh, as you've, uh, as you've demonstrated.

[00:52:04] Guy: Um, so I guess maybe just as a, a, a final, uh, question here. What's the sort of the top advice you'd have for developers listening, uh, to this podcast? Like as they, as they brace themselves to this sort of insanity that is engulfing us, uh, and change. What's, what's sort of the top advice, top advice for developer today?

[00:52:26] Moar: Um, the way I think the future is headed is that people who can jump between domains, so at least understand a little bit between domains so that they can execute with AI agents. Uh, things end-to-end will be more successful than the people who are currently very deep into something.

[00:52:49] Moar: Uh, so there's like a great frontend developers that understand the ins and outs of of React, I think that won't be as valuable as people who can execute end to end again together with AI agents and have some understanding of frontend, great understanding of backend, some understanding of of design, some understanding of like UI and can take something, either a feature or build a product themselves and can lead that end to end.

[00:53:19] Moar: So my advice for, for, I think for developers and what I'm advising some of my friends, like, take a step back, go and build something end-to-end. It'll teach you more about the other places that you haven't touched yet, like product and design and, and users and community and whatever. Uh, depends on, on where you're at and what type of developer, uh.

[00:53:42] Moar: You all, um, but take a step back. Try to build something. Uh, 'cause I think the future will belong to, uh, people who have some understanding across domains. Um, yeah. 'cause then you'll have AI agents specializing and, and deeper understanding of syntax is not, uh, an advantage anymore. Like those agents will know, the LLMs will know way better than us, what's the latest and greatest packages, how to use them, what's the syntax and so on,

[00:54:10] Guy: Right. Yeah. Yeah. Super, super interesting. You know, basically like elevate yourself up, uh, the, the list and you know, we talk about you need to either move up the product manager route of understand product better or move up to architect route of sort of understand Yeah, sort of system architecture. But either way you have to broaden, uh, the perspective more.

[00:54:29] Guy: Uh, this was excellent. Thanks a lot for coming onto the show. Massive congrats on, on the incredible journey, which I understand is just beginning still a lot of work ahead, uh, which I look forward to, to following, but. Thanks, uh, thanks for coming here and sharing all these insights.

[00:54:44] Moar: Thank you guys. This has been awesome.

[00:54:47] Guy: Uh, and thanks everyone for tuning in and I hope you join us for the next one.