Vibe-a-Thon: A Practical, Step-by-Step Guide to Building Apps with Vibe Coding

Well, hello, hello. Oh no, bad hair day. Whoa, hi, it's a different camera. Hi everybody, welcome. I gotta change cameras, um, hold on. I can't see it because my camera's in the way.

Let's see.

Hello, good to see you. Hello, my friends.

Oh, there we go.

I got it.

There we go. Oh, wrong one. Uh, oh, it's not plugged in. Oh my goodness, that's why. All right, hold on everyone, I'll be with you momentarily. Alexa, office. I was gonna say, careful, everyone's Alexa is gonna go off. She tells me today she doesn't support it.

And you're like, but, uh, but if I tell her to turn the lights off, she will.

Yes, it's crazy.

Alexa, lights off in office.

All right, all right, I guess I'm gonna use this.

Going back, going back to the camera.

Hello.

It's gonna be hard because I have to look at you here, but I'm actually—

it's not a great angle.

See, fire sign, someone's no takers in the house. Keon, what's up? Uh, all righty, welcome in everyone, welcome, welcome. We're gonna have to figure this out. Uh, maybe I'll just move you all to this computer. That'll work. There we go, there we go, that's better. Now I can see you all.

Welcome in.

Hello, hello! Today's a fun day. We're gonna do some vibe coding. So I, um, I guess it was 2 weeks ago now. Um, yay, Sonia's here! Um, I know, Sonia, we should have like planned, but we're gonna just go with it. Uh, so I'm excited for you.

I know, Noelle.

I was gonna say, hopefully you're not too nervous. Um, and the timing, like, we should have done it earlier anyway. Um, but that's fine, that's fine. It'll be exciting.

I'm excited for it.

Um, so a couple of weeks ago I actually did— I guess it was our third Vibeathon in person and was super excited. I came, I shared it, uh, with you all in one of our calls, and, um, Somia was like, hey, I actually built something, uh, that could be helpful to the group. And I was like, great, let's just show it. And so we two weeks put on the calendar and the time blew by and here we are. So we are going to spend the next 2 hours, which will be the time we typically would do for AI Leadership Institute. So it's our whole— all our communities together again. So the AI Leadership Institute call would typically happen now. Then we'd have a break, which I never— if y'all know, never take that break. I always run one right into the next one. And then at 4 o'clock, we have our I Love AI community call. But it's all the same. And I do just want to introduce it because And welcome. We are gonna do this live. So we will be recording this. It will be available. So if those of you wanna go back, sometimes when we go through, there are steps we have to do and you might not be in a position where you can go through all the steps. I don't want you to feel any anxiety whatsoever because you can go back and watch this recording. You can watch it on slow speed or super fast speed. It'll be up to you. Good to see you, Eve. What's up? So great to see everyone here. I'm so excited. And so today, really, I'm going to— first, I know I didn't give you any warning whatsoever, so, man, but hopefully you won't mind. These are all your friends here. We've seen you many times. But I do think it's great if you could talk a little bit about who you are and what you do and how you came up with this idea. And then, like, share with us what we're up for. I will make sure that if you need to share your screen, you can do that. I think it's enabled.

Oh, no, it's not.

All right, cool.

Now it is. So If you want to share your screen, you're welcome to do that. But, but we'd love to know like a little bit more about you, about your idea, and, and anything else around that you want to share with us.

Sure. So my education— thank you, Noelle, for this. First of all, I am nervous, but, you know, I, I know like your support is always there. So thank you for this. And Starting with my education, I am from an electronics and communication background, but I always wanted not just to build something but also understand problems from a business mindset. So I joined Deloitte. I worked there for 5 years as their quality analyst, but then came the AI wave, and I also wanted, you know, not just to be on the business side, but, you know, have a mix of both. So I I kind of started, I took a break from my career, did my master's in AI, but everything was so theoretical. And then eventually I started gaining, you know, the practical knowledge of it by joining your community, seeing the other people doing this. And that's where my journey began. I'm still learning AI. AI is kind of evolving every single day., and it's so fast. So this idea came from the fact that, you know, we all cannot learn everything and become expert in everything with the speed that the technology is growing. So it's better if I've learned something, if I've gained experience in something, I can share with the community. And that's how, you know, we all can learn from each other. So that's, that's the idea behind this. I've been bike coding for around 6 months, mostly to build my own personal projects to, you know, get a hands-on on that. And I, what I have seen is that earlier we used to, you know, when we used to learn a tool, it was like learning how to use it and how to, you know, become an expert in it. But today the tools are evolving faster. So what remains constant with us is the mindset of how we want to build a solution rather than just using that tool. So then I wanted to come up with this framework that talks more about the mindset and for for the non-technical people because that's what, you know, AI is enabling. It's democratizing this whole technology. So that's where this whiteboarding framework comes from. It's not like a set of prompts or instructions that you can directly apply and just, you know, come out with the same, you know, mass products that we are seeing currently that AI is producing, but it's more of how you streamline your own idea and how you can get yourself more immersed into it and, you know, build something that is really valuable. So yeah, that's, that's what about, that's about framework. I will share my screen and I'll just, you know.

Do we need anything? Like, do we need to have a piece of paper or a notebook or what? Do we need anything?

No. So currently what's, yeah, so I'll quickly, you know, walk you through the framework and how I have applied it to build a very small meditation app. Using my free account. Okay, so it's like just 5 credits, but I built an app that's running. So using this mindset, so I'll just quickly go through this, walk through this, and then maybe, you know, we can ask everybody to just sign up on any one platform that's out there and be as chaotic and creative they can be to see, you know, where the real challenges come up and then how this mindset kind of helps them, you know, or redirect their thinking. So that is what my idea is. Yeah, because, uh, you know, I have done this, like, if somebody asks me to— when you're coding, right, and somebody asks you to build a flowchart first and then code it, it's very difficult for me. But when I start coding, I can do reverse engineering, and then I understand the importance of why the flowchart was really important, right? So it's similarly, uh, applying the framework in one go is going to be hectic, chaotic, might, you know, give a little bit of resistance initially. So I think starting with the chaos is better. So, okay, I'll share my screen.

Let me know if you have any trouble.

Sure. Okay, let me know if you can see my screen.

I can see it. Can everyone see it? Great.

Awesome.

Okay.

And is the screen, Noelle, like only my framework screen is visible? Or am I—

All I can see is it says AI Whispers, and then it has the complete app building workbook.

Oh, okay.

Okay.

Because I need to share my entire screen because I'll be switching between—

What you might have to do, I don't know if it's a thing, but you might have to hold down like Control and multi-select the windows you're gonna share because there isn't like a desktop share option.

Okay, thank you so much. I don't know. Yeah, it's working.

Good.

Okay, so, uh, before diving in into, uh, you know, the framework, there are a couple of things that we, uh, should keep in mind. Currently, we kind of use AI as, you know, mostly our replacement. We do not put that much of hot. We have certain set of prompts, we go prompt it, get— we get an output, we quickly see if, you know, it understood what we're trying to communicate with it. But if we understand that AI is more like a human and, you know, more collaborative than we think of it as today, we would be, you know, more immersive in how we are building that, you know, getting that output from it. So first of all that, and the second is that when we try to build a solution, it generally comes from a problem or an idea that came up, you know, at some point we were facing a problem or we were discussing something with a friend group and that spark just comes, right? And what we want to do is go to these no-code, low-code platforms and just start building because we are so excited, like, you know, to, solve that issue. But the thing is that the more clarity we gain on what we are building, the, uh, you know, better outcome we have. Also, when we have an idea, we need to kind of validate it, that whether it's just, you know, a smaller group that we are catering to, or is it like, you know, a larger community out there that also wants this problem to be solved? And what similar kind of problems are they also going with? So, you know, as sooner you streamline your idea and you validate it, it becomes better to, you know, build a solution and you feel much more motivated with it. So for example, can you see my ChatGPT screen?

Yes.

Yeah. Okay, thank you. So for example, when I'm trying to focus on some work, great, and I feel overwhelmed, and I don't know even where to start with. So I want to maybe, you know, use some focus app or a meditation app, but all it does is, you know, add more confusion to my mind, like which track to choose and what to do. And I might just, you know, not even go there, and my work will kind of get impacted with it because I'm not totally focused. So I shared this very simple emotion with GPT. I said, you know, I feel so confused about which soundtrack to choose to focus before starting my work, especially during a deadline. Do other people focus, you know, face the same problem? Can you do a research on Reddit and other similar platforms to see if people have similar problems? And it did its research and it came up with really good examples that people have talked about. For example, you know, as long as I'm listening to any type of music, I will be focused on my homework. The moment a commercial comes on, I can't focus anymore. So from this, we can identify, right, somebody's doing the homework and they are having commercials in their app. It's like a student basically. And they need an app that does not have this monetization factor, the commercial factor into it. Or what kind of music do people generally use to focus, to bring their focus? If you read through these, each quote, you can get a better clarity on the kind of problem people face, the problem you are facing, and where they are headed to. So these researchers are very deep. You can go as deep as you want to. So when you're whiteboarding, it's very important that you kind of give yourself 4 to 5 days to streamline your idea before starting your hands-on. And you see the change is, you know, really devastating. And I'll show you, you know, I'll show you the comparison between these different mindsets. So the GPT did its research, it came up with a lot of things, and then it came up with suggestions. So I know that, you know, sounds related to nature kind of helps me a lot to focus. And I saw that point here when, you know, GPT summarized it, that people use nature sounds to focus on. And, you know, they might use a timer or something like that to, you know, bring their focus back on their work. So that's somewhere I start with. I validate my idea. I try to pick a couple of points from these and move on. So now when I know the problem, it's out there and it needs solving, my next question is like, you know, what solution can I bring? Because there's this big solution in my mind, but it's always better to refine it. So then it comes up with really good ideas. It's like, go with a one-tap focus mode app, because then there's no choosing in it, no, no, nothing, you know, distracting. Person opens that, taps it, and it directly— they focus on their work. It's a good idea. Or maybe an adaptive AI soundtrack generator. This might feel innovative if I'm a subject matter matter expert in this and I want to create different soundtracks, right, which is not available in the market. But for me right now, I just want a simple app with really good quality sounds that are already out there. So I think OneTap works for me. So, you know, you can refine your ideas, see what's out there, what's possible, and streamline as much as you can. Then we need to understand the target audience. So there could be a couple of target audiences in your mind. For example, for me, it's mostly students and professional workers. But when you look at what GPT provided, there are like focus on writers and analysts or students, researchers, freelancers. All these audience might have, you know, different, a slight different approach to how you can, you know, enhance their experience with the app. So yeah, so like you can choose a couple of audience to begin with. So once your idea is kind of streamlined, yeah, that's when you can start looking at the framework. So now I know what the problem is, I know my solution, at least the initiation from where I'll start my solution, and I know my target audience. I can start, you know, with an elevator pitch, like just define simply how you'll explain it to your friend, what you're trying to build. So I give this template to GPT. I ask it to come up with an elevator pitch, and it says, simple, it's a focus soundtrack app that students and remote workers get into deep flow quickly when they feel overwhelmed or distracted. By too many music choices. Now, what we are doing simultaneously is we are not only— we are gaining clarity, but we are also giving our research tool this clarity and context on which direction we are heading. So it gives much better outcomes, you know, going forward. So now the next thing that we go to is why this and why now? This is important because we know the problem, we know the solution, but why are we doing this? Is it because it's already not built there? Is somebody not coming up with the solution, does not exist? And why does it feel urgent at this very moment? So when you give this prompt to GPT, it gives you better brainstorming ideas here, like why would someone use this instead of what they do now? So like current behavior is that people already use Spotify and YouTube or white noise apps or silence, you know, if they prefer silence. But how this brings an edge, how your, you know, app can be an edge. So it removes, in my case, the decision fatigue. It's context aware, you know, it's curated with trust. So all of that, it provides an edge to your application. So you know that, yes, my app that I'm building is not just another noise in the market. It has a unique value and it can really help the target audience that you're going for. What makes this feel urgent or important to them? So like I discussed, you know, the deadlines, the people that are having constant distractions, they have this decision overload. It helps these people. It's important for them to kind of, you know, just have the most simple out there to help them, you know.

Do you want questions at the end, or how do you want us to ask questions?

Uh, sure.

I mean, if you have any questions, please do, but I don't want to interrupt your flow. I really want to know what's better for you.

It's okay.

So when it said context aware, you scrolled down. Yeah. What, what is that talking about? Because I don't, I Yeah, how— what is it referring to, if you don't mind explaining? Like, fewer higher quality choices has less switching mid-work, that one? Yeah, that one.

What is the context of where— so my app is more context aware because it understands the needs of the target audience. Currently, for example, if you're using YouTube or Spotify, it's not context aware. It doesn't know that I'm a person who is I get kind of distracted or I lose focus easily. So my app is built around these people that, you know, its UI is designed in a way that it's context aware that people that lose focus are going to use it. So it picks the sound based on these type of people, the mood, the, you know, importance around these people. So that's why it's context aware. Just thank you. Thank you, Noelle Russell Russell. Yeah, okay, great. So the next question is like, what assumptions am I making that might go wrong? And this is very important because whenever we are building a solution, we are attached to it and we can be biased. So for example, the assumption that people want an app instead of just reusing Spotify. So it can be a problem like, you know, another app in your phone. But if this app kind of really solves that one-tap problem, then people might want to. But it's good to check these points. For example, so sound choice is their main barrier to focus. So I am assuming that, you know, bringing only the sound aspect of focus is going to help everyone. But that might not be true. For some people, the barrier is just, you know, social media distraction. If they switch off their phones and keep it aside, they can bring back their focus. But then I'm not catering to every audience out there, but it's people that are similar to me and want to go through this path, right? Then one tab, simplicity beats personalization. So for some people, you know, nature sounds are not gonna work. It could be some classical music that works. So this is something that we are building like an MVP and we can always, you know, build upon this. So it's good to have these assumptions in mind, but also remember that, you know, we don't have to build everything at once. So after the assumption check, we can go to, you know, understand why would a person, you know, use my app and what would they feel around it. So for example, what would make someone tell their friends about this? For example, it gives them a surprisingly quick win, right? I tapped once and I suddenly worked for 2 hours straight. So it, it kind of validates your idea. It gives you much more motivation and a vision for your app that you're going to create. So after this, what we can do is now we know the solution, we know the problem, the solution, we have the target audience and we have a little bit of vision. We now move towards building this app. Now for that, we need to pick a vibe for our application. For example, if you're using Instagram, we know it's for engaging and connecting and being creative. If you are using Headspace, it gives more of a calm and a centered vibe, right? So similarly, it's always good to pick a vibe for your application. You can check for the similar apps that are out there, what vibe they are giving, what works for them, what doesn't work for them. It's okay if you don't know what you're going for. You can always, you know, prompt and research on these topics, like what similar apps are using and what way we want to go with it. So after all this, you know, basic brainstorming is done, now comes the most important part is what our applications will do. What features should it have? And the more complex your solution is, the more complex your app can become. And you can have like 10 features at once that you want to build. But it is very important to know that we should always start building from scratch. So because whiteboarding is not a very structural form of, you know, building how enterprises actually do. So we need to start small and then we need to build over it so that we are also aware of the flow where we are going. Rather than building everything in once and then we start using our application and then we want to make all those changes in the reverse order. So what we can do is here, just go to GPT and say that, you know, give me like around 5 to 10 features that my application should have and tag it as, you know, must-have and put at later kind of approach. So for example, in my case, ChatGPT kind of came up with 10 different features, offline mode, a timer, nature-inspired sound library, task-based modes and everything. And then it kind of segregated it and like, you know, this should be a must-have and these you can add later to enhance the experience. Now, must-haves not necessarily mean that you have to have it. GPT's opinion. You can use, you know, you can even add more things or remove things from here. So for my app, what I did is I just wanted two features currently. One is a one-tap start and other was an Asian-inspired sound library. And that's what I wanted to proceed with. So this kind of gave me clarity on, you know, what features I need in my MVP. Whenever we are trying to segregate these features, we can, you know, ask a couple of questions like, can I launch my app without this? Is it going to, you know, affect my pitch that I have? Is it going to affect the vision that I'm going with? And would users, you know, be confused when I'm giving them so many features? Like, you know, if this feature is actually important. Or it's just adding a lot of confusion just because it'll look cool or something like that, you know. So we can ask these questions and reduce the complexity of our app. Now comes the interesting part. So generally when we are in organizations, we try to write user stories for the application that we are building. And these user stories are very technical. What I generally like to do is, I build a user story more in the format of a story and not a technical specification. So for example, I prompt my GPT that this is my elevator pitch, these are the features that I picked and a couple of feelings or the vibes that I have for my app. Can you give me a detailed story which is not technical? And it comes up with a very beautiful story. So it's like when you're building this app, it's also like reading, you know, a book or something, and it's not very boring when you're doing this. So for example, it comes up with this scenario and it says it's a Wednesday evening and Ananya, a remote design student, sits at a desk with a cup of chai. She has a deadline in 2 hours. Her head is buzzing not just with the project, but with a choice of how to even start. And it tells the problem about why she doesn't want to use Spotify or any other app out there. And then it starts talking about my app. So then she remembers a message a friend sent earlier. Hey, try this new Focus app. It's super simple, no decisions. So curiously, she downloads it. The app opens to a clean, quiet screen. Now this is where you pause, okay? And you take a pen and paper and you start imagining this user first opened my app and it says it's open in a clean, quiet screen. So that's you mapping it to your landing page. So when, you know, your user is opening that app, how should your landing page feel like? What components should it have, right? If it's a sign-up page or it's just, you know, a hero section conveying the message of that app. Then comes a little bit of like a soft illustration of a Leap Swing you know, you can make your UI however you want. So no menus and no chaos. So I know that, you know, I don't have to put any menus in that app or anything, but if your app is complex enough, it has multiple screens, you can pause and reflect here. Okay, so after the landing page, when this— what does this person click on? It goes to the next screen. What is— what are they doing there? And you don't have to create any wireframes or anything, but just say that, you know, this screen, has menu in it, it has a chat assistant in it, it has a planner in it, you know, a calendar in it. So you just write it down because these no-code, low-code platforms are good enough to place them correctly. You know, industry standards are there. So they do it very nicely, but you need to know which page needs to have what features. Now it says, she hesitates for a moment, then taps. It instantly— a gentle stream sound begins. Again, I pause here and I'm like, okay, so I don't give her an option to kind of choose from the track. She taps it and a stream sound begins, means I might have to, you know, choose a default track for my app, right? Because that is what I want. I don't want somebody to, you know, go and choose from there a lot. So I need a default track, and this track is something that, you know, statistically most people use to bring back their focus. I can do that research there. So I'll just, you know, I know that I need to work on my default track, and then from there I can give those options to toggle if she doesn't, if they doesn't like, you know, to do that, to, you know, use that sound. A small timer starts in the corner, not bold or intimidating. When you're reading the story, you know, like for me, I don't want a timer. You can do these changes in a beautiful way, and you know, you're creating the entire navigational flow of your app from before. So you're gaining this clarity, and when you're building this app real time, you know a lot of the flow already and where you want to head to. And this kind of does not even feel boring, you know. So that is the advantage. Now, when we have planned our landing screen, our action screen, and what pop-ups need to come, what confirmations need to come, we can head towards designing the UI of it. Not too detailed again. We can just simply say what colors, you know, supports the emotions I'm going for, or supports the target audience I'm going for. Should my app's UI be minimal or to be rich? What patterns to similar apps use, or what should I avoid for this, you know, app type. So you can experiment with these. GPT will come with, you know, so many answers out there. Yeah, so for example, in my case, it's soft greens or earthy neutrals because I'm going for the nature kind of vibe. So similarly, you can experiment as much as you want to check for similar apps, what they are doing, and come up with a bit of idea how your UI should feel like. So now when we are done with this, we actually come to start building this application. So that's, you know, that craze that we have and that idea comes to do the hands-on. So now your GPT has the entire context you have discussed with it, right? All you have to do is just give a simple prompt saying, can you For my first prompt to that NoCode.io platform, can you give me the context? What exists now, even if it's starting from scratch, you can let that sink in there. What I need from that app, what visual style did we decide on, what functionalities did we decide on, right? So when you give that, GPT will come up with your very first prompt that you give to this platform. And it tells you what it, it tells that platform what it should do, what it should not do with that application's UI. For example, in my case, it should not overwhelm the users with choices or distracting gamification UIs. Another good thing that I always do is before coding, please explain what your plan is. Once you give this input to a whiteboarding platform, you need to know what it understood, right? You just could reconfirm what it understood and if it's in line with what you were planning to do, highlight its own assumptions and everything, like, you know, and then you just go and put it in your whiteboarding platform. Just give me a moment. Yeah. Can you see the, uh, Lovable platform? Okay. So here is the context that I provided, nothing else. I just simply gave this first prompt to the platform and it started building this UI. It came up with this UI. It's not super amazing, but it did go for the calm vibe that was there, no distractions, nothing. It has a little touch when I'm going for a particular Nature sound, its background is changing color. It's giving much more immersive feeling to the user. So when you give this prompt, the first thing that the whiteboarding platform will do is build the UI for it, okay? The front end of the application. And it is always good to pause here and finish with your UI before building the back end of your application. Reason being that when you build the backend of your application along with your UI, the entire app becomes too heavy and you lose the efficiency of changing. Even if you want to make even the tiniest change in your UI, you'll consume much more tokens than if you would have just, you know, built your UI first. So it's always smart to do that. Also, that you, you are, you know your navigation much better, you, what you imagined, what the tweaks you want to do, everything becomes easier when, you know, you don't have anything from the backend disturbing or the feature out there, right? So for example, here in one go, it gave me this entire application. It understood I need, you know, minimal soundtracks and everything. It came up with this and then it suggested me, do you want to tweak any colors or do you want to discuss any other feature? Now mostly the mistake that people do here is they use this platform just to build the app and any research work that they're doing or any feature that they want to build, they go back to GPT or Claude and try to brainstorm there. But we need to understand that that platform has forgotten or is not aware of how far have you reached here, right? So if it suggests you something, it can be totally out of context or, you know, if you simply copy paste from there, it can disrupt the entire flow that you've built here. So it's always good to use the chat or the discuss mode in different platforms that are there. And if you want to add a feature, you discuss it, you discuss that feature here that, you know, I want to integrate this. Do you think that this is too complex or how should I approach this? Anything, it's better to kind of, you know, brainstorm in this platform itself. For me, I didn't want to change anything. I wanted to now build the backend for this application. So it also prompted me, now are you ready to add the real audio files, right? Now generally people are comfortable with tabular data, text data. Why I wanted to show, you know, playing with audio data is because I wanted to remove that hesitation. So when you are using mostly text data with your applications, these agents are well enough to, you know, build everything for you from the schema to tables and real-time data that you want to input in these applications. But when you're working with audio or video data, there's a small manual part that you have to do, and that is to, you know, upload these files into their databases. These applications mostly come with, you know, databases like Supabase or Firebase. The integration is very simple. If you, you know, simply go and connect your Supabase here, you sign up, you build an organization in it. The signup process is simple. You build a simple organization with your brand name, for example, and you create a project within that. You connect that project here.

It will—

you just have to do simple sign up and it connects this project with that database. Now it will tell you that your app's connected, everything is good. It will suggest certain things like what's next, for example, just keep building for any questions. Just ask if you plan to have user logins. We highly recommend setting up authentication first. So this is also important. For my app, I did not want any user authentication. I wanted simple, but it's very important to build, you know, the sign-in, sign-up functionality beforehand because the entire backend that you're building will be connected to these users. And if you try to integrate this before you have, you know, after you have built everything in your app, the entire backend has to kind of restructure itself around this one functionality. That's why you see it's also warning us to, you know, if you have user login functionality in your app, do it before, you know, building anything else. So now I said that I don't want any of that. I just want to add real sounds to my app. And it came up with bunch of approaches. Now these approaches might feel technical. You'd need, one by one. For example, in my case, audio files plus Web Audio API. So audio files, I understand that, you know, MP3, MP4 files, but Web Audio API can feel overwhelming. Supabase storage, on the other hand, I know is something I can work with because I integrated Supabase right now. Then generated audio is something I don't want to go with. So generated audio is basically, you know, this agent will automatically use AI to kind of generate these sounds for your app. And these are not very high quality sounds. Either you then go and integrate it with ElevenLabs or OpenAI. All of that adds too much complexity. So whatever complexity you're comfortable with and your app requires, go with that. If it feels difficult, you can, you know, in plain English, ask what needs to be done. For example, I wanted to store base storage and audio files. And I didn't want to read through all this. All I asked was, do I need to do anything or will you be able to implement this plan end to end? And it came up saying that, you know, I can set up the storage, I can do the implementation of audio, everything. All you have to do is after I've done everything, you need to upload the actual audio files too, Superbase storage bucket. So first of all, I need the data source for my file, right? For my app, where do I get these audios from? In my case, I went back to GPT. I just said, can you tell me where I can get free nature sounds for meditation to use in my app? It came up with a bunch of application websites where I can go. I chose one, I downloaded a couple of these sounds that I felt were good, it gave me this button where, you know, it says upload your audio files. So I opened my Superbase storage. It's very simple. You don't have to find or navigate anything. It gave you that exact place where you need to be. I went to audio files and I simply uploaded the files, nothing else. It is as simple as copy-pasting the files that we do daily. And once that is done, it tells me that what kind of names you should keep your files, maybe because it's using it in the code that it's running behind. So I did that and my app was fully functional. So for example, if I want to, I don't know if you can hear the sound. Lauren, can you hear the sound?

No, you might have to unshare, and then when you reshare, there's a little checkbox that says, uh, share sound.

Okay, okay, stop sharing.

Do you see a little checkbox?

Yes. Okay. Can you hear the sound now?

I'm like leaning in. No, I don't think so.

Yeah, I can hear it. Oh, you can hear it? Yeah, yeah, the rain. Yeah.

Oh, it's raining. Maybe I can. Let me turn it up.

So now, I mean, this audio is very easily integrated into my app. And when I started working with these white coding tools, Creating that bucket was a task, right? So that's why in the beginning I said technology is advancing very fast, things are getting easier. All we need to do is have the right mindset to build our solutions. So while I was, I don't know, I mean, I'll just stop it now. So when I was building this framework, during that time came another whiteboarding hack platform that kind of works on this framework. So there's just a couple more things that is left from these frameworks are test as you build. So it's very important that, you know, we will not have another testing session as we have in the traditional app building process. Every feature that we are building, it's important we test it immediately and also test the flow that our app was built for. For example, it's a very complex app, but it's there to, you know, do the planning of your meals. So maybe you're adding a menu or you're adding a small simple chatbot assistant. But the most important thing is that you check the flow that you're working, that your app is created for is working perfectly after every small change. It really helps, you know, rather than doing this in the end and not knowing where what broke. After testing comes your— so this I discussed, like, you know, add features very carefully using the same platform that you are in. Now, the bike-pudding platform that came recently was Emergent, and when you're trying to build an application here, so I want to show you the mindset that, um, I have not used any of these tips and tricks here or any idea refining here. So the advertisement for this app was like, give it one line and then it'll build the entire app for you. So I just simply said, I want to create a meditation app for ADHD patients. The good thing is that it started asking me clarifying questions on its own. Like right now we are going to GPT to do this. It's a good practice to still gain clarity first on your behalf, and then if the agent does this, it's even better. The other thing is, so as and when it's progressing with your application, it will keep prompting you with questions. That is where your input is important. The other important thing is it continuously tests after every build. That, you know, that we have to do. Although it's an emerging platform, so the tests are not always correct or always complete, but that mindset is here, right, to test after each build to make it much more better. Now, this app that I built on Lovable was using this entire, you know, mindset that I have discussed here. The first time that I built my app was using Bolt.new. My mindset was not that clear. I just went with the flow. So you see, it feels different. Every whiteboarding platform has a different UI that they go with. And here you can see there are timers and there's actually no sound at all that they can choose from. It's like they have to go with the sound that I provided. So for me, initially I felt, okay, this is a good idea, but then, you know, to cater to different people with different sounds, I was much more important than giving these timers because you don't, you never know that a person is working for 2 hours constantly or, you know, how much and they every time have to restart. This is again, you know, problematic. So these small things without the right target audience and the right mindset can create different kind of applications. Now coming back to the UI part, the best UI that I found was in this Emergent, from this Emergent app. So whenever you're trying to choose your, you know, white coding platform, you need to understand for what kind of application are you building? Is it a professional application that's out there, you know, using the same white UI and many cards out there? You can use any whiteboarding platform, but if you want it to feel much more realistic, you can do research on that and then select your right whiteboarding platform. Then also the ease of learning. So for example, Lovable and Bold.new, they are very easy to learn, but if you go for Replit, Replit's agent is very easy, but if you want to do small changes and like how I uploaded these audio files and everything, The learning curve is much steeper over there. So, you know, you want to do those research, pick your live coding platform, and, you know, just use this mindset to— I really wanted to show you the app from here, but sadly it's not loading. So—

I have a quick question.

Sure, yeah, please go ahead.

I was just going to ask, can you change out the UI on Lovable?

Yes, yes, I can definitely. I can, you know, just the icons. There are the icons here.

Yeah, right, exactly.

Yeah, you can do that. Like if you want to upload your own images or something in these icons. You can prompt this agent that, you know, I don't want icons. Instead, I want to upload my own images. And it'll tell you where to upload that. And then it'll integrate, like how I uploaded these audios, you can upload the images in the storage bucket. And it'll integrate it with these icons. Yeah.

So you would use Superbase again? Was it Super?

Yeah. Yeah, to the Superbase. Okay, to the base. It'll create kind of another bucket. Images and something, and you can just go and upload it.

And you won't have to, you won't have to like build the buckets. Like, you just ask it. And something that I often will do is ask it to model other apps. So if I know that there's a UI, because I'm not a UI— some of you are UI people and you design beautiful things. I am not that person. So I will go and find an app that I really like and ask it to model that. And so it will use— like, I will give it a website or I'll give it an app name. Sometimes it inherently knows those things. But yeah, when you ask it to create these images, it's going to automatically— it'll ask you, would you like me to create a table to store this information? And every table you'll have to approve. And just know that obviously, as you mentioned, Sylvia, so beautifully, that as you get excited about this, you're going to start creating pretty complex data structures, and that's not free. So the bigger your ideas get, great, but also kind of be careful because as you build these data structures behind the ideas that you have, that infrastructure you will pay for at some point.

So that's a good question. So Supabase, is that like a monthly subscription and it's based on what you, how much information you have stored there? Does it tie into how many people are accessing it too? Because Is there drawing?

They have a couple of different, um, plans. There is a, like, not unlimited, but a high-use standardized plan where you just buy a bucket of, um, access. I think it's like $50 a month or something like that. Um, so when you use it, it will ask you when you sign up for Supabase, which you will do when you connect to it for the first time, it's going to give you these options. I just chose like the buy all the things for $50. And that has supported the apps that I've built so far. But I mean, I'm maybe no more than 1,000 users am I like serving. So if you're looking to build like the next, you know, cool Joe Blakely app, no, I'm like, you might get 10,000, 100,000 users. That cost is probably gonna get pretty high.

And I was also wondering if you tied into an API like Spotify's API, Is there a way you could have sorted through that to just, I don't know, to just take meditation music or calm music?

Yeah, because you can have it build a query. You just would likely not, from a latency perspective, you wouldn't want it to do that query every time. You might maybe for the first 5 times execute the query and then save the ones that were the most popular and then always hit the memory instead. But you don't have to do any of that at this stage, right? Because at this stage, we're just trying to vibe our minimum remarkable product. But as you— like, this is the reason why lots of projects never see production is because kind of what Joe mentioned in the chat is that, you know, at the end of the day, there's all these little details that make production use, like, complicated. And those things are worthwhile thinking through. But most company— like, most ideas never get to that stage because they can't get momentum behind the idea. So we're kind of reverse engineering that, right? Like, hey, what if you could build something without those complicated things and just get it working and then worry about the details later? So yeah, but it is important. I wrote in the comments as well, I do think we probably need to, which I think is ironic because my career started in cloud. I do think we kind of need to have a baseline cloud end-tier architecture discussion, right, Nitin? Like, just how are these, like, applications built? Because even if you're a ViBE coder and you never see that, I think it's useful to know what these pieces are, the concept of web servers and app servers and deployment. I don't know, I feel like it might be good to hear it at least once, even if you're not technical, just so you know that there's like some complexity on the back end. And, and you might ultimately, depending on how big you decide to go with your idea, ultimately need some help that you'll need to, to ask for. Yeah.

Are we—

so, Mia, are you good for some questions? Of course, I'll be here to, to answer them. And any one of you— some of us are Vibe Coders and have done a lot of really cool work on different sides. Like, this Vibe Coding experience was for the non-technical user, so it wasn't like engineering vibe coding, which is a very different perspective. But hopefully, I mean, the audience here is not— like, not all of us are engineers, so we try to make it as accessible to everyone. But let's start with you, Deb, and then Joe will go to you, and then Eve.

So I'm a non-coder. So my question for you was based on what you just said, Noelle, that does that mean that apps like Lovable and Replit are really only good for the minimum viable product, it's not good for something if you want to actually sell it?

No, I would say you just might need additional technical expertise when you start to move towards production. So for example, on Lovable, I can get something into production and not have ever called an engineer because I can talk through and it will tell me when my code's broken and give me suggestions on security remedies. Where other platforms are assuming you have that knowledge. And so they're not as coachable. They're not coaching you in the same way. But right, like, that's who they're built for, right? So I do think it's important when you're evaluating your vibe coding platform to look at who their audience is, like, who are they targeting, and make sure that that matches who you, you know, identify as.

I was thinking more in terms of price because you're saying it gets expensive if you're, you know, doing more.

Oh no, I think it's expensive no matter what. Like, ideally you're monetizing this. Over time, right? So ideally you're able to build something and the minimum remarkable product is something that you can sell to someone. And then as you add features, just like every other software company, as you add features, you increase your price. And so, yeah, it should. But these are all really great things to think about that aren't really the Vibe Coding platform's job, right? It's like, how do I make sure that as I deliver on the dream of what I want to build, that I don't get over my skis in cost before I've been able to create a customer base that's even willing to use it.

Thank you.

It's like a product manager. Actually, Reena, we'll get to you, uh, after, but I feel like you could definitely speak to that because that's— it's like a product manager's job, right? Um, the platform's probably not gonna support you too much in that, but it is possible. Um, did I answer your question or did we answer your question? Okay, great. Thank you, Deb. Joe, you're next.

Hey.

So I just was going to share my views on Vibe Coding, at least from how I've used it. So it's really great for proofs of concept, or if you're trying to say, okay, I understand, client, Mr. Client, I understand, or Ms. Client, I understand your requirements. I'm gonna put together something in 5 minutes and show you how I view it, or at least how we can work, start working with it and put that thing out really fast. And, and because it's much better to show someone than to talk about it. And so from a show and tell perspective, that's really good to start a conversation. I don't think that I would use a fully designed you know, like a vibe coding platform designed product as the, the final production release. I think there's a lot more that goes into thinking about, so are you going to release this on a global scale? Are you going to do it on a regional scale? Is it just going to be on a local, in your state or province? So you've got to think about the scale, the scalability. You got to think about the infrastructure costs, about supporting whatever app that you're designing. Is it going to go on a cloud infrastructure? Is it going to run with a database in the background? How much does that infrastructure support cost going to run you? And is it going to scale globally? So, so all of these types of— well, we call them in architectural world non-functional requirements. So they're the ability, the scalability, performance, those types of things.

Latency, resiliency.

Yeah, resiliency. All of those things that you have to think about when you're, you're going into production type of situation. Also think about planning for failure. So think that your app is going to fail when you, when you design it. And build those, that resiliency around knowing that it's going to fail.

Yeah, I love that, Joe, 100%. And the only, you know, I would encourage everyone to kind of look through the lens, like Joe is an enterprise architect, like he works with like the biggest companies in the world. And so I 100% agree with you, but I also know that there are like little tiny companies that absolutely could go to production where their scale is only their business. They will never go global, you know what I mean? So I think— but I think what you said is incredibly important, that it is in the questioning, right? It is in our discovery that we decide how viable a vibe coding solution is for what phase of the lifecycle. So I think you're— that's so very important because we are kind of skipping to let's just build this. And when you're using this for a client solution, if your client is small enough, like I have a client He's, you know, he basically has 7 customers, maybe he'll grow to 20. And the platform I built for him, which was a VibeGoat solution, he designed, I engineered, but I didn't have to write the code. It was actually beautiful for me as an engineer. I'm like, this is awesome. But, like, I don't need 5 nines reliability and uptime. I don't need, you know, like, I don't need cross, you know, availability zone distribution. But some you do. And I would not have used this to do that, right? So I think it could be the right solution for your customer, but the burden is on us as the architect to ask those questions. And I do think, what you mentioned earlier about functional requirements, I love using this MRP idea, building a vibe-coded solution, and then reverse engineering, what do these business requirements look like? And then validating, right? Like, did what I build actually validate? Does the business agree with what we're designing? So I, Yeah, I think it's a really important point you're making.

So the other thing that's great about a POC and giving them something to look at and show and tell is that you can, you could trace their requirements, you know, their, their actual business requirements back to the functional, nonfunctional requirements. So basically what you're telling them is help me visualize what your vision is of the app and focus on the end user. That's the— that was— you said that earlier. I love, I love that because people forget to mean to keep the end user's usability, their performance requirements, their, you know, if you, if you lose sight of the end user's vision, then you've lost it already.

Yeah, exactly.

Awesome.

Thank you for that. Feel free to chime back in if you hear someone say something you want to comment on it. I think Tara, I have—

oh no, Eve.

Did Eve not?

Yeah.

Yeah. So mainly you covered it.

Sorry.

I was like, I felt like you were next, but I didn't see your hand.

No, I just put down my hand is what happened. I think you both covered what I was going to say, but I have another perspective because I'm not an engineer and I didn't start my path in coding. And I think this empowers us amazingly, right? And Joe, I understand your pushback, but come on, we've got the power now. They gave it to the simple people. And I think it really teaches us so much, right? And the backend stuff, when I got a little bit, you know, like, what, Cloudflare now? So I just took screenshots. And I asked my ChatGPT and Clutter Perplexity, I said, what the hell now? Like, I'm stuck. What do I do? And it explained it to me and I felt like, oh, this is amazing. I can actually do it end to end. So I think there's a lot of value there. I'm not about to sell this to Microsoft, yeah, but for myself, it really empowered me. That's one thing. And I learned a lot along the process. I thought it was totally worth the struggle. And you could come up with all sorts of crazy ideas and you could do them, you know? And like, I couldn't— 4 months ago, this wasn't a, you know? So like, who knows, in 6 months, Joe, I might be able to sell it to Microsoft. But I just think it's very empowering. It's a really good learning tool. And there are people that it's gonna work, you know, you're gonna be able to— anyway, you all covered it. I don't need to keep talking.

Thank you so much. I think the diversity of our perspectives is so important because you see the world through a totally different lens than we do. And so I'm so, so grateful that you decided to chime in, even if you felt like it was covered, because I think, uh, I think we all got something from you just saying, like, you know, Sherry's got a t-shirt design, uh, all around the simple people now, like, power, power to the simple people. That's like a shirt we're gonna have now. Um, so thank you, Eve. Thank you for your perspective. Tara, come on up.

Hi, I actually have two questions. And Eve, 100%, I'm with you, girl, 100%. So the first question is, when you're like, I'm building this first product for me, it's something I envisioned, nobody makes it. I can't believe it, it needs to be made. So I have a really clear idea of what the first version looks like. But as I've been iterating back and forth with ChatGPT and as well as Claude, I've all of a sudden realized I could add this, this, this, this. So two questions: at which point do you realize— how do you realize that now you've got feature creep, even if it's a couple iterations down the road? Get a grip on it, girl. And, um, how when people talk about the infrastructure cost or whatever, if I'm paying X for, you know, ChatGPT and X for Claude and X for Lovable, whatever, what are those other costs? That's what I don't understand, that the more it has, the more costs there are. I'm not understanding that part.

Oh, sorry, I thought I was muted. I was like, ah, um, So I think one of— I mean, you asked a couple of different questions. Maybe I'll take the last one first. And happy to hear if anyone else has perspectives on this as well. So infrastructure costs. The good news is, is that we know what this costs. And so you can, like Eve had mentioned, when things get complicated, you can just ask for estimates. You can ask it to explain to you, like, how would this grow? And this is something I did for my own business. Is I was just like, let's just say I wanted to do this thing in this way. What would that growth structure look like? What would potential infrastructure costs look like? Just to get a baseline. And then I exponentially grow that and charge my clients. Not you all, but the other people. But that is one piece. The other one I wanted to talk about, maybe, Soumya, you could talk about this too because I think it's part of your framework, which is the scoping part, which I do agree is a slippery slope. And like, you end up— and Reena, maybe you could talk about this when you come up too— but like, it's a slippery slope. Like, you, as soon as you start, you know, getting excited, you're like, oh, and then this, and then this, and this. But I think what your first part of your framework, um, Soumya, was like this purpose statement, like what are you going to do. I think it's, again, the discipline is on us as the architects to kind of be like, okay, this is what V1 looks like, and Joe, I think you'll appreciate this. I often say, like, I will snap the line, like the chalk line on the field. Like, you have to at some point snap the line on features you're going to deliver in your MRP, just like we used to do in MVPs. You have to kind of say, okay, this is it. These are the features. And it's so hard to be disciplined, to not be like, ooh, but I can let them build their own tracks with SoundCloud. Ooh, I can let them—

Yeah, yeah. For sure.

Exponential. So you have— but here's what I do to, to satisfy my brain's desire to create features is I document all of them. You do like the best of us, you know, the best product managers in the world. You create a backlog and then you prioritize the backlog, you know, and so the ideas never get lost. I use ClickUp. So in ClickUp I put in all my crazy ideas and then we, if you are an agile person as I am, Every time you finish a sprint and you snap that line and you deliver those features, you go back and go, okay, if we could only do one thing, what's the thing we would do? And why would we do that thing? And does it align with the purpose that we designed in that first part of Soumya's framework? So that's my perspective. But Soumya, do you want to add something to that?

Sure, definitely. Thank you for asking that, Tara. So one thing that I have, you know, discussed with people around me and they say that this has become a new gambling thing, right? People are riffling their tokens just to reach an endpoint to their app and it's never happening. So what we need to think here from my perspective is that for the people that we are building this app, like I, you know, in my framework I asked this question, ask this question, right? Can my app live without it for the moment? First, I need to validate what I'm doing. Are people really connecting with it? Maybe take that early feedback. So, you know, we have that minimal features first, go out in the market, get a validation from it, and like Noelle Russell said, create a backlog and just keep on adding to it as and, you know, when the traction is— your app is gaining that traction. That could be one part. And remember that, you know, we don't have to get trapped into the gamble of it.

It is.

It's very tempting. I have clients that are— it's very hard for them to say, like, we have made a decision. I'm very big on minimum remarkable product. It's like my brand. So I'm like, we define what that looks like. We document what it is. I've never had a client be like, I love it. Like, we're good. They all will basically come back and be like, oh, but what about this? And I really think our client needs this. And so I love that question you're asking, which is the most important question. Like, is it really necessary? Or how does this violate the original intention of the system that we were trying to build? Because, yeah, it's just so easy. And that's the danger is that because it seems so easy to just add a new feature, it becomes, and I encourage you to just play around with this, but it becomes a rabbit hole, right? You end up adding a feature that requires you now to learn an API, and now you have to learn how to integrate that API, and that API doesn't match the thing, and you're on this thing which isn't even related to the minimum viable, you know, the minimum remarkable thing you're trying to deploy. So I don't know, you know, create some kind of like, you know, post it on your monitor that's like, take a breath before you, before you change the scope. But this is a challenge for all products, mature or immature, vibe-coded or, you know, traditionally coded. Like, we all struggle with keeping the scope. We call it scope creep for a reason. Like, it's not a new, a new problem. But those are, I think, some great, great advice on sticking to it. But yeah, it's a discipline. And really, we just get better with it the more we miss scope and then fail, the better we get at keeping scope and winning.

So it's kind of a—

hopefully you can learn without failing, but I found that that's my best and favorite way to learn. All right, I think we have a couple more questions. I'm trying to find— oh yes, Reina, you're up.

Okay.

Yay. So I'll ask my question and then I'll address your product managing questions. Yes. So I'm looking at vibe coding from a non-coding perspective. And, you know, I'm kind of midway through vibe coding my first project. And I used Bolt to do my vibe coding. And one of the things that I did not do before I got started was really sit and think about what are all the things that I'm going to need out of my vibe coding tool. And so I vibe coded. I had a great prototype in 10 minutes. I got so excited. I asked, I went and asked Claude, okay, what do I need to do to make this real? And meaning, because this is a mobile app that's going to need to go into Google Play and the Play, Apple Play Store, right? And immediately it pulled me out of Bolt. And I was, yeah, and I was sitting there, I was using ChatGPT and now I'm back to Claude. To try to code my thing. And I think my question is, when you're vibe coding and you're at prototype, right? I had a working prototype. But how do you take that, like when you make that decision to get an engineer involved or when, you know, because I think this to me was supposed to be a simple app. I actually got it even with the vibe coding into the Google Play Store, but then I started getting feedback. Yeah, I got it. I haven't touched Apple yet, but I got to the Google Play Store because I have an Android. So I started with what I know. But I got some feedback and it actually messed with my— I was thinking in terms of MVP, but it is what will take it really to an MRP because this is a music app and it wouldn't play if you closed your app or your phone went to sleep. It didn't play in the background, right? And it's one of those things that's like, OK, yes, this is major scope creep now.

Yeah.

But also, it's like, this is why you beta test.

Right.

And all of a sudden now I'm changing my whole code base for the player. And I'm outside of Bolt at this point. So I guess that question is, it sounds like I could have probably done a lot more. In Bolt or whatever tool I was using. It's like, when do you take it out? Because like, can you— and then you might not know this, but if you're making a mobile app, can Bolt or Lovable get it that far?

Because it definitely can get it that far. I mean, I've got— I know at least a dozen production systems that are built on Lovable, and Lovable has probably 100 case studies of their own.. And they've scaled to like hundreds of thousands of users on these apps built on Lovable, scaling on Lovable's infrastructure. So that is, that is not the challenge. The challenge typically is kind of what Sonia was going through in like her first few frameworks. Like one of the questions I loved that you had in there was what's the worst thing that could happen? I kind of threw in like baby tiger mode. Like when you ask this question, like what's the most common problem? I mean, You know, there's so much in there. You put just this one kind of question, but there's so many questions. And I think, Joe, you talked about it too. Like, there's so many questions we can ask. Like, what's the worst thing that can happen? What are the most common reasons these types of apps fail? What are, you know, like, because it has, and I don't mean doing this inside the vibe coding platform. I mean doing this in a, like, deep research reasoning platform that can go and look at Reddit and go and do right research and actually find out. You are not building the first app of any, any kind, right? Like, it's very, very rare that we're building something that's never been thought of before. And most importantly, that other people have likely, which is why you have the idea, they've likely tried and failed. So if you can scour the internet to find out what was the problem, why did they fail, and how do I avoid that? And you do all that. I mentioned that in the chat as well. How do you avoid like you want to do all of that before you even burn a token or burn credits on your Vibe Coding platform, right? Have thought through those solutions because then it would have told you, well, like Reddit definitely knows the music players to avoid if you're a mobile app developer using music players. Like that is, we know that, but you wouldn't have known to ask that question, right?

Right. Now that's the thing. If, but if I had asked the question, which I thought was a really good one, what's the worst that can happen? What are the things that I need to think of when it comes— because I'm in product, but I've never been in mobile, right? So those are things I would— if you've ever asked me to build some B2B API with a database and all that, I could answer those questions. But this was an end place.

And now think about those prompts, right? Because now you can say, hey, as a product manager in the mobile space, right, you can scope your ChatGPTs, like, based on the purpose of that prompt. You can actually get it to like hone in on mobile product management expertise, which, like you said, you— and the good news is you know enough about product management that you could validate, like, okay, I see why that would be true. But it'll give you insight into an area that unless you knew to ask, it wouldn't know.

Right, right. My challenge is because I took it out of my vibe coding app too soon, now I'm having conversations with GPT and then Claude, and it's having me replace code and fix code and upgrade. Oh wait, it had— it failed on the build to go to the app and all these things. Yeah, where I'm not an expert and now I'm finding myself having to pull in actual coders because I don't know what I'm doing, right?

So that's why I was saying, I was like, yeah, we probably need to do at least a little bit of architecture. But I will tell you, like, for a long time, and, um, for a long time, one of the things, uh, you know, there's always been— when you start a company, you have a CEO who's the visionary, the idea person, and then you have the CTO who's the builder, right? Who like implements or COO if you're not building anything service-led. But either way, there's like two brains. And so this doesn't solve for that. Like, you know, you're not getting a CTO, right? Like you're getting an engineer. So you still need someone who like can own that engineering work, but not at first to Eve's point. Like you can get really far far before you need to really invest in that, that stage of—

yeah, yeah. Now, now I'm at the stage where I'm pulling in my husband, who is a web developer, but he knows nothing about mobile, and now he's calling his friends. So yeah.

And so I will say though, when you're vibe coding, the idea is to— what, what feature set could you pull back to, to get something that works? And you might even trade off things you've already implemented successfully pull those back to get this player in so that you can get to market and get positive people saying positive things.

Right. And that, that's exactly where I'm at right now. But it's kind of like this— what was really easy has now, because of the beta testing, just taken me forever just to get this all correct because it suddenly made a really simple app much more complex.

Right, right.

And I guess that's maybe the, the truth of it all, right, is that at some point when things get real, like, it's gonna be like, it's still software, right?

Like, right, right.

And I guess comfortable with that.

Yeah.

And then not to go on a tangent, but so I'm at a point where I've had to, I've gotten a lot of great feedback from my beta testing. And this leads into your question of the product management and, oh, can we have this? We have this, like, right? And you have to like be so diligent and say, that is a great idea. I will, you know, it's on the roadmap. It'll be built, but let me just get this out there so real people can use it beside my beta testing group. Absolutely. And they're like, oh, okay. But the question becomes one of the things that we want to do, and this is, you know, my husband is my partner here, that will require usage of a database and all of that stuff. But I've already taken out of my Vibe Coding tool. Can I kind of put the thing back into Vibe Coding so I can get the design? Because he's not a front-end person at all.

Absolutely.

And I would even take it into like a ChatGPT type LLM in order to talk through so that you can have it generate a prompt that is good for you instead of doing that like re-engineering since it's out already. Yeah, rather than do that re-engineering inside of— because the Vibe Coding, um, credits are just much more expensive token to token. And so I would do it in like a ChatGPT type LLM, whether—

okay, so that's, that's where I'm at. Okay. Okay.

So I would do it there and then ask it at the end, okay, based on what we've talked about, create me a, a prompt I can use in, you know, which one did you say you were using?

I was using Bolt.

Bolt. Yeah, it was in one of our top 10. Yeah. So, and, and the good news is these models, especially GPT-5, knows Bolt. So you could be like, hey, create a Bolt-friendly prompt that I can use to accelerate to this stage of my ideation. And then that way you don't, like I said, burn a bunch of transactional token requests just trying to figure it out. You can do that on a much— the larger the platform, right, the cheaper the token.

So, okay. No, that, that, that, that's great. I don't know if I answered the product management question, but it's, it's was the hardest thing for me to come to terms with as a product manager. Like being able to like figure out what that minimum is. And I've done it, I've guessed incorrectly, right? Where I've said, oh, we need these 8 things, but you know what? Turns out we really only needed the 5 things, right?

Right.

And it was taking forever. And I remember I had a VP of Engineering, it's like, well, do you really need this? I'm like, oh, but this is what we wanted to do. But Do you really need this? Like, oh, maybe you're right. Well, let's see what happens. If it totally flops, we'll add my things in.

Yeah, but it actually worked.

So yeah, and I actually think that's again another little Post-it that we have on our monitor. And yes, my monitor has Post-its all over the place. But do you really need this is a good one to have on, right?

Or do your users really need this? Yes, right? Because it's So to Joe's point, for me to think about the user, that's my job and I have to circle back with the engineers. But coming in from an enterprise perspective, I completely agree with everything you said, but I'm taking this for as a one or two person business and it, it's a different mindset. I don't need to think about all of that engineering and scaling. This is not gonna scale. This is a small little app, but if this is successful, then I'm going to think about scaling because can I sell this app?

Absolutely.

And one of the things that, Soumya, in your framework— and do you— will you share that with us? Can we— are we going to go through that next? OK, so we're going to go through that next. We have a couple more questions and then we'll go through that. But I just wanted to mention something that David put in the chat because you also have a set of questions around kind of your— I wrote it down like you're— you didn't use this term, But some of us would know it as your unique selling proposition, right? That in your designing of the app, you want to think about— and if you don't truly know your users, you're going to be relying on either you going and finding those users and talking to them, or asking for Reddit-based research or user-based research, or ask the public. And so that is just as important because that becomes your differentiator, right? What is it that you do that's unique? And how can— Maybe you don't even realize how unique what you're trying to do is. How can you use a research model to actually validate your uniqueness and build that moat, as David mentioned? 100%, couldn't agree more. Varol, it's been so long. I'm so glad to see you, my friend. How's it going? I can't hear you. Oh, there you are.

Yeah, just coming out of the hospital. Oh my God. I've been in the hospital for a while.

I'm glad to see you. Well, not see you, but I'm glad you are here.

Yes. I'm coming along. So my question, one more comment, but I think it has been addressed when you were talking about scope, because there are sometimes that there are features that are necessary, but there are features that can become a scope creep and take you down the rabbit hole, as you mentioned. So once you're defining these requirements, the most important thing is what is must-have, what is like to have. You have to be able to categorize those. And once you understand what's a must-have, there you draw the window. So you're not gonna have a scope creep. You may have a timeline creep, but you're not gonna have a scope creep. Is that— if it's a must-have, because can the product function or the app function without this? Does it give— what does it give to the user and what does it take away? But once you can define that, then you stay within that window. They like to have, oh yeah, that's the next upgrade, right? The next, you know, that's the next iteration when you're going to do it.

Yes.

But I agree totally with what you said. You don't have to have to have that window. Otherwise you'll be building forever.

That's right.

Yeah.

And, and that's like the death of every, you know, they, that research that just came out that said 95% of projects ever fail.

Right.

This is one of the reasons, and it's not a technical problem. It is a leadership problem. Problem because nobody can say when done is. So yeah, I think it's such an important, such an important thing. And yes, please, please get better. I would like to take a moment and just, you know, give some love to Sonya. So in the chat or via emojis, I just want to give her some love so she knows what an amazing— like, obviously you provoked so much conversation and questions. It was really, really awesome. I'm so grateful. That you talk to us about it. And so the plan was for her to kind of describe it. And now we have some time left for those of you who are here. Wow, look at all that love. Wow, that's so good. Yeah. So this will give us a chance now to actually practice what we just learned from your framework. So do you maybe want to take us through what maybe our next hour might look like and how we can maybe put into practice what you've talked us about?

Sure, sure, Noelle. So like I said, you know, adapting any framework is very difficult, but I guess a lot of us have, you know, had this practical hands-on experience in white coding. So the biggest struggle here is to, you know, come out of the scope creep and to make our white coding experience more efficient. So what I'd encourage all of us to do is, you know, sign up on a white coding platform that we have not, we have not registered before. And with those minimum credits that are there, you know, it's in Lovable, it's just Sprite credits. In Bold, it's just, you know, 150K tokens. I want to, I want you to experiment and see how far can you reach when you start thinking the right way. Just don't apply the entire framework, but, you know, just try to streamline your idea. Try to see what your must-haves can be and see if you can build the minimum product in just those credits. Because I tried doing it in 3 platforms and it helped. And earlier I would, you know, refill my tokens like crazy and not even reach there. So maybe, you know, smallest idea that you have, it's like, be as creative as you can. For example, I did my meditation app, or maybe I want, you know, to have a readers community like an Instagram community, but where people are posting more of what they are reading and, you know, we are engaging with those kind of reels and stuff rather than mindless scrolling. So that's my idea of, you know, small app that I want to do, create a community out of it. So any random idea that you have not directly related to your business brand, but just to get your hands on and, you know, try to solve the problem that you're facing. Yeah.

Yes, love it.

Yeah, because, you know, the time is really short to fight through it.

Like, I actually love what you're— what you said about that, because I think I always say, um, of course, learn by doing, but it is in the iteration, right? When you build like 3 or 4 times. Like, I just sent out an article that has 10 vibe coding platforms. So I think it would be an interesting challenge if we went and like did use your framework, right, to ideate, but then actually went and built it 10 different times using free tokens on those platforms. Now some of you are going to be like, well, no, I might have more than one idea and I don't want to burn all my free tokens. But I really do think that that is such a— yeah, it's a great— I mean, that's what I did at Alexa, right? I mean, this is 10 years ago, but the only reason I am who I am today is because I built like every single day. I built on a new, a new idea on a new platform with a new API. I mean, I, I knew Java going in, but I don't know if you all know this, but when I was a Java programmer and on Alexa, they didn't support Java. You, you had to write in Node.js. And I was like, Node.js? Like, in my opinion, I was like, that tiny little language? Um, no offense to anybody, but I was like, that's not very robust. Anyway, I had my issues, but I had to go learn Node.js and then I had to learn like there was 5 other languages that were adopted before and of course Python before, before Java became one of the languages they supported. And of course then I built on that too. But it is this like building skill, right? The muscle of just build, build, build and then partnering with ChatGPT to help craft those prompts and that and then even you'll see your efficiency in using your free tokens gets better and better and better. So yeah, really, really great idea. I love that. I love that. Okay, awesome. So I guess, how will— how is this framework shared? How do you—

what—

where is it?

I can share the link. I can share the link.

Yeah.

Is it in like a— it's on like a website somewhere?

It's on my website. It's on Gamma as well. So perfect.

Yeah.

That's amazing. I love AI Whispers. I actually told the CEOs the other day, I'm like, you all need your own AI Whisperer. And, and like, and this actually maybe goes, Deb, a tiny bit to your question, is that there is, and so everyone can click on that framework and see it. But while we're, we're doing that, there is a huge challenge in the marketplace right now between people who can do what we're talking about, vibe coding a solution. Just like many of you mentioned, you get to a certain point, then you're going to need an implementer or you're going to need someone who's a little bit more technical than you are to make sure that you're doing things safely, securely, in a trustworthy way. And that partnership with your technical delivery team is not only is it the most important partnership you have, it's also extremely hard to find good people that do this work in a good way. Like, it's one of the hardest things we do. So here is my hope, is that some of us here, we do this now, right? Like, that we help each other, that this, you know, AI Leadership Institute specifically, um, that we, all of us have different skill sets. Half of us are are technologists by trade, you know, like that we're willing to become partners in this way. And so I think there's an opportunity for us to build a bit of a directory that says I'm on the partner, you know, on the product management side or on the, you know, engineering design side, meaning the front end. And I'm on the back end, right? Just like we used to have a distinction between front end and back end engineers. Now we call them full stack 'cause we're like, no, actually they need to be the same person. And ultimately that will become the evolution of what we're talking about. Like eventually the technology is still new. VibeCoding like instant, like was instantly available to us like 6 months ago, right? I think some of you were like in the early days of it. If you know a little bit about how these models are growing, right? They are exponentially growing in capability and power, right? So within 5 years, these models will be 1 million times better than they are right now. We can't even really conceive of how good they will be. So they will be able to write their own unit test. They will be able to, like, they'll be able to anything that you were gonna ask, like, Reina, you were gonna ask this technology person, those models will eventually be able to do. It's just we're in the gap years right now where the technology, you know, we're exciting the world about how to build and the technology isn't It's not perfect. Like we haven't stitched it all together. MCP is still brand new. But in over years that will get better. But in the interim, in the next 3 years, these partnerships will be critical. And I, I don't think that's a reason to wait. I actually think it's a reason to go because you have an opportunity to build something that most people are like, I'll just wait till the tech gets better. I'll wait till it matures. And you have an opportunity to create that moat that David was talking about. So I just share that with you because you actually are amidst your friends here that can help you with this delivery. Some of us have built companies around delivery. Some of us are delivery people ourselves where we actually build it. And many of us, if it's not us, have networks of engineers like myself. So I, yeah, I anticipate that we're going to have to build some kind of directory so that you can post a project or an idea and that someone with the technical expertise I just worry about ensuring viability. Like, I've seen so many people say they can do a thing and then get into it and go, ooh, actually, I don't know nothing about this. And all of that is at the cost of us. Like, we pay for that mistake. And so I— yeah, I would love to create a validated, viable list of people that we could trust to deliver on our ideas, and we're paying them, like, you know.

Noelle, I was just going to ask you a quick question. I did take a look at what Soumya had shared. It's on a higher level than what she shared with us in this meeting. And so you indicated that you were going to— is a video of this going to be made available?

Yes.

All right, great, because it's hard to— it went so quickly on the screen.

No, I know.

It was such a high level on what she's given as a link. It's like there's a gap in between.

So we're going to provide the link, we're going to provide the video, but we're also I'm also gonna take the transcript and put it into ChatGPT and build a lab, like a guide based on what she said. So, but all of that sits inside of the community. So, and obviously this is like Somia's, it's kind of like her IP. Like, I'm really proud of it. Like, this is pretty amazing. So, so obviously don't share with anyone unless they're like in our group because we vetted everyone who's here. And of course, if you're watching this on LinkedIn Live, you know, come on in. You could join us. But we do like to, you know, just make sure that we're using this, the right people are using it, that we're not, you know, misusing people's information. So thank you for that question. But yeah, we're gonna make it much easier for you to go back. We call it live learning. So it'll be one of our live learning labs. You can go back and kind of do on demand. Great question. And Padme, I see you.

I'm so sorry.

I saw your hand and I was like, oopsie. So hi, are you still there? Are you still there? Maybe you've long forgotten us. Oh, I'm still here.

Okay, good.

Sorry.

So yeah, so thank you, Soumya, for a great presentation. I just wanted to, just based on what you were saying about models getting better over time, just wanted to add in a little more that, you know, right now when our models are trained, they are trained on completed code, like code that has worked. And looks good. But a lot of learning happens when we are writing code and doesn't work, we go back, rewrite it, and all that. So I came across this thing called, you know, RLCE as opposed to RLHF, which is reinforcement learning from human feedback. But there's RLCE, which is reinforcement learning from code execution. So which sort of, you know, which takes in the human judgment and all that. And there are two companies that are actually doing this, Cosyne and Poolside, which sort of are getting the learnings from, you know, all these, the trial and errors. So those then help get the models even better, just going to what you were saying, Noelle. So I just wanted to add that to the audience here.

Oh my gosh, I love it. If you wouldn't mind throwing those two links into the chat.

Sure, I will do that.

Yeah, that's so awesome. What a great, what a great thing. And of course, that means now we got to teach about it.

Yes, yes, absolutely. So awesome.

That's amazing. Yeah, great to see you. Yeah, exactly. Javier, you're one of those people that people can lean on. Anyway, there's quite a few of us. So many times we don't, you know, we get a couple minutes to like hang out with each other, but, but I wanted to offer you one. So you see the the framework. I do think I want to share with you a couple of the things that I've vibe coded before the end, but we still have a couple of questions. So thank you, Padmini. Mauricio's here. We've got a bunch of OGs in the house today. So great to see you, Mauricio. Question, comment, would love whatever you'd like to share with us.

Thank you, Noelle. Just, I mean, thank you so much for the colleague that brought the Vibe app. Presentation and also for the colleagues that contributed to the discussion. I didn't hear the term, but I think half hour— I was driving and I couldn't participate, but half hour of the discussion revolves around technical debt. So you guys will hear that term, and maybe, Noelle, you want to expand on that, but it is is pure technical debt. At some point you're gonna have to hire an engineer if this is gonna scale to more than 1,000 users. As long as you have 1 or 10 users, your tokens, even on the free account, will carry you. But, uh, at some point, if you want to sell this— think of this— if you want to sell this to more than 100 people, even Chatbot Builder will call you and say, hey, you You exhausted your tokens and then you need to rewrite the application. Then the question is, should you spend that time better on the front end? Maybe take $1,000 of your budget, hire an engineer for a few hours, think about it, or do you want to spend $2,000 later? That's— yeah, that's, that's the question. There's no answer for that. But I just wanted to bring that up.

Oh my gosh, that's such an important topic. I'm surprised, yeah, we didn't talk about it earlier, but it's such an important topic. But I guess, you know, it's because this topic ends up coming a little bit on the more advanced side of live coding, right? This was meant to be like an intro, like let's have some fun. Also, let's free ourselves from thinking we can't do this. So that's why I love this framework. Like it allows all of us, regardless of our tech experience to be like, I can build something. And then that partnership with like, how do I actually deliver that at scale or to an audience in production? That gets more complicated. But this concept of tech debt is so important because, and for those of you not familiar with the term, it basically means like every technical decision, especially with live coding that you make, it basically is a trade-off that you are making. And right now you're making the ultimate trade-off, which is the easy button. That you are pressing an easy button to build you technology. And this is not new, this is not, uh, no, like, it's not original to me, but it is known that the software engineering, the code that comes out of these systems, it is not—

I—

it's not in any way meant to be production level. So it's not secure, it's not, uh, it doesn't adhere to data policies, these, it doesn't really— I mean, not by, by default. Obviously you can encourage it to do this, but by default it's just building you kind of a little minimum remarkable product, something that you're like, oh my gosh, I just built a web app and it took me 6 hours. Um, but on the back end of that, the most common problems these apps run into is that one, you're going to either realize— because when you press an easy button, you're paying way more for something than if you build it yourself. And that's almost always the case, right? Like, you could build it something yourself or build something in your own infrastructure, and it's cheaper than if you go and buy a software as a service product. And it's always a trade-off. Like, the benefit of— like, with, uh, software as a service, right, the benefit of paying for something $50 a month, like my Supabase database, I pay $50 a month, but I don't have complete control as a sysadmin over that database. Lovable does. They own that. Well, I should say Supabase does. And then Lovable has even abstracted what Supabase would give me as an admin. So I am twice removed from the ability to control that asset, which means, so that's the debt, right? I'm now in debt because I do not have access to that system. So should something change, should I wanna do something that's not supported, I'm gonna have to pay that debt back because I'm gonna have to take that and reinvest it somewhere else. So I think the moral of the story is that none of this, even though it's easy, it's none of this is free. That if you get serious and you decide to go to market, you're going to pay the piper in one form or another. Like, you're going to either have to pay to rebuild it, or you're going to have to pay an engineer. Now, here's why I like Lovable. Lovable does allow you to passivate, meaning save your project infrastructure in GitHub, which is what I do.

To.

So it becomes real code. Now, this is what Reina was talking about. It's this moment of like, well then, when does it become me in Lovable versus me in GitHub? And it really can't be both. Like, because you can't, you know, you're gonna basically eventually want to do things that Lovable is going to restrict based on the easy button that you have. So, but that's at least the good news is that your code is created, available, and in a repo you own. Not all models are like that. The more abstracted you are, the less you even know where the code is. As a matter of fact, Claude, I mean, Claude is of the perspective that code is irrelevant. Like, you don't even need to know what the code is. And I think one day we'll get there. But yeah, I think this is a really important point that you will, like, this tech debt does need to get paid eventually. And if you do not pay this tech debt, it will end up in compromising the integrity of your projects long-term. And so it is, every decision you make is a compromise. And it's a good question. That's why I think, Soumya, in your framework, you ask these types of questions in the design phase, right? What should I be worried about? What does this look like at scale? And even if you don't solve for that in your MRP, those types of questions will at least give you insight into things you need to be thinking about. So thank you, Mauricio, for bringing that up. Anything else you want to add to that or clarifications or another topic?

Thank you, Noelle. Very well said, and I appreciate your extra comments. Very insightful. Thanks as always.

Oh my gosh, such a good topic. Thank you for bringing it up.

The other comment that I had is just a marketing comment for the colleagues that even if it takes you 5 minutes to do something, it's nice to brag about it. It never took you really 5 minutes. It maybe took you 10. And second, if you're trying to sell that, who would pay for something that you spend only 5 minutes? If even if your, your consulting hour is $200 an hour or $240, that's only $20, and the customer will ask you for that time for free. So watch out how you come across as how proficient you are coding. Oh, I did in 5 minutes, against the perception of somebody, well, if you did in 5 minutes, maybe I can do it in 5 minutes too. And I don't need you. Or maybe give it to me for free. Anyway, that— can you comment on that? I mean, that's kind of—

yes, that's such an important point. It's funny, because we, like you said, it's kind of like, we're like, oh my gosh, can you believe what I did in 5 minutes? But the reality is, And that's why the framework that you showed us today, like a lot of us do a lot of that work, certainly product management type people. We do a lot of this work in our head and some, right? Like that we talked about, like these ideas are years in the making in our head. Yeah, like years we've been thinking about how to solve a problem. I mean, that's what people are paying for. So it's so easy to be like, it only took me X number of minutes or days to build. But building is not the economic currency, right? It is the ideation. Because just like you said, like, all of this whole framework, the last 10% is building. The 90% is thinking, asking, ideating. And that is what you want to talk about. So I actually try to avoid, as a solution architect, I try to avoid talking timelines at all. Number one, because it's really not fair. I'm not going to cash that check. Check, right? I'm not the engineer having to build. So it isn't fair that I say, hey, I did this in a certain amount of time. But even if I am, it's not fair to me because, like you said, Mauricio, it really isn't. That isn't the case at all. It actually— it is my life experience that allowed me to build something in 5 minutes. So, so it's just a— it's a paradigm shift because it seems pretty cool that we can do something, but we tend to dismiss what we would have had to do in our lives to create capability, and it is not something, you know, it's, it's not something that you should— I always say, don't, you know, don't sit on that. Like, that is your, that is your career. That is your lived experience. That is every customer you've talked to. That's what allows you to be really quick when you're starting to talk to a machine about this. Yeah, yeah, exactly. Yes. I mean, I don't think he was talking about you per se, but I get it. Like, in this room, you could definitely say, It only took me 10 minutes, but I will tell you, when I sell these vibathons, I used to do— I did 140 hackathons in 2014 and 2015. I delivered them. I was like, I delivered them. And I did MIT, Notre Dame, like all over the US, all in universities and colleges. And one thing that I knew about that experience was that 80 to 90% of the time was spent building. Only 10% of the time was spent designing. And that's because it— you had to, or you wouldn't have a working product. Like, you had to basically start with the tech and see what you could get to work and then kind of mush that into a pitch. It is completely the opposite with Vibe Coding, right? With Vibe Coding, we're going to spend 75% of our time doing what was in this framework— designing, thinking, asking. And then when we partner with an AI system, it's gonna be able to generate it. You know, if I spend 3 hours, 3 hours is spent designing, an hour is spent building. And that's what I mean. I'm delivering a lot of these vibathons inside companies. I have one coming up in November inside a company that I'm super excited about. But like, they don't even realize that they're gonna spend more time designing than they will building. And then they don't also realize that when they actually build it, they're like, oh my gosh, that's exactly exactly what I, I wanted. Like, they will be surprised at how tightly correlated their ideas are to the outcome in a 4-hour period. And that's, I think, what the essence of vibe coding is, right? Is that you're shifting from how do I learn the tech and then mush my idea into the available tech to starting with, you know, I love empathetic questioning, right? Who's my user?

What do they do?

How do they do it? And then using that to drive you know, a prompt that I'm gonna use to build out the implementation. But yeah, I love that though. So, so good. Okay. Thank you, Mauricio. Anything else you wanna add before I go on to Tara?

Oh, actually, Tara, I'm gonna let—

Thank you, Noelle.

Yeah.

Yeah.

You're welcome.

Thanks for being here.

I hope you—

Yeah.

I'm glad you enjoyed it so far.

Thank you. Yes.

Alonzo, I'm gonna go to Alonzo, and then I'll come back to you, Tara.

I just had a question. So I understand the way you and Mauricio were talking about technical debt where you use this vibe coding, but then when you have to like roll out for production, that there's some issues to be resolved. But I'm a little confused because there was an article that was released. It was talking about Microsoft rolls out like AI tools to tackle $85 billion of technical debt, but then they're using it in a different way where it's like, I guess they're talking about like legacy systems that may not play as well with the new large language models. So is technical debt both, or is there like a more general definition to describe it?

Oh yeah, no, it's definitely one definition, which is every time you build software, you're trading off something. So in order to get certain features out, you're gonna have to, for example, let's say we have a deadline of this Friday. I might, I could think through what it would take to build a relational database infrastructure and maybe an object-related, you know, use an object database. Maybe I could think through that, but I don't have time for that. So I'm just gonna use the easiest, most available access that I can, and that's gonna be my old language of Java, 'cause I know it, and a JDBC connector, which is a Java connection to a relational database. That's what I'm gonna build. The second I, as an engineer, make that decision, technically I could have done it better if I had more time. So I've now put myself in debt knowing eventually I'm gonna have to fix that. And the idea of vibe coding is everything you build, likely you're gonna have to fix. Likely is not gonna be the exact same code that you're gonna put in production, that you're basically building a prototype that you'll have to rebuild. Now, I, like you mentioned in the, um, or, or earlier, like there are, every one of those platforms has an article saying that they've got customers that are not rebuilding. That are able to achieve production value on their platform. But then the tech debt you have is that you need to acquire a skilled person who knows what questions to ask. Because this is the danger. If you're not an engineer, you don't know to say, "Hey, can you refactor the database to ensure I have the lowest level of latency?" You wouldn't even know those words, like, right? So either you will have to rebuild on a platform that understands the way you speak, and can build these technical pieces. And I think in the future our models will be capable of this, or you'll have to hire someone, which now is you paying a debt, right? You built something, now you have to pay someone to come and manage it for you or build it for you. So it's the same for both. It's just old tech debt. I mean, it was part of the deal. Like, I think we, we don't even— it's not a monetary thing, right? It's a concept of work. So remember the backlog we were talking about? So when you build something, usually a developer, when they make a choice, will go, okay, I'm gonna have to fix this later. And they will create stories in their, like, workflow, like little activities, tasks that say, I need to update that driver. I'm gonna have to update this. I hardcoded the database user ID and password. I'm gonna have to go do that later. And all of those things get a point of work associated with them.. So that I, as the manager, can go in and go, wow, we've got 620 days of debt that we need to pay back in order to make this what we want. And so it's a level of currency in application development or software development that it's so important that we talk about. Because yeah, you're acquiring debt. I think, though, to be fair, Claude truly believes that all of that's irrelevant. That you'll acquire tech debt, but it won't matter because you'll deliver something that's good enough to get clients. And, you know, like they're playing the game of they really are planning on putting software engineering completely out of business. But we'll see.

I mean, yeah, I guess that's what they're saying. Like right now, like you said, if you're using like old equipment and you don't want to replace that, then you're going to spend the debt like trying to work around that. But I guess their way they're saying is that like I mean, the new agents, maybe not the current generation, but they'll be able to do all, all of it. Like they can work with all equipment, they can go out there and spread out to your network and you don't need the specialist. But I don't see that yet.

But not—

yeah, I don't see it yet either, but it is just an agent away, right? So, and this is a business, like somebody in here could go and build like SAP to, you know, Salesforce integrations and build agents that do that.

The beauty, right? That's what I'm looking at.

Yeah, yeah, that's right, that's right. That's why Roel came today. Um, but like building, you know, back in the day, and Roel did this work like for real, we hardcoded these systems together. Like we wrote the code and like tied them together. It was called enterprise integration, like enterprise application integration. Now It's the same exact work, but we're gonna build agents that exchange inputs and outputs and do that data transformation on behalf of whatever activity, whatever part of the business process we're doing.

We're not a—

at a level of maturity at like in the enterprise where those are massively available. As far as I understand, most of the big consulting consultancies are building these little agents right now. So in the next 2 years, maybe, but you're right. I don't think we're there right now, but There might be people that disagree with me, um, so please do. We, we, we believe in, like, you know, what do we call it, like, positive discourse.

One of us will build it. All right, but thank you so much for the clarification. That helped sorting it out.

Awesome. Okay, Tara, I'm coming to you, and then, uh, Javier, and then Marcy, I'll come back to you unless you forgot to lower your hand.

Um, so Honestly, until today, I actually forgot about beta users. My first tech writing job a million years ago, you know, we were actually, the instructions were written in binary code for the people who were going to use our product. That's, that's how many years ago that was. But now I realize the importance of it. So my question comes back to pricing because I can see that I would want to release a version, this first version. I would need feedback, but also I want to start building that, the money side of it, like making enough money. So when I get ready to release it at scale, there's money in the bank to do that. Because right now there's no money in the bank to do that.

Right.

So you've done this a lot. Do you suggest like a software as a service kind of a monthly fee or like you're buying it once? Here's the cost, move on, sister.

Yeah, I'm not a big fan of like one-and-done kind of things. Um, I like long-term marriages, long-term friendships. Um, so I like the SaaS model. Uh, and the nice thing about the SaaS model is that you're acquiring monthly annual— like monthly recurring revenue and annual recurring revenue. I like both options. I will share with you that from a pricing perspective, First, you have to figure out what is the value of this thing to the market, meaning what problem are you solving and how much is it costing them to have that problem now? And if you build a product that solves that problem, can you correlate that to the value of what you do? Not how much do you want to sell it for or how much do you think you can get for it, but like literally what value are you generating? And if it saves them $1 million a year, like you need to change your pricing to accommodate. Like, hey, I'm gonna solve a million-dollar problem for you, you know, here's where it starts. However, in the stage you're talking about, which is in the beginning, beta users, this is what I've seen be very successful. And, and I am a design partner for many, many AI companies, but like, they will say one of two things. A, I can get access to their software for a very low price, like 10% of total value.

In—

but because I'm getting it at that low price, my currency is my feedback on the product, right? And you only take maybe 10, 25 of these people because how many? Okay, right.

Yeah.

And so you create this super low— but the benefit is, is all of them now become your testimonials engine. They become your like adoption engine. You want to pick them carefully, make sure they have big audiences or big customer bases, right? Like who— you don't just say, hey, anybody come and join for You know, whatever this price is, you want to make sure that the people you choose are scaling partners for you. So if they do end up finding value and you do deliver on the promise, that they'd be like, oh my gosh, I have to tell everyone I know. And that isn't like 2 people. It's like they have some, some value there. So you're giving them— come here. So there you're giving them a really small price. But they're exchanging that value proposition is in exchange for their information. So I would create— you can use ChatGPT— create a design partner program, give them a— not complicated, but give them an expectation of like, hey, you're getting this, but let them know what the real price is and what their discount is, and that they're gonna be getting, you know, 1 hour a month with the CEO to talk through their experience with the platform. So to let you know, I do this for HeyGen. I've done it for ChatGPT, well, Codex specifically. I've done it for Remind and Limitless AI. So usually, and this is what I think you should do too, is if you have like a way of identifying these people, you— they just emailed me on LinkedIn and was like, hey, we noticed you're a user of this type of product. We're building a similar product. Would you become a design partner? And I pay— like, sometimes they'll do it for free, but I feel like there's value when both people have skin in the game. And so I just say that. Can you just open it up for free and say, hey, I'll give you free access?

Sure.

But don't be surprised if they don't show up on calls. And if they don't, like, you know, like, um, I feel like there's, you know, make it small enough that it's negligible, but there's still a transactional relationship being built.

No, that makes total sense. And you made me realize where I need to find them because mine's, um, is dealing with a particular learning disability that frustrates the heck out of me. And so when they were— you guys were talking earlier about like what we've been thinking about this forever, designing it in our head and blah blah blah. I'm like, oh my God, for years I'm like, why doesn't this exist? And so now I can make this thing that doesn't exist. So I would get in a group on LinkedIn or wherever that has that same learning disability and maybe do a survey like, "Who would want to help me with this?" and get them involved.

Yes.

And I mean, this goes to the accessibility mantra, "Never for them without them." Yeah. And that's true for every one of us. Do not build anything unless you have someone who you're building for being like, "Oh my gosh, I would love that." Because you're going to think they love it and then you're going to deliver it to them and they're going to be like, "But why did you do this thing?" Like, I have so many other problems.

Okay.

Because we think that— I mean, I'm a mom of a special needs child. I think I can solve all his problems, and 9 times out of 10, he's like, so of all the things you could have solved for, that's not the one. Oh, I don't do that anymore. I always start with them. Um, and you could do this a bunch of ways. You could build a survey. You could also create a think tank, right? You could invite people to become part of a community, just a call. Right, where they join on a Zoom and you give them information about the latest research that you're doing. But at the same time, you ask them questions. Like, there's a lot of different ways you can do it to create value.

Cool.

Thank you.

Appreciate it.

A nice approach is to, if you could find one person to, like, develop with you, partner with you, because they're the user, they're using the tool, they know how to do this, and they partner with you as part of— I remember years ago, When SAP in the beverage industry, I know SAP didn't know anything about the beverage industry. So what they did, they partnered with Coors. Coors, so Coors get the rollout first. They tell them what to do. They test with them. They work with them. So they perfect it. When they perfect it, now they can sell it to every beverage company in the world. You know, so that's a nice way to, to, to do it. If you can find someone who can work with you. Yeah.

And that's ultimately is the challenge, right? Uh, is that you will have to be be patient in identifying the right partner. And that's the same thing on the engineering side.

Like, these—

the human partnerships are the most important things that you will develop. And sometimes it's so hard that people just give up. Um, you know, like, I've had, I've had entrepreneurs who have invested in implementation teams like 10, 20 times, and each one costing them $20, $50 grand, and it just like, like gone. Like their money's just gone. And I'm like, I, I don't know. Anyway, it's not a good situation. So that's why I'm really, I'm really interested in— Deb's not here anymore, but I'm really interested in her, her question around like, how do we create a trustworthy group of implementers that know how to do what we're just talking about? Um, and they don't necessarily have to be here. Like if you know someone who's trustworthy, that's good. Like we would take that recommendation I just find there's— I, I used to say, uh, there's 5 people in the world that can do what I do. And then when people would go, like, they'd be like, okay, great, nice talking to you, Noelle, and they'd go and try and find other people, and then they'd end up with back in my inbox 5 months later, and they're like, so who are the other 5? Because we talked to a bunch of people. Um, so I do think, like, a lot of— there's a lot of opportunity if you choose to dive in, especially if you're on the engineering side and willing to get out there. I just find it's a huge problem for companies is finding trustworthy partners to help them build this technology. And of course, I think there are CEOs in this room and CTOs in this room. And so we have an opportunity to really work together and do some, some cool work. Okay, awesome. Wow, that was fun. I think it was fun. Did you guys have fun? All right, so I wanted to, in the last few minutes, uh, we always like to get together, um, and, uh, get to know each other a bit. We have a lot of people on this call, so we'll see how it goes, uh, but I do want to give us a chance. So we got the framework, um, from Soumya. I would encourage you, uh, we're also going to create the little step-by-step guide, um, we'll do that today. We'll post it inside the I Love AI community as well as inside the AI Leadership institute, so you don't have to bounce back and forth depending on which community you're in. Um, and but I would love to encourage you all to share what you build, and I would, if I were you, I would just build something that new. Don't tie it to something you're super invested in that you're building right now for you. Like, just have some fun.

Like, and the 5 platforms, the 5 platforms that you want us to try out.

Oh, I actually put— yeah, I'll repost that. I just put a, um, uh, a link to the top 10. You could pick any platforms, um, but it was like the top 10 2025 vibe coding platforms, and I didn't make the list, but it's helpful. Um, I'll try and find the link and re-share. Oh, here it is.

Sherilyn, I already beat you to it.

Oh, I mean, yay! Thank you, Sherilyn, you're awesome. Of course you did. Thank you for that. Perfect. So, and we'll of course put both the link to the framework and we'll also put a link to, a link to the, to that list so you can see. But like I said, I would just have some fun. Like, the other thing is, is if you come to it with an idea that's a bit fully baked, you're gonna run into that scope problem, right? You're gonna immediately start building way too much. So try to think of just a cool idea. I always like look at my life.

I'm—

I'll tell you, I am right now, which I can't use this idea because I'm already too far down the pipe, but I am building this beautiful, amazing email like interpretation system that can just tell me which emails are important and which ones aren't. But this specific contextual to me, um, because none of the apps I use work, uh, they all work a little bit, but none of them work perfectly. And so I'm building my own. And that's, I think, the world we're in right now, right? Is like, think of a problem that just bugs you and that you have tried and even bought other things to solve for. And you're just like, nobody get— nobody's gotten it right. And think about what a minimum remarkable version of that might be and build that because it's super rewarding. But then be careful because you might end up being like, I have to start a business now and I have to quit my job, which happens to the best of us. So that's, um, anyway, so I hope you enjoyed today's session, but I do want to, for those of you willing to stay, we're going to break up into breakout rooms, and I just want to present a question to you all to contemplate and share. So, you all will be in one of the groups. I'll be in one as well. I would love for you all to share either a vibe coding experience you are, you already had, and some of you have shared already. You know, you can elaborate on that. But also what, like, what ideas you're thinking about, because I think the biggest challenge right now that I have when I go into companies is they can't figure out what to start with. And so how, you know, how have you done that? If you've already built something before, like, how did you figure out what to start with? Because I think that skill set is, it's really hard. And I would love for us to share a little bit about You know, how do we select the right project? Like, how, you know, of all the things, and there's no right answer. That's why I like this question. I would just love for all of us to share, like, what is our process of figuring out what's the most important thing we do using this technology these days? So I'm going to break us out into groups. You'll have a chance to talk about it. Don't forget, you have a chance to also introduce yourself. So there's going to be about 4 people in the room. Just give everyone a chance to just go around and say who they are and what they do and how they help people. Ideally, if you need help, you can also use this moment to ask for help if you want to. But we wanna just get to know each other. I think it's really cool. You'll get a chance to meet not just I Love AI people, but also AI Leadership Institute. And that just means we're gonna be on a broad spectrum of AI capability. And so I'm so grateful that you are here. Let me open this up right now to our breakout rooms. Oh my goodness, there's a lot. Yeah. So now's your chance if you don't want to hang out with people, which is totally fine. No judgment. Like, we love you all. But if you don't want to be in a breakout room, you're welcome to either leave or hang out and wait 10 minutes and we'll come back and close out the session. But we will be providing all the details on implementing and following the guides and the steps that Sonia went through. We'll be doing that in the classroom. So we'll send out a link with that information. All right, here we go. Yeah, here we go.

Here we go.

All right, there we go. I think— oh, goodness. There we go. I think this is it. So I'm gonna try— there's a lot of note takers today. So I'm gonna try and make sure that we don't have any note takers in, in the room. Room 10 is our note taker room. All right, moving you to room 10. All right, here we go.

All right, moving you to room 4.

All right, we're doing good so far. Notetaker AI out. Goodbye. And I have someone on an iPhone. I can't tell your name, so hopefully it'll be all right. I'm just gonna throw you in. I'm hoping. Let's see.

Wow.

All right, that's not terrible. 1, 2, 3, 1, 2, 3, 1, 2, 3.

What?

There's all these nice people I haven't had a chance to talk to. Hi, Tracy. Hi, William. I didn't see you all on the video. Maybe you were on my second screen. So good to see you all. It's been like 2 and a half hours, but I see you. All right, awesome. Let's move this one to room 10 and you up to room 8. Almost there. Almost there. Hang in there with me. Room 8. And then note taker.

Oops.

Let's move you to room 10. All right, we're gonna have— All right, I'm gonna move you to room 9. All right, I think we're good. I think we're good.

Everyone looks good.

If you see a note-taker in your room, I'll do my best to get rid of it. You can also kick it out, I think. But if not, I will. I'll do my best. All right, thank you. Have fun. So just talk about, like, how do you come up with a good idea? Or if you have a good idea, now's the time to share it. All right, have fun. Accept the button. Click the blue pill.

Ciao!

All right, everyone who's on LinkedIn, thank you for joining us. This was super fun. We are so excited. This was a vibe coding day. We haven't done one before, so this was really fun to get an idea on some ways of thinking about vibe coding, uh, in your spare time or even as a profession. We walked through Somia's amazing framework, but if you want access to that framework, you will have to join us in the I Love AI community, which you can do by just going to noelle.ai, noelle.ai. Join one of our communities. We have a free community. We also have an upgraded paid community where you get to get your fingers on a keyboard and build stuff. So thank you all for being here and we will see you next time. Bye everybody.

I only had