A SaaS instructor takes a host's vibe-coded headshot prototype apart on camera, then rebuilds it inside a pen-tested template with auth, Stripe and a real database.
Posted
11 months ago
Duration
Format
Tutorial
educational
Views
15.7K
332 likes
57 · 43
Big Idea
The argument in one line.
A vibe-coded prototype becomes a real SaaS app only when you add a server, a database you migrate deliberately, auth on every endpoint and payments, and the fastest safe way to get there is to build inside an existing template.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You have a working prototype from Claude Code, Cursor, Lovable or Bolt and want to know what is missing before anyone can pay for it.
You build on Lovable or Bolt with Supabase and have never heard of RLS or checked who can read your user table.
You are a product manager or non-engineer who can prompt an AI coding tool but does not yet understand client, server and database.
You keep getting stuck on API versions, model names and deployment and want to see a real debugging loop instead of a polished demo.
SKIP IF…
You already run production apps with auth, migrations, Stripe and error tracking. The security section is a review, not news.
You want a line-by-line coding walkthrough. The build happens inside Claude Code plan mode and most of the 40 minutes is explanation while it runs.
TL;DR
The full version, fast.
A prototype is just a client, a pretty picture on the screen. A real SaaS app adds a server, a database, auth, payments, email, file storage, analytics and error logging, and that is where vibe-coded apps fall apart. The tutorial converts a Claude Code headshot generator into a full-stack app by dragging its React components into a prebuilt template, having Claude write an 80-line spec, and running plan mode before every change. It also exposes the biggest security hole in Lovable and Bolt apps: Supabase row-level security is wide open by default, so any user can read any table. The closing playbook has four steps: pick a template, build in VS Code with Claude Code or Codex, add your API keys, deploy through Render or Replit.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Montage of the episode's key lines, then the host introduces the guest and the plan: convert his vibe-coded Nano Banana headshot prototype into a real SaaS app.
01:44 – 08:57
02 · Client, server, database: what prototypes miss
Excalidraw diagram of client, server, database and third-party integrations. The seven SaaS extras: email, file storage, payments, auth, product analytics, error logging. Live code review finds base64 images and a hardcoded localhost URL. Tour of the guest's template with Stripe, Google auth, SendGrid, PostHog. Sponsor read.
08:57 – 16:45
03 · Live demo: porting the prototype into the template
Drag the prototype's React components into a new folder in the template. Claude generates a spec markdown, trimmed from 800 lines to 80. Plan mode reviews the plan: new headshots table, auth on every backend route, unit tests, a database migration. Kick it off.
16:45 – 20:30
04 · Why templates beat prompting from scratch
Claude copies existing patterns instead of inferring them. Then the Lovable and Bolt 'own cloud' announcements are unpacked as white-labeled Supabase, and the no-server architecture of those tools is drawn out.
20:30 – 25:35
05 · The Supabase security flaw in most vibe-coded apps
RLS rules are completely open by default on every Supabase project, so any user can read any table. This is the primary reason vibe-coded apps leak data. Hot take: Claude Code and Cursor are not harder to use than Lovable, which sells you on low complexity.
25:35 – 35:00
06 · Why AI should not touch your database directly
Claude pauses to ask permission before applying the migration, which is the correct pattern. The template was pen tested for a couple thousand dollars. First test fails on a stale Gemini model name; paste the docs, plan mode, retry. Headshot generates, new table appears in the database, PostHog analytics already running.
35:00 – 38:15
07 · Four steps to ship a real SaaS app
Use a template (free ones exist on GitHub and Vercel). Build in VS Code with Claude Code or Codex. Add your Stripe, auth and storage keys. Deploy via GitHub plus Render, or import the whole template into Replit. Course plug with engineering support.
38:15 – 39:17
08 · Why credentials no longer matter
Take the course to build something that makes money, not for a certificate. Skill and a revenue-producing side project beat credentials. Where to find the guest, his Built with AI podcast and the shared community.
Atomic Insights
Lines worth screenshotting.
A prototype is only a client. A real app is client plus server plus database, and the seven SaaS extras bolt onto the server.
Lovable and Bolt announcing their own backends changed nothing: both are white-labeled Supabase and the code still says Supabase.
Every Supabase project starts with row-level security rules completely open, so any signed-in user can read every other user's data until you change it.
The primary reason vibe-coded apps are insecure is that builders do not know RLS exists, not that Supabase is bad.
Supabase-backed tools auto-generate your server from your tables, which means you cannot modify the server when something goes wrong.
Every backend endpoint should check two things before doing anything: is this user logged in and are they allowed to do this.
AI coding tools that write SQL straight into your database are dangerous because you cannot undo a database change the way you undo a code edit.
Use migration files so the AI proposes a database change, you review it, and then you apply it.
Claude makes better architectural decisions inside a template because it copies existing patterns instead of inferring how a backend should work.
It is far easier to one-shot a feature on top of a working template than to one-shot an app from scratch.
A hardcoded localhost URL in the client is the kind of small AI mistake that makes a prototype fail the moment you deploy it.
Models work from stale training data, so paste the current API docs into the prompt before the AI picks a model name.
Run plan mode before every implementation so you can read what the AI intends to change before it changes it.
Ask the AI to write a spec markdown file from your prototype, then cut it from 800 lines to the 80 that matter and use that as your prompt.
Unit tests exist so you do not manually re-test the app every time the AI changes code.
Prompting Lovable to fix your email system is not a skill. Understanding how the email system works is.
A professional penetration test on a codebase costs a couple thousand dollars, worth it only when thousands of people will reuse that code.
Build a side project that earns revenue instead of collecting certificates. Skill and a material outcome beat credentials in tech.
Takeaway
Templates, migrations and auth make a prototype real.
WHAT TO LEARN
A prototype is only the client; everything that makes an app real lives on the server and in the database, and a template gives the AI working patterns to copy.
02Client, server, database: what prototypes miss
A prototype is just the client layer. A real app adds a server for logic like login and a database that persists data over time.
Budget for seven extras on top of the stack: email, file storage, payments, auth, product analytics, error logging, and never roll your own auth.
Small AI mistakes break deploys: base64 images stuffed into code and a hardcoded localhost URL both worked locally and would fail in production.
03Live demo: porting the prototype into the template
Move a prototype by dragging its components into the template, then ask the AI for a spec file of the requirements instead of rewriting them yourself.
Cut the generated spec to the essentials. An 800-line spec became 80 lines because only the requirements matter, not the restated code.
Run plan mode before every change so you can delete what you do not need, like credit tracking or file storage, before any code is written.
Every backend endpoint must check that the user is logged in and authorized. That check is the main line between a prototype and a real app.
04Why templates beat prompting from scratch
Inside a template the AI copies existing patterns for routes, tests and database access instead of guessing, so complex features become pattern-matching.
Lovable and Bolt's own backends are white-labeled Supabase. The branding changed, the architecture and the security model did not.
Supabase-backed tools auto-generate the server from your tables, which saves code but leaves you unable to modify the server when it misbehaves.
05The Supabase security flaw in most vibe-coded apps
Every Supabase project starts with row-level security fully open. Until you configure it, any user can read any other user's data, including emails.
The real cause of insecure vibe-coded apps is builders who do not know RLS exists, so learn how the stack works before trusting a prompt to fix it.
06Why AI should not touch your database directly
Never let an AI agent write SQL straight into your database. Have it generate a migration file, review it, then apply it yourself.
Database changes cannot be undone like code edits, which is exactly why you review migrations and avoid skipping permission prompts.
When a generated feature fails, read the error. A stale model name pointed straight at the fix: paste the current docs and rerun in plan mode.
Models have training cutoffs and will pick outdated APIs. Supply the current documentation up front to skip a debugging round entirely.
07Four steps to ship a real SaaS app
Start from a template. Free ones exist on GitHub and Vercel; search for your technology plus 'boilerplate' and pick one with auth and payments wired in.
Build in VS Code with Claude Code or Codex, add your Stripe, auth and storage keys to the env file, then deploy via GitHub plus Render or import into Replit.
08Why credentials no longer matter
Learn the skill and ship a side project that earns revenue. In tech, that outcome counts for more than any certificate.
Take a course to build something that makes money, not to collect credentials.
Glossary
Terms worth knowing.
Client, server, database
The three layers of a full-stack app. The client is what the user sees in the browser, the server runs application logic such as login checks, and the database stores data over time.
RLS (row-level security)
A Postgres and Supabase rule system that decides which rows of a table each user may read or write. Supabase projects start with these rules open, so every user can see every row until you configure them.
Migration
A versioned file that describes a change to the database schema. You review and apply it deliberately instead of letting code or an AI agent alter the live database directly.
Schema
The structure of a database: which tables exist and what columns each one holds. Adding a feature that stores new data usually means changing the schema.
Plan mode
A Claude Code setting where the agent writes out what it intends to change and waits for approval before editing any files.
Pen test (penetration test)
A paid security review in which a firm runs common attack patterns against your app, reports what it could exploit, and tells you what to fix.
Base64-encoded image
An image stored as a very long text string inside the code rather than as a referenced file. It works but is an odd choice for anything beyond a mock-up.
White label
Selling another company's product under your own brand. Lovable and Bolt's 'own clouds' are Supabase with their name on it.
PostHog
A product analytics tool that tracks user behavior such as daily active users and feature usage inside your app.
Sentry
An error-tracking service that captures crashes and exceptions from a live app so you can see what broke and where.
Render
A hosting service that watches a GitHub repository and automatically redeploys the app every time you push a commit.
“Most AI coding tools will just modify your database directly, which is terrifying.”
short, visceral, names the real risk→ TikTok hook↗ Tweet quote
26:17
“You can't undo a database change the same way you can undo a code change.”
clean principle that transfers to any stack→ newsletter pull-quote↗ Tweet quote
34:18
“It's much easier to one-shot something on top of an existing template than it is to one-shot something from scratch.”
the thesis of the whole episode in one line→ newsletter pull-quote↗ Tweet quote
37:58
“Build yourself a side project that makes some revenue. That's way cooler than having a certificate.”
motivational close with a point of view→ IG reel cold open↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogystory
Typically when we're talking about prototyping, especially with AI tools, we're usually talking about building things that are just on the client. The main difference between that and, you know, like a full stack application is usually the combination of adding in like a server and a database. You're going to have things like your email integration, file or blob storage as well, right?
Payment is pretty typical with Stripe. You have to have auth of some kind and product analytics of some kind, and then some type of log analytics. That's like a lot of stuff through Vibecode, man.
That's a lot. So if you tried to deploy this app, it wouldn't work. Do you have a request to the backend, right?
From your client side to generate the image to this endpoint that you made API transform, but it's sending it right to localhost 3001. So these are some good examples of like the types of things that AI can make mistakes on. What I built is a little template that has like what I think are the most common necessary features to build a SaaS project.
So basically let's recap the steps, okay, to build a real product.
Okay, welcome everyone. Today, my guest is... Colin Matthews, the one and only.
Colin's a good friend. He's taught a lot of students how to build stuff with AI and like build real shit, not just like random prototypes, like real stuff, real apps that you can actually get paying customers for. So that's what we're going to talk about today.
Like I vibe coded a pretty crappy nano banana image prototyper thing. And then me and Colin are going to convert that into a real SaaS app. Okay.
So welcome, Colin. Yeah. Happy to be back.
I think this is my third time now. Yeah, great. All right.
So why don't you start by talking about what the difference between a VibeCoder prototype and an app is? Sure. Yeah.
So I actually have a quick visual to help us out here. Let me share my screen really quick. So if you've heard me talk about software at all, you've probably seen me talk about this before.
I had client servers and databases. So typically when we're talking about prototyping, especially with AI tools, we're usually talking about building things that are just on the client. So like this is what you see in the UI, right?
So if I build something in like Bolt or Replit or Lovable, a lot of the time and the attention is actually spent on like getting it to look correct and making it like feel good and all that kind of stuff. The main difference between that and, you know, like a full stack application is usually the combination of adding in like a server and a database.
So something to handle like application logic, things like how users log in and that kind of stuff, as well as obviously storing data over time. And then the only other major thing that people like to add usually is like third -party integrations, right? So this would be things like, you know, your Gmail integration or something similar.
And usually that's talking to your server. So these are kind of the main components like prototype, really just a pretty picture, right? Just the client, full stack app, client server database, and then some third -party integrations typically.
But when it comes to like a SaaS app, there's usually is like a set of common features that most of these apps have, right? Yeah, exactly. So we can kind of pull some of those in here, but typically you're going to have things like your email integration, right?
So that's going to be like a third party. So you can send transactional emails. I might have like file or blob storage as well, right?
Payment is pretty typical with Stripe. You have to have auth of some kind and usually you don't want to roll your own auth, meaning like you don't build it yourself. You use preexisting auth tools.
And then kind of, I would say a bare minimum in terms of like the product and engineering side, you want to have product analytics of some kind. So understand using user behavior and then some type of log analytics. And this is specific to errors.
So like if you're familiar with the tool century, that's what I'm talking about, but like capturing errors in the product. Got it. Okay.
Yeah. That, that, that's like a lot of stuff through vibe code, man. That's a lot.
Yeah. Can you actually show the vibe quarter thing that I have? Sure.
Yeah. So right now we have like a, well, I guess you can explain it if you'd prefer. Yeah.
This is my. really amazing headshot pro ai app you can see it's very professional basically you can upload a headshot and then it will use google nano banana to generate a more professional looking headshot of yourself and hopefully it still works did you try it to make sure it works yeah yeah it works it works okay it still works okay yeah and how did you build this just curious oh that's good man yeah um perfect i how did i build this I use a clock code and just like vibe coded it.
And then I had to give it like a bunch of instructions to use Gemini's APIs and like a bunch of documentation. Yeah. I was able to get it to work.
There's actually a tutorial that I can link to if you want to vibe code this. Yes. Oh, perfect.
Yeah, yeah. I was just going to comment, like, you can perfectly see why I no longer have hair based on this image. The airline's pretty far back.
I think the AI got that right. But anyway, so, yeah, so this I would say is, like, closer -ish to a prototype in that, like, you don't have all those extra things. And then also, just for fun, we'll do, like, a quick review of your code.
So you do have a front end and a back end, right? So you have... You have a client and you have a server, which is already one step up because you don't necessarily need to have a server for this type of application if you're just running it locally.
But you have that working, which is great. And then there's just a couple of things, though. We'll just try to point out a few on the back end here in terms of how things are working.
So if we hop into your Gemini stuff, you can see here's your prompt and all that good stuff. Did you write this prompt manually or did AI generate this for you? I worked with AI to write the prompt, yeah.
Yeah, cool. And then it's sending the request over to Gemini and doing all this good stuff. And honestly, this is fine because this is just that kind of third -party integration stuff that we talked about a second ago, right?
Like sending a request over to Google, getting the results back, not a huge deal. In terms of the overall setup, so there are some things that are a little bit off. Let's see if I can find a good example here.
Let's go into this one here. So one good example is that your images are base64 encoded text. Like usually you reference a file, but it's just a super long text string that like the preview images that you have or like mock images.
So it's like kind of a weird AI -y thing. Not necessarily like super incorrect, but kind of like an odd thing to do in terms of a decision to make. And then another good one.
Let's see if I can find it in here. I think we have a local host somewhere. You actually have, I believe, the local host URL directly in the code somewhere.
Yeah. So, well, basically, yeah, right here. So what that means is like you have a request to the backend, right, from your client side to generate the image to this endpoint that you made API transform, but it's setting it right to localhost 3001.
So if you tried to deploy this app, it wouldn't work. You mean localhost doesn't work? Yeah, yeah, yeah.
So these are some good examples of like the types of things that AI, even when like you're building something that's a bit more complex. uh can make mistakes on right and like just some small small things that you you'd want to fix or change okay and then obviously the big thing would be adding like auth and stripe and all the other things we talked about right um yeah All right, so you have this template, right?
Where you actually added all this stuff. Can you show it to us? Yeah, for sure.
So what I built is a little template that has what I think are the most common necessary features to build a SaaS project. So the template itself is just a to -do list. The intent would be that you replace this page with whatever you're building.
But you can see that it has pricing, right? And we can go and upgrade to pro. That'll send us over to Stripe to actually complete the purchase.
It comes with our... obviously like login and stuff. Let me just hop back over here.
Login, so you can sign in and sign out. Right now it's using Google Auth for that. You can also set up with like GitHub Auth or really whatever you want.
And then also comes with an AI chat. And actually I'm in the process of swapping this over to the new agent kit from OpenAI. as the backend, so that'll be kind of fun.
And then also on the settings side, you can, you know, like toggle your email preferences and it comes with an integration with SendGrid. And then also like the other stuff, like I mentioned, so like PostHog for product analytics and for error capture and some other like small things behind the scenes. And sorry, did you mention there's a way to get paid?
Like a set payment? Oh yeah, for sure. Yeah.
So basically you just set up whatever you want and you just prompt like change this text. But yeah, you'd prompt or you just throw in your Stripe ID and then you can collect payment from Stripe. Okay.
All right, man. This episode is brought to you by Composio. Most of the pain shipping AI features doesn't come from the model, but from the integrations.
You're dealing with messy APIs, fragile tool calls and hours lost debugging and figuring out why something broke in Slack or Salesforce. Composio gives you one SDK to connect to 800 plus apps like Slack, GitHub, Gmail, Jira. And they built the rube .app that plugs all of those apps straight into an AI chat.
So you can just ask, pull me the latest metrics from Mixpanel and update linear. Now, instead of fighting with APIs, you can focus on actually shipping faster. Check it out at get rube .link slash Peter or the link in the video description.
Now back to the episode. Why don't you start a process of putting this thing? like putting my live quarter thing in here and then we can talk about some other topics while i was trying to program yeah that sounds good so basically we're going to try to convert your prototype to a full stack app right that's right um cool so i'm going to start by actually taking a look at your code here and i just want to quickly break down uh what your code is so people have a general sense of like how this works so you can actually see you have these two folders right so you have backend and front -end code back -end code this is your server -side code like we talked about right so this is really just the integration with gemini there's not much else going on here we'll probably copy your prompts so that we maintain the prompts the same way everything else i honestly will just have the ai regenerate this code because there's nothing like super useful it's just a call to the lm to gemini to generate the image okay and then the front end you can see in the front end you have different kind of like
elements in here. One of those elements is components. So you have like a style selector component, a result display, an image uploader, and a download button.
And then you kind of have like this main file called app .jsx that just imports all these components and kind of puts them in the page. Kind of like Legos, right? So like we have all these individual Legos and you're assembling those Legos in the page.
So what I can really easily do and what anyone can do is take the components that you built and bring those with us into the full stack app if we want to. So we can try to maintain like some of the visual styling of what you have in the prototype. Okay, I think it's up to you.
I'm not that proud of the visual styling, but yeah. Yeah, we'll try to keep it. Just for fun.
So, cool. Let's go ahead and start kind of moving this over. And literally what I'm going to do is I'm going to go like this on this side, like go like this on this side.
And you can see this is the template, by the way, the code I have over here. And you'll see a very similar kind of structure. So we have the client side code, we have server code, right?
Same as you client, like front end and back end. And then in the client, if we go into here, we'll see a folder called components, right? So this, this pattern will repeat itself all the time of like how your code is organized.
So I'm going to create a new folder here called Peter components. And I'm literally just going to drag over your files. And that's, that's all we need to do.
And you, by the way, you can do this also with like cloud -based tools. So like Replit allows you to drag in files and like right into the file system. And you can just bring in your components, maybe build the prototype and like.
v0 and you want to make it better in Replit, you can move stuff around in the same way. Okay, so what else? Yeah, I did also ask it to build us a little spec based on your stuff here, so let me just close this down a little bit and see what we have.
So I just asked it to generate a .md file for rebuilding your thing, just basically describing the requirements for it so I didn't have to rewrite it all. So this is currently a prototype application. We're going to rebuild it.
I'm going to get rid of some of the, or like modify some of this. Specifically, I'm going to say that the components are in Peter components because we just made that folder. And yeah, I'm going to kind of get rid of a lot of the backend service stuff that you have already.
Just because we can kind of clean up some of this ourselves. The rest of this looks fine. Oh yeah, and it automatically extracted your prompts, which is nice.
And yeah, I think that's pretty much it. So I'm going to, again, delete some of this.
Yeah, we'll get rid of a lot of this extra stuff. This is a lot of code and just stuff I don't really need. I just really need this top part here.
And this is going to become our prompt. So I'm going to basically take this, head over to our actual application and throw this into cloud. And I mean, I know you've done tutorials on cloud code, so I will probably won't spend a ridiculous amount of time on like explaining cloud code, but I am going to put it on plan mode first.
Just so that I make sure that the result that we get aligns to what we're expecting before we kick it off. Okay. That's awesome.
Okay. So just to recap, you drag and drop some component files into your template. Yep.
And in my original repository, you ask Cloud to generate an empty file. And the prompt is like, hey, if I want to rebuild this somewhere else, what do I need, right? Yeah, exactly.
Okay. And then it magically included prompts in the empty file. Yeah, yeah.
It just extracted all the, well, I would say all the important stuff and probably a lot of the non -important stuff. So you can see like I deleted, it was 800 lines because Claude likes to talk. I think I got it down to 80 lines.
It was just, I just needed the spec. I didn't need the, you know, the whole thing, all your existing code. Yeah, yeah.
Got it, got it. Okay, cool. So let's just do a quick read through.
And actually I think this will be really interesting to kind of like illustrate the difference between the prototype. right and what we actually have in a production application so the first thing it says is that we need to change the database schema right so this is how we're storing information inside the database and let me just see if i can run something really quick to make this feel a little bit more real give me one sec cool so this is like a database explorer that you can run locally on your computer if you're using the template or the same kind of technology or you know tools that i'm using and so when we talk about changing the schema what we're referring to is like right now in this database there is nowhere to store anything that is relevant to this these requirements right like we have uh items for the to -do list we have user information so like my email and my id we have file storage and that's it so the first thing claude is telling us that we have to do and this is a very common thing that you need to do is to change the database so we need a saying we need a headshots table we also need a credits table to track user credits um i'm probably gonna modify the plan a little bit because i don't actually care about tracking user credits so i'll say don't need
to track user credits, at least for now. And then let's see what else we got. We have the backend routes that need to be built and you're going to see a couple of good things here, right?
So we're going to require authentication. This is one like critical thing. Whenever you're building a full stack app, every backend endpoint should be checking, is the user logged in and are they allowed to perform this action?
Yeah. Right. So this is another kind of main difference between just a vibe coded prototype and building something real.
And then it looks like everything else is pretty similar, right? all that stuff there. I am going to say like we don't need to upload the image to Firebase storage, so don't store files in Firebase storage, just to keep things simpler for now for file storage.
Let's see what else here. And then front -end integration, it's going to build a page for the headshots. It's going to use your existing components that we already have, integrate authentication, all that good stuff, credit checks.
Payment integration, so we already have the payment plan. It's going to put three headshots per month for free. That's fine.
Gemini integration, the file storage integration to store the files over time. I'm going to skip this one just for the sake of time, but obviously we would want to store the images over time for the user. And then also really important unit tests.
So just in case people aren't familiar, typically you'd want to write unit tests against code so that you can automatically run these tests. And that way, when the AI makes changes, you can test if things are broken. So unit tests are a way to avoid manual testing all the time.
So it's going to write some unit tests for us as well. And then actually apply the database migration changes. But basically what this means is we will have new code, but we actually need to apply that code to the database to make the database have a different schema.
We can't just have the code be different than the real database. We need to apply that change. Got it.
Yeah. And yeah, that's pretty much it. So I'll go ahead and kick this off.
And I'll just say, give me back an updated plan.
Go from there. So you're going to do all these steps at once? Well, I mean, I'm going to try to like Claude do all these steps at once.
Yeah. Honestly, like this change seems kind of big, but it's really not. It's just a Gemini integration.
Yeah. One of the cool things, by the way, about having a template like this, you don't have to use my template just generally. is that Claude is making better decisions because of the existing patterns in the code base on how things work, right?
Like it's not inferring how the backend should be set up or inferring how tests should be set up. It's looking at examples of how things are set up already. And so it makes it a lot easier actually to do like changes like this, where it feels complicated, but it's actually just copying existing patterns.
Cool. Let me just give this a peruse. All right.
Well, I'm not going to read this whole thing. So hopefully this works. So I'm going to say yes.
And then it'll do its thing. And you're using a VS code, right? Just because it has like a native integration of call code.
Yeah, it's just a little bit nicer from like a UX perspective than the terminal, right? So like you get this nice little markdown editor and you can kind of scroll up and down with the text at the bottom there, like the input. So it's just a little bit cleaner.
Yeah, that is cleaner. Yeah. Okay, cool.
So it's going to work for a while now, right? Yes. As you can see, we have about a dozen to do to work through.
So this will probably take a minute. okay so let's go talk about some other things while this does its job so let's go back to your uh exact to draw thing yeah all right so let's talk about so we did a previous uh video on like our favorite ai coding tools right yeah but but now i think there's like a lot more out there and and like i think you prepare some diagrams about the difference between some of these prototyping vibe coding tools yeah exactly so I guess to start with like some pretty popular ones, Lovable and Bolt, a few others actually nowadays too, they're all using Supabase on the backend.
So even at this kind of fun for the folks who don't know is Lovable and Bolt just announced their own clouds, right? So like literally I think a week ago now or maybe two weeks, they're like, oh yeah, you can integrate directly with our own backend services. What really happened is Supabase released a feature that allows companies to white label Supabase inside their products.
And so it's still literally Subabase. And even if you look at the code, it literally references Subabase inside the code. So it's like a branding thing.
It's 100 % a branding thing. There's literally no difference in the features, functionality, or anything between the prior existence of Bolt integrating with Subabase or Lovable and what you have today. It is exactly the same.
Interesting. It's kind of funny because the people... that these companies are targeting.
I have no clue what the hell a cloud or a super base is. Sure. Yeah, yeah, yeah.
I agree. I think a lot of it is just competitiveness in terms of like, oh, this is the best tool because we have our own backend. Or this is the best tool because we have the best Figma integration.
But anyway, one of the things that's interesting about these tools, so specifically using super base as a backend, is that by default, they actually don't have a server. So we go back up to this pattern that we talked about so far. The way that they work is basically Supabase controls the server for you.
So there's kind of like this little thin layer at the back here where every table that you have in your database automatically gets a corresponding API endpoint, basically meaning they auto -generate the server for you, but you don't control that server. And so on one hand, that's really interesting and cool because that means that you don't have to write any of the server -side code.
On the other hand, one of the downsides about that is that you don't have the ability to modify the server -side code. It's auto -generated. Especially from a security perspective, this becomes a problem.
They have this system called RLS, which is basically a configuration system for who should be able to access what. Because the server would typically handle that in the normal stack that we have. It would decide, is the user allowed to perform this action?
But that doesn't exist in this context. And one really interesting thing is that by default, the RLS rules for every super -based project you set up are completely open. So any user can access any information.
And this is like the primary driver behind why you hear about like vibe -coded tools being insecure is because people are building on top of the system and they have no idea that RLS or any of this stuff even exists and that they've built on top of it. or how to modify it or improve it right like how to configure it correctly and so they're building these systems that like are not secure because you know it's not that super base is inherently bad it's just that like you don't know what's actually happening behind the scenes wait wait so so what is what what does rls stand for or is that like an acronym yeah um you know what i can't remember off the top of my head but it's something like a it's like rules and some type of rule -based access system um And then, and then if I go, like, is there some sort of set settings or a thing for me to change this stuff?
Yeah, exactly. So inside of these tools, if you prompt them to like, ask about your RLS rules, they will tell you what they are, but by default, it is completely open. And then you have to configure it to, to be correct.
So one like lovable did add a thing where like, wait, if you publish your application, they'll pop up a warning and say like, Hey, anyone can access the data in your product right now. Do you want to, do you want to change that? And then you basically try to prompt your way to these rules.
But again, you're reliant on the AI to configure it correctly, which is a little bit scary. That's kind of crazy. Okay, so if I build an app using these tools, and then let's say I have a user table with the user information, right?
Because people sign up and stuff. So you're saying that anyone can just get the email for all the users? Yeah, by default.
That's crazy, dude. so it requires the user to like the person authoring the project like you know the user of level or bolt to modify those rules and set them up correctly um but i guess my point here is that like the vast majority of people using these tools don't know those rules even exist right but why why why doesn't level one both fix the stuff they don't know which table is which or something it's more so that like this is just how super base works that like because they're trying to make it simple by not having you have a server You still have to have a server, though, in order to access the data in the database.
And so this is the simple version, which is you use a rule system instead of actually having code. But again, I think it's actually more complex or more difficult to understand for the average person. Whereas I think if you have this, it becomes a lot more clear if there's issues in the server, where those issues are.
Yeah, I mean, I don't think it's too difficult to set up a server, right? Especially if you have some very powerful model to do it for you. Yeah, no, no, it's not difficult at all.
And hosting is pretty straightforward and all that kind of stuff, right? You can host on like Vercel or Render, even Replit, like this is the stack Replit uses as well behind the scenes. So Replit, I would say it's like, that's one of the reasons I prefer Replit is because, not because of like the AI coding tools or anything like that, it's literally like what stack are they using and how likely is it that someone's going to make a mistake that they're going to really regret, right?
Wow, this is very, this is like news to me. I didn't know about any of this. Yeah.
Yeah. Yeah. It's pretty interesting.
I mean, like I built an app on lovable the other day and it did fine, but like, you know, I had to go through and configure the ROS rules to make sure that everything was correct. So, you know. Wow.
Okay. All right. Maybe we should email the lovable people.
Oh, they all know. They all know. Yeah.
If you, again, if you've read anything online about like five coding tools being insecure, this, this is the thing that is like the primary security of vulnerability. There's lots of other stuff that people make mistakes with. But this is the primary one.
Wow. Okay. Okay.
Okay. I have a hot, hot take. Like, I feel like even as a complete non -technical person, like I don't think like ClockCoder or Cursor or whatever is like more advanced tools are actually that hard to use.
Like you're literally just like typing to chat, right? Yep. I mean, I don't actually think they're actually much more hard to use than some of these like web -based tools.
Yeah, I would agree for sure. I think, again, like... Part of the job of a level or something like that is to convince you that the complexity is low so you feel like you can do it.
But again, if we go back to the image up above, at some point in time, you will need to add payment. And they have a Stripe integration, but you still need to go into Stripe and set it all up. You'll have to add email.
And if you don't understand how these systems work, I think at the end of the day, when you have a bug with your email system and the only thing you can do is prompt level to say, fix my email system, that's the challenging part. um not to try to dissuade anyone from doing this type of work because obviously i think everyone should try and learn but at the same time i think it's important to to not treat it as like i want to get to the outcome as fast as possible and i don't care at all about how anything is working and more so to say like okay like how does this actually work behind the scenes and try to learn some of that stuff got it okay cool do you want to check the vs code see if the things are generated Yeah.
So let's see, we want to generate and apply database migration. So this is actually interesting. We kind of got stuck here.
I must have asked for permission a little bit while ago, but it's asking us to apply a change to the database. This is another really good thing in terms of a pattern, because typically what happens is most AI coding tools will just modify your database directly, which is terrifying. What this is doing is it's generating a file to basically tell us what it's going to change.
And then we apply that change and it makes it easy to make sure that our databases are always kind of like in sync and up to date. So this is something called migration. And again, this is like a pattern that you'd want to learn and consistently do rather than just allowing like an AI agent to write SQL queries against your database and just change anything at any point in time.
That's a little bit terrifying. And again, that's the default pattern. Yeah, because if you script a UI, you can change it back pretty easy.
But if you script a database, it's harder, right? Yeah, yeah. And even like with undoes, I know a lot of people are reliant on like trying stuff and undoing it.
You can't undo a database change the same way you can undo a code change. So generally speaking, you want to be a little bit more certain that things are going to work. Yeah.
So you don't dangerously skip permissions? No. No, no, I don't.
Cool. So it's going to run through this. I'm going to probably have to pay attention for a second as it installs some stuff.
Okay. And you have a database. The reason it's doing this is because you already set up a database with your template that has some basic tables.
Yeah, exactly. Yeah. So we have a database that has like the user storage information that has the Stripe integration.
So it stores like all the Stripe IDs and stuff like that. So again, like the template is there. It's not, I'm not going to claim that it's like a prerequisite, obviously, like you don't need it.
But the purpose of it is to like help people avoid common mistakes, especially on the security front. And maybe this is interesting while we're waiting. I actually had the pen test or I had the template pen tested by a security firm before, you know, I gave it to anyone just for fun.
What is a pen test? Oh, sure. Yeah, great question.
So basically, it is like a security review where they attempt to extract information from your website or from your app. And there's like a bunch of very common attack patterns that attackers use. And so they run through all those attack patterns against your application and see basically what they can exploit.
And then at the end, they kind of give you a report on what you need to update or modify in order to be secure. Is that like a lot of money to do a pen test? Oh, it's like a couple thousand dollars.
okay okay wow okay so you gotta be serious yeah yeah yeah for me like if i'm gonna give the code to people then you know like it's my template multiplied by a thousand or two thousand or five thousand times yeah it's worth it to spend a couple thousand dollars to make sure that i'm giving people secure code um for the average person probably a little bit out of reach got it okay All right, we are back and here's what we have.
So what it did is actually added it to the nav bar, right? It didn't necessarily replace what we had. That's okay.
We could, you know, ask it to take some stuff out later. But theoretically, so let's just take a look quickly at the UI and then we'll try to see if it actually works. So in pricing, it did not update our pricing page, it looks like.
So no, no headshots. I don't see anything here. That's okay.
And then in the headshots here that we do have like a counter for the number used this month. And let's give it a try. One thing you'll notice is like it's using your components, right?
So that part worked. So click choose image. We'll grab our picture here.
We have this guy here, generate headshot. And we'll see if it works. Cool.
Okay. So new error. Failed to generate, not supported.
So this is likely an error because we didn't pass in the right documentation. And again, this is where like some debugging is obviously helpful. So if we just take a look at this, we can see it says.
Gemini 2 .0 flash XP image preview. So this is likely the same issue that you had before, Peter, which is like, it's not using the right model, right? And so we're just going to go ahead and, yeah, this is actually a really common pain point of LLMs is like, they don't have up -to -date information, right?
Like the training cutoff. And so they don't know how everything works. So we're gonna have to go find the Gemini nano banana docs.
Let's see. This one here and we're gonna want to pass in the relevant documentation and just ask it to update it So we're doing image to image editing and I'm just basically gonna copy the docs here paste this in and Say you're using the wrong model And again, I'm gonna turn on plan mode because honestly I pretty much never I don't know if you do but I never kick it off Without doing plan mode first.
I always alternate between planning and implementation. Yeah, I just don't like the idea of like letting it do a bunch of stuff on its own.
I have no idea what it's doing. Okay. Um, but that's the rest of the, the, those, the SAS stuff work like, like the auth and everything.
It should be the same, right? Yep. Yeah, it still works.
So we can, we can hop back into that for a second. Um, so let's go to here so we can sign out, we can sign in, we can hop into our pricing page in a second here. We can open up, we can upgrade to pro.
I want to actually obviously upgrade, but we have our pricing set up here. If we wanted to change this, this would be just like a setting in Stripe that we change. We don't actually change the code anywhere.
And yes. Okay. But to make this payment thing work for my stuff, I have to enter my own Stripe information?
Exactly. So you would have to enter in your own Stripe keys. And that's just part of the ENV file, like similar to the API key that we have for Google.
You just put in your own environment variables, basically. Okay. Got it.
Yeah. Cool. All right.
So. it's gonna clean up our server basically wrong package wrong model all this stuff so yeah we could have probably avoided this issue if we had um given it the docs up front but that's okay we'll clean up pretty quick i don't know man it took me like a good 20 minutes to get this thing to work so maybe we have better luck Yeah, I've also done this one before.
Kind of like the headshot thing. And usually it just makes this mistake of like not using the correct up -to -date information. I actually partially did this on purpose because I think it's useful for people to see like the loop of like we tried something, it broke, we read why it broke, right?
It actually gave us like a very useful error message if you just read it. Immediately figured out what the problem is, grabbed the relevant information to fix it, pasted it in and then did it again. Yeah, it's all this like installing stuff or like picking the right version that that's like a pain in the ass with these by -point tools.
Yeah, for sure. As an aside, by the way, like some people might be watching this and thinking like, oh, wow, this is a lot more difficult than lovable or bold or something similar. And so that I would say like, generally, I agree.
It's more challenging. But I also think that like, one is you're learning how things actually work, which is good. And then two is like, I do think those tools have kind of a bar.
That is, let's say, lower. So you can't get as far as you can with some of these more power tools. I mean, you're going to run into the same API issue using Lovable and Bolt, right?
Because they have the same model behind it. Yeah, exactly. Yeah, yeah, yeah.
I do like Cloud Code better than the Lovable agent and the Bolt agent, but yeah. Bolt has recently switched to... I think Bolt, now you can use Cloud and Codex agents.
Yeah, inside a bullet. Yeah, that's a pretty cool decision generally to try to go down that path. Yeah.
But yeah, let's see what we got here. There we go. Nice.
We have our headshot. So theoretically, we now have, I mean, we probably want to delete some stuff in the template, right? Like the AI chat and some other stuff.
But we now have our professional headshot editor. We have to do some basic prompting to put in our own logo and stuff. Maybe rearrange the pages a little bit.
But yeah, we used one out of five this month. Oh, you're going to use my best template, dude. You're not using my best template.
Do you want me to restart that whole thing? No, yeah. Can you just upload a picture again?
Sure. Let's give it a try. You got to use the third one.
The one on the right. Executive portrait. Okay.
All right. All right. There you go.
But yeah, so we also store your past headshots in the database. And we'll take a look at the database in a second. Here's our executive one.
There you go. That looks good. Yeah.
Yeah. So yeah, let's take a look at the database and let's just refresh here and we'll see what tables we have, right? So we have headshots now.
We have a new table and it's storing the user ID and the style and anything else. Maybe that is it.
Wait, wait. Okay, I got that. That is it.
Okay, got it. Yeah, I think that was the only change that I made to the database, just storing their past history of like using the tool. And if we head back over, we can see that down below.
That's basically how this is showing up, right? Our past headshots. As I mentioned, I'm not storing the images right now.
I just wanted to do that to save a little bit of time. But ideally, we'd be storing the files for the images as well. But how did I know to just start storing this stuff?
It was part of your... Yeah, so part of the template includes all this database access patterns that are already in the code. And so generally speaking, when you put in a prompt, it's going to follow the code that's already there.
Okay. And so it just sets it up following all the existing patterns and everything works. So that's why it's much easier to one -shot something on top of an existing template than it is to one -shot something from scratch.
Yeah. Because all this stuff already works. And one other thing, just for fun, and we might be running short on time, but let me pull this up here.
I also have product analytics hooked up to this already. So we can see our number of daily active users and how many times they're visiting and all this good stuff already inside of the template as well. You can kind of, as I said, you know, add in all these third -party integrations and all that kind of good stuff to make this more like a real product and less like, you know, a vibe -coded thing.
So basically, let's recap the steps, okay, to build a real product. Sure. So first of all, we got to use your magical template, right?
I would say it's a good idea to use a template and there's more than mine available on the internet. So, you know, find one that you like, but yeah, template's a good idea. Okay.
We'll put a link to your template or your course below this, but I think there's also like free templates, right? This is not just purely to sell your course. There's free SaaS templates, right?
Yeah, exactly. Yeah. I mean, if you want to use mine, obviously that's an option.
It comes included with the course, but there's free ones you can use as well. And just like search on GitHub or something? Yeah.
I mean, Vercel has some really good ones. But if you generally, if you speak, look, Google, like the technology. So it's going to be like, you know, Next .js boilerplate template or Node React template.
And it'll come with all this stuff. Okay. Got it.
Okay. So number one is to use the template. Number two is to like start building in a template with like, you know, uh, some, some, some, uh, a cursor or VS code or something.
Right. And, and, and, and your preferred combination right now is VS code plus codex. Yes.
Yeah. Yeah. Yeah.
I know we demoed cloud code here and it worked pretty well, but I'm using codex more for, especially for larger code bases. I find it works better. Um, but either, either is fine.
I think cloud code or codex. Okay. And then number three is to, uh just to add a bunch of api keys right for for like um well i mean i guess it depends on what you're trying to do but like yeah so you need your key for like stripe uh for payment i assume you want that one uh you need your auth stuff for like your google login right um you probably want file storage if you're doing anything with files so like yeah there's a couple of keys you need to kind of add in uh for those things got it and then how do you put this whole thing on the interwebs?
Ah, yeah, good question. So typically I use a service called Render for deployments. So what we would do is we basically sync this code to GitHub, we'd commit it back to GitHub, and then Render would automatically deploy it whenever we make an update in GitHub.
So that's one option. Another option is if that feels too sophisticated, you can also use this template inside of Replit. That's what a lot of students are doing currently in my cohort.
So they're not even doing any local setup. They're just importing the template into Replit. Replit gives them the database.
Replit gives them the server. They click a button to publish. So they kind of get the best of both worlds.
They first import a template into Replit or they import the whole app into Replit? Yeah, like the whole template that we kind of went through and modified, they import that whole thing into Replit. Okay, okay, got it, got it, got it, okay.
Awesome, dude. All right, it looks like I have to take your course again. Yeah.
Just to plug in, just, you know, it's my job, is the course also comes with like dedicated engineering support. So I know that's like a challenge that a lot of people have. And I really tried my best to like get rid of all of the barriers.
So as I mentioned, like the template is pen tested for security. You have engineering support, you get a template. So like, you don't have to figure out the Stripe integration yourself.
And then obviously there's, it's an eight week course. So you have like plenty of support and other students and all that good stuff. So, yeah.
Awesome, dude. And let me, let me just close on this, man. Like if you're taking Collins courses, like you should really like.
The point of taking the course is to actually build something and hopefully like make some money, you know, from your software tool, right? Right. It's like, you know, don't just take this course to get credentials, you know?
Yeah. So just keep that in mind. Yeah, yeah.
Maybe this is a bad thing for me to say, but like I'm actually not a huge fan of credentials, especially in product or in tech. Like as a mechanism of advancing your career, I think the experience is what makes you better, right? Like the skill.
So that's the main thing is like learn the skill and then like get a material outcome, like build yourself a side project that makes some revenue. That's way cooler than like having a certificate. So that's my opinion anyway.
But when do you see my SaaS app to generate certificates, dude? Yeah, there you go. No, I'm just kidding.
Cool. All right, man. Well, thanks for coming again.
This is a great, great chat. And yeah, if you want to find Colin, you can follow him on LinkedIn, right? Yep.
Is there anywhere else to follow you? Substack. Yeah, actually I have my own podcast.
If you want to see people building SaaS apps, I interview them now, mostly PMs. So it's called Built with AI on YouTube right now. And I have to get the Spotify thing up, but you can check that out if you're interested.
And we also have a community together, right? Oh, yeah, we do. For sure.
Yeah, there's that one too. I think we're almost 700 people strong now, which is pretty cool. Yeah.
So sign up for our newsletters if you want to join our community. Cool. All right.
Yeah, I think that's it. Thanks so much, Colin. All right.
Yeah, no worries.
The Hook
The bait, then the rug-pull.
The cold open stacks the whole episode into 27 seconds: a list of seven things every SaaS app needs, a hardcoded localhost URL that would kill the host's prototype on deploy, and a template that promises to fix both. Then the host admits his headshot generator is a crappy vibe-coded prototype and hands it to the guest to make real.
A three-tier ladder for judging how real an app is. Most vibe-coded output stops at the first rung.
Steal forscoping any app build or explaining to a client what 'done' means
03:00list
The seven SaaS components
Email (transactional, e.g. SendGrid)
File or blob storage
Payments (Stripe)
Auth (never roll your own)
Product analytics (PostHog)
Error logging (Sentry)
Server plus database underneath
The common feature set nearly every paid web app shares. Each one is a third-party integration hanging off the server.
Steal fora launch checklist for any paid app
10:45concept
Spec-then-plan porting workflow
Drag existing components into the template
Ask Claude to write a spec .md of the prototype's requirements
Cut the spec to the essentials
Paste it into Claude Code in plan mode
Review and edit the plan
Approve and let it run
How to move a prototype into a production codebase without rewriting it by hand.
Steal formigrating any throwaway build into a real repo
35:00list
Four steps to ship a real SaaS app
Use a template
Build in VS Code with Claude Code or Codex
Add your API keys (Stripe, auth, storage)
Deploy via GitHub + Render, or import into Replit
The closing recap of the whole episode, stated by the host and confirmed by the guest.
Steal fora getting-started page or onboarding checklist
CTA Breakdown
How they asked for the click.
VERBAL ASK
37:03product
“The course also comes with dedicated engineering support. The template is pen tested for security. You have engineering support, you get a template, so you don't have to figure out the Stripe integration yourself.”
Low-pressure. The host explicitly says free templates exist and this is not purely to sell the course, then the guest pitches the course on support and the pen-tested template rather than on outcomes. The real close is the credentials-don't-matter note, which reframes the course as a means to revenue.
Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.
Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
Replit's head of product engineering walks through three non-coder founders who built real six-figure businesses, then live-demos the four steps that turn a raw prototype into one.
Anthropic's Thariq Shihipar walks Peter Yang through /goal, sub-agent workflows, and a planning habit built entirely around finding out what you don't know before you build.
A 19-minute live build showing how to make Claude Code skills that grade their own output, remember past sessions, and get better every time you run them.
00:39
01:33
02:12
02:42
03:26
04:10
04:39
05:09
05:38
06:07
06:37
06:57
07:36
08:12
08:37
09:03
09:34
10:33
11:02
11:32
12:01
12:22
13:00
13:30
13:59
14:29
14:58
15:57
16:26
16:56
17:25
17:54
18:54
19:23
19:53
20:22
20:52
21:21
21:53
22:07
23:19
23:48
24:06
24:35
25:19
25:46
26:16
26:45
27:12
27:38
28:00
28:31
29:34
30:07
30:48
31:10
31:40
32:19
32:39
33:07
33:24
34:37
34:56
35:24
35:56
36:37
37:09
37:20
37:51
38:59
36:06
41:17
13:23
19:18
Video of the Day31:33
41:48