The #1 Hack to Build Apps With AI Without Getting Stuck | Colin Matthews

This is the technique that I just call reflection. But basically what this is is giving it all the information about what we want to build and then asking for a plan first before actually kicking off any type of coding here. And the reason why is it's. It's twofold. So one is you'll get to see what is going to happen, which, you know, allows you an opportunity to modify it.

Right.

If there's something in here that you don't like, you can change it. And then two, also actually learn a little bit about what's happening. By default, these systems are built to write code, and so if you ask a question, it might just go try to fix it for you.

Right?

Like, it's not necessarily going to wa. And so saying don't write any code gives you that opportunity to read this. And so it will do a better job. Even if I don't read this, if I just ask it for the plan and then say go and I don't even look at it, it will still do a better job most of the time.

All right, welcome, everyone. My guest today is Colin Matthews. Colin is a Rockstar instructor who has trained over a thousand PMs on how to become more technical, and he has an exciting new course out about how to prototype with AI. So I'm really excited to talk to him about how to pick the right AI prototyping tool and how you can build an app with AI in just like, 30 minutes. And we're gonna do a. We're gonna do a live walkthrough, so you should be listening to this, hopefully watching this on YouTube, so you can see Colin's screen share. But anyway, welcome, Colin.

Yeah, great to be here. Thanks, Vitik.

All right, so before we talk about building the app, let's talk about different types of AI prototyping tools. You know, there's, like, so many prototyping tools out there now, and, like, how do I think about which one to use?

Yeah, good question. So different tools are useful for different, basically, application stacks or different parts of the product. I actually have a little demo. If I can share my screen here. We'll just hop in and I'll share that right away if that sounds good.

Yeah, go for it.

Okay, cool. So let me share and we'll take a look. So, yeah, this is a little framework that I've worked on previously with Lenny in terms of choosing tooling. So we grouped it into three main categories. We have chatbots, kind of cloud development environments, and then the local development assistance. Chatbots are really only going to work on client side code. One quick kind of clarification here is that any of these things can write code for any part of the stack. So, you know, like ChatGPT can write server side code. Really what we're talking about here is the ease of use for you to go and use that code. So, you know, you have to know what to do with that server side code if ChatGPT writes it for you. And so with Cloud or ChatGPT you can basically write, you know, little front end applications. But then when we move over into cloud development environments, you can see that, you know, we can do client side, server side databases and also deploy onto the Internet. So this is where most people are going to want to sit. And then finally we have things like Cursor, windserve and so on that again are going to write code for you. But then you have to know what to do with that code, right? So you have to know how to run it on your own machine, how to deploy it to the Internet and all that good stuff. So typically I recommend, you know, sticking to the middle here, one of the options here, but you know, depends on what you're trying to do.

Okay, so let's talk about the middle a little bit more. So you have V0 repreplate, agent, bottom and lovable. Which one should I start with or what are differences between?

Sure, yeah, so they definitely do have some differences. I'll start with, let's say replit, just because I think replit is probably the most unique out of the set. So replit can do everything that you might want to do in terms of writing your client side code, writing your server side code, actually hosting a production database for you. So this is an important point that none of the other ones, if you want to store data in a database and can do that by default, and then also deploying just using replit, they have their own deployment tooling, replit. Also I have personally found like just playing around with it is the best at building more like data driven applications. So you can write applications using Python and libraries like Streamlit, which basically help you build, you know, like an internal tool or you know, visualization of data or a dashboard, stuff like that. I found replit to be really great for, for Bolt. I've personally found that Bolt is the most flexible. So there's really no, like there's some strong defaults but you can get around them pretty easily. And that's actually really nice sometimes. I'll show you an example of that later on where sometimes we actually don't want the defaults and it's pretty easy to tell Bolt not to use them and to get what we want instead. And then Lovable is kind of like an intermediate one, to be honest. It doesn't have a code editor. And you're going to see the importance of a code editor a little bit later on, actually, even if you're not technical, having the code editor is pretty important. But it does have some nice integrations. So like you can connect to Supabase, you can connect to GitHub, push your code out, or deploy automatically.

Yeah, so if I want to build like both server and client, I should just start with V0 bolt or replit or something.

Yeah, exactly. So if you want client and server, then you know one of the, one of the options down below. So V0 bolt, lovable or replit, that'll get you both of these here. And for a lot of applications, you're definitely going to want both a client and a server. And then finally, like we talked about for storage, if you want to store data in a database, you know, Repli gives you that by default, which really easy or you have to integrate with an external tool if you're using one of these other ones in order to get that database.

And what are some of like some personal apps or things that you built that are actually useful through AI? You know, do you have like some examples?

I built like two things that I use on a weekly basis and then some own some tooling to solve my own problems as it relates to teaching. So two tools that I built. I actually don't know if you ever run into this is with substack, I could never get the images table to fit correctly. Like there's a default size that it tells you should use, but then my images are always cropped incorrectly. And so I built a tool with Replit that I can upload an image and it basically resizes it so that it will fit correctly. With substack, it just resizes my images for me. And so it's nice because I don't have to think about like aspect ratios or anything when I'm creating the image. I just throw it into the tool afterwards and then it resizes it for me. So that's one. The other one is actually a gif, basically converter. So I was having a lot of problems with getting GIFs to load into subsectors like file size limits. And the online converters that I found, they would all output files that were massive in size, even like Adobe's. Adobe's was not very good from my opinion. And so I went and I built my own where like, I could control, you know, the file size, the duration, I could do like trimming and stuff like that. So basically my own little tool for creating GIFs. And you could actually buy something like this if you wanted to. Instead, like you can spend, you know, some amount per month or 25 bucks one time, or you can just build it yourself in 20 minutes with Replit. So those are two good examples.

Nice. Yeah. I don't know why Substack wants to have a different ratio with the social share ratios is super annoying and I've just kind of given up. I guess I can do figma. But yeah, it's really cool that you build a tool to. It's interesting because I think AI is really good at solving very specific problems. Like a simple tutorial to solve a very specific problem.

Yeah, you know, Yeah, I agree. And for that specific one, I even added some features where like, it detects the background color and then when you, when it gets the correct aspect ratio, it adds the border and that background color. Yeah, Right. So it maintains the image as it would appear. But that's some of the stuff that you can just like ask or repl in this case to do that and, you know, it'll figure it out. I didn't tell it like, what, how to implement that. Right.

Like, another really strong use case, especially for PMs, is, you know, like the designer will put together some sort of figma mock. Right. And then usually what you want to do is you want to explore multiple different mocks or multiple different options. So I found that using these tools before, I would just give some feedback to a designer, like some text feedback, but now I can actually just paste the mock into AI and be like, hey, can you give me some other options? What about putting this here or what about doing that? And then it will create a bunch of different prototypes. And I'm not sure if that offends the designer, but it makes it much more easy to share my ideas visually. And then a designer can continue to iterate and make it better.

Yeah, I 100% agree. Actually, there's a topic that I like to talk about which is building a prototype library so you can actually just take a screenshot of your application and rebuild it inside of one of these tools and then continue to create copies for different ideas. So like, let's say you're, you know, you're the PM at, I don't know, Reddit. You actually were at one point and then you wanted to like prototype a Gen AI feature. You could build a really quick mock of Reddit and then continue to go back to that so you don't have to redo that work and just create a copy and then prototype like your Genai feature or prototype some changes to comments or something like that.

Yeah, that interactivity really brings it to life. And also it's actually also really amazing at running Product Compute to make it more concise and more clear and stuff.

Yeah, exactly. The cool thing about these tools, which maybe isn't always clear to folks, is that behind the scenes mostly it's using Claude SOM 3.5. It could be using different models as well, but you can ask it to do things like inside of Bolt that are just general, like ChatGPT esque requests in that context and it will actually do a decent job. Right. So you can ask it to like rewrite the copy of your landing page. You don't have to pull that out necessarily to Claude to do that.

That makes sense. That makes sense.

Yeah.

All right, man. Well, let's get into it. Let's actually try to build something with AI with all its imperfections. So what should we build today, Colin?

Yeah, so we're going to build a to do app. I kind of have some quick little mocks over here if there's any designers listening. Sorry about that, but this is my little, you know, new year 2025 habit tracking app. So I'm going to walk through a little bit about the, the design. You'll see the workflow that I walked through as well. And then I did write the prompt at the beginning just so you know, we'll save a little bit of time, but I'll explain, you know, why I wrote it the way I wrote it. And then we'll continue to iterate on this over time. So yeah, just to go over the actual features here really quick, it's pretty straightforward. We basically can store habits and then also market we completed those habits. So you can see, you know, we have on January 17, I have three habits. And you know, I have these streaks because I've completed the habits over time, I have the ability to add a new habit. And then over on the right hand side, this will be a detailed view for the habits. So we able to see, you know, for running which days I completed it and then which days I didn't. Right. In the kind of in the past or in the future. And that's pretty much it. So just these two screens, one like kind of main screen and then one detail Screen on the right hand side.

Yeah, this is great. Are you sure you're not a designer? Because it looks great.

Yeah, it's not a bad set actually. This is a funny thing. If you are planning on doing something like this, I'd recommend doing a lo fi mock. You can include it in the prompt and it just one. It helps you think about it.

Right.

Like, and you'll see this throughout, that being more specific is always better. So in order to be specific you have to kind of know what you want. Right. So doing these types of mocks or thinking about a little bit ahead of time goes a long way in terms of getting better results. Makes sense. And yeah, we'll just run through this prompt really quick. I'll paste it over into bolt. Actually, you know what, let's do that first. I'll paste it and then explain it as it's working on it because it'll take it a little bit. So I'm going to grab that. I'm also going to grab this and just copy this to my clipboard and paste it in and you can see, you know, basically follows what we just said. So, yeah, the prompt here. I want to build a habit tracking app and should complete or should. Allow me. Let's go back up. Allow me to enter new habits. Mark if I completed the habit and then show me a streak of how many days in a row I've completed the habit from the current date to the past. And you can see I'm pretty specific about the interface here. So I say put the date at the top with left and right navigations to change the date. Each tracked completion of the habit should be associated with a date and habits can be complete or incomplete on each date. So I'm both describing the user interface as well as a little bit about how data should be stored. I then tell it that in the future I'm going to add a calendar view and I want to ensure that the data model is compatible with this. And then the final thing here is to create a plan for the implementation starting with the data model and not write any code. So this is a technique I just call reflection. But basically what this is giving it all the information about what we want to build and then asking for a plan first before actually kicking off. You know, any type of coding here, and the reason why is it's twofold. So one is you'll get to see what is going to happen, which allows you an opportunity to modify it.

Right.

If there's something in here that you don't like, you can change it. And then two also you actually learn a little bit about what's happening. Like when we talk about building these products or building these prototypes, you having some familiarity, like a little bit of technical knowledge actually goes a long way in terms of your ability to navigate these systems.

Yeah, this is very smart. Like, most people just, like, actually start coding right away. But this is a really good strategy.

Yeah, yeah. So you can see we have our data model, right? So this describes that we have a habit. The habit's going to have a name when it was created. We also track habit completions. And then there's this little helper here with habit streaks. It tells us how it's going to organize the files. And just to reiterate, like, if we were in CLAUDE right now, this wouldn't exist because we can only have a single file, so there would be no kind of component structure at all. And then it also tells us a little bit about how it's planning on implementing this feature. Right. So we can go through all this, the key functions and so on. And so I'd recommend, like, especially if you're getting started with this, to actually read through this. Think about it. If you want to make a change, ask for a change at this point, rather than kicking off the actual development. But here we can just say, you know, go ahead and get started or please implement is usually what I write.

And is the data model for this app just like, locally, or is it, like, stored somewhere else?

Yeah, yeah. So right now this is just going to be local, so basically within the front end here. But the nice part about this is that later on, if we wanted to, we could connect a database and then basically mimic that same data model. It's easier to make modifications to the data model here than it is after we've connected the database. It's harder to make database modifications later.

Got it. And you should go ahead and ask through it. But, like, why did you decide? Why did you ask it to start the data model first?

Yeah, yeah. So the data model, this is where most of the problems that you're going to have come from. When we talk about issues with these tools. So we know that we need to store data on habits. And if we just kick it off and say, like, hey, build me a habit tracking app. And I'm not really explicit about what I want, it's going to store that data, let's say missing some data elements. So maybe it doesn't store the date.

Right.

It just stores, like, the habit name, whether we completed or not. And it's not storing the date or it's not storing the tracking of the completions. And so later on when we have an issue or when we want to add the calendar view, we don't have any calendar dates to display. We never set it up, we never stored those calendar dates. And so we have to go back and say, hey, actually now I want to add dates. And it's a little bit more challenging to change the data model later on than it is at the beginning. So, like, trying to nail the data model first is really good.

That makes sense. Yeah, it looks like it ran into a bug.

Yeah, this is actually perfect. So you're going to see this a lot. This is kind of the second part of navigating these systems is that you're going to have issues as we go along. And learning to read a little bit about these issues is helpful. You can also just ask it, like, I'll just demo that right here. So let's say I have no understanding what this issue is. I can just throw this in and say, please explain this to me. Yeah, and then again, don't write any code. And the don't write any code part is important because by default these systems are built to write code. And so if you ask a question, it might just go try to fix it for you.

Right.

Like it's not necessarily going to wait. And so saying don't write any code gives you that opportunity to read this. And so we can say there's a syntax error, incomplete function. So let's say, you know, please fix this and we'll see what it comes up with. And yeah, one other thing just while we're waiting here is. Well, I can continue. It is. This is part of the reason I actually like having a code editor that's visible to us because now I can actually go and look at the problem. So this is telling me that there's a problem in App TSX with something here. So let me see if I can find the issue quickly. Let's see. Unexpected token. So one of their. One of their strategy, by the way, I can't find the issue right away. It says that there's a missing closed bracket, but I actually don't see a missing closed bracket anywhere. So I'm going to say another strategy here, which is please determine the possible issues. And again, don't write any code. And I'll copy and paste that issue one more time here.

You're very nice to it. I just asked it to fix this shit.

Yeah, just have it, I guess. Oh, and there we go. So I actually don't know if there was an extra issue that it maybe just didn't load properly a second time there. I don't think it actually changed anything. And we would have seen, like, if there was actually.