# Lovable From a prompt to a running app with a database, and where you take over. Multimedia & Creative Technology · 3.1 Extra Webdev · Self-study · version 0.1.0 · 2026-10-14 Tags: ai, security, database, github Slides: ## After this lesson you can - Explain what Lovable builds for you, and which stack you get whether you want it or not - Write a prompt that makes Lovable ask questions first, and read a plan before you approve it - Explain why RLS is the only lock on the data of a Lovable app, and check the policies yourself - Get the code onto your laptop through Git sync, change it, and push it back - Decide per project whether Lovable saves you time or costs you later > **Explanation:** The two assignments in this deck build on each other: first you plan and build a small app of your own in Lovable, then you take the code to your laptop and change it with your own coding agent. Keep a Lovable tab open while you read, and look up every screen yourself. The menus move faster than any deck can keep up with. ## Agenda 1. What Lovable is 2. From prompt to plan 3. The backend 4. Security 5. Getting your code out 6. When to use it > **Explanation:** Chapters 1 and 2 show what Lovable is and how you get from a prompt to a working app. Chapters 3 and 4 are about the database and what went wrong with Lovable apps in the past: read those carefully if you ever put an app in front of real users. Chapter 5 is for developers who want the code, chapter 6 helps you choose. ## 1. What Lovable is > **Explanation:** You have probably seen a Lovable app already without knowing it: a lot of startup landing pages carry an 'Edit with Lovable' badge in the corner. Clients and colleagues will ask you about it, and some of them will hand you a Lovable project to finish. Knowing what is under the hood tells you what you are getting into. **A coding agent in the browser, with hosting and a database attached.** It reads and writes files, runs builds and migrations, and fixes its own errors. You never open a terminal, and the app is live on a url within minutes. > **Explanation:** Same loop as in Working with AI: a model, tools, a harness. The difference is everything around it. You never see a terminal, the agent runs in their cloud, and the preview is right next to the chat. That is what makes it work for people who cannot code, and it is also what hides the mistakes from them. Building by prompting and judging the preview, without reading the code, is what people call vibe coding. ### What Lovable is | | | | --- | --- | | **From** | Stockholm, founded in 2023 by Anton Osika and Fabian Hedin, as Lovable since November 2024 | | **Scale** | More than 60 million projects created, according to Lovable. Valued at $13.3 billion in August 2026. | | **Frontend** | React and TypeScript on TanStack Start with server rendering, styled with Tailwind | | **Backend** | Lovable Cloud: Postgres, auth, storage and edge functions, on Supabase | | **Hosting** | Cloudflare Workers, on `yourapp.lovable.app` or your own domain | The framework is fixed. Whatever you ask for, you get a React app with Postgres behind it. Check the [FAQ](https://docs.lovable.dev/introduction/faq) before you promise a client anything else. > **Explanation:** Lovable started as GPT Engineer, an open-source project by Anton Osika. The numbers come from Lovable itself, so read them as marketing, but even half of it is a lot. The stack changed in May 2026: new projects are TanStack Start with server rendering, on Cloudflare Workers. Older projects you run into are often still a plain React app built with Vite. You cannot pick another framework: no Vue, no Laravel, no Astro. ### Lovable or a coding agent #### Lovable - It runs in their cloud, with the preview right next to the chat - You always get the same stack: React, TypeScript and Postgres - Database, logins and hosting are set up for you - You can build a whole app without ever reading the code, which is the risk #### Claude Code, Codex, Cursor - It runs on your laptop, in a project you already have - Any stack works: Laravel, Astro, Python, whatever the client uses - You set up the database, the server and the deploy yourself - You read every diff before it goes into a commit > **Explanation:** Keep this comparison in mind for the rest of the deck. Lovable is not a different kind of AI, it is a different trade-off. You give up control over the stack and the environment, you get speed and hosting. The questions you ask about a coding agent (what is in the context, who reviews the diff, what may it touch) all still apply. Lovable just makes it easier to never ask them. ## 2. From prompt to plan > **Explanation:** The next slides follow one real build from start to finish: the prompt, the questions Lovable asked, the plan and the result. When you build your own app, expect different questions: the model changes, and so does the product. The way of working stays the same. ### Three modes ![The mode menu in Lovable with Build, Chat (free) and Plan](https://slides.mctantwerp.be/decks/en/extra-webdev/11-lovable/modes-menu.png) | Mode | What it does | | --- | --- | | **Chat** | Talks about your app, changes nothing. Free. | | **Plan** | Asks questions, writes `.lovable/plan.md`, waits for your approval | | **Build** | Changes the code, the database and the preview. Costs credits. | More in the docs on [Plan mode](https://docs.lovable.dev/features/plan-mode). > **Explanation:** Chat mode is free, so use it for anything that is a question: is this a good idea, why does this look weird, what would you change. Plan mode costs about one credit per message. Build mode is where the credits go. On a Mac, Option+P cycles through the three. Plan mode is the one beginners skip and experienced users never skip: it is the same 'plan before you build' from Working with AI. ### A prompt to start from ![A prompt for a foosball booking app in the Lovable chat box, in Plan mode](https://slides.mctantwerp.be/decks/en/extra-webdev/11-lovable/prompt.png) Who it is for, the one main action and the rules that matter, in Plan mode. The last sentence asks for questions before the plan, so Lovable does not fill the gaps with guesses. > **Explanation:** The prompt says who the app is for, what the one main action is, and the rules that matter: 20 minute slots, one per day, only your own bookings. It does not list pages or features: Lovable is better at that than you think. The last sentence matters most. Without it, Lovable fills every gap itself, and you only find out which guesses it made when you click around in the preview. ### Questions first ![Lovable asks how far ahead students can book, with three options and a field to write your own](https://slides.mctantwerp.be/decks/en/extra-webdev/11-lovable/questions.png) Four questions before any plan: the email domain, magic link or password, how far ahead you can book, and the look. Each one is a choice it would otherwise have made for you, silently. When none of the options fits, write your own answer. > **Explanation:** Lovable asked four questions here: which email domain, how to sign in, how far ahead you can book, and which look. Every question is a guess it did not have to make. Notice that it offers options: that is fast, but the options are its idea of what is normal. Use the 'write your own' field whenever none of them fits, and skip nothing just to get to the build faster. ### The plan ![The plan Lovable wrote for the foosball app: what students get, sign in, the board, booking and limits](https://slides.mctantwerp.be/decks/en/extra-webdev/11-lovable/plan.png) - A magic link, and a trigger that refuses any email outside @student.kdg.be - Unique on day and slot, and on student and day, so nobody books twice - RLS so you insert and delete only your own bookings - The public board reads first names only, never email addresses > **Explanation:** Read Technical details first: it is the part people who cannot code skip, and it is where the database design lives. This one is better than most first attempts by hand. You can select any part of the plan and ask for a change before you approve. A plan you approve without reading is the same as no plan. ### What it built ![The Lovable editor with the chat on the left and the Kicker Lounge booking board in the preview](https://slides.mctantwerp.be/decks/en/extra-webdev/11-lovable/editor.png) - It checked that a Gmail address is refused - It could not test signing in and booking: no student account yet - The summary is your to do list. Test what it did not. > **Explanation:** This came back after one approval, a few minutes later. Read its summary: it tested that a Gmail address gets refused, and it says itself that it could not test booking, because no student account exists yet. That honesty is useful, and it is also your to do list. It named the app Kicker Lounge on its own and asks whether that is fine. The bar at the bottom of the preview lets you select an element and prompt about it, or edit a text directly. ### Prompting that works - Say who it is for and what the one main action is, before any features - Use Plan mode for anything bigger than a button. Answer the questions, then approve. - Name the design in concrete words: "thick black borders, one orange accent", not "modern" - One change per prompt, and say what must stay untouched: "only the booking page" - Give it real content instead of lorem ipsum, it designs around the text it gets - Bookmark a version that works before a risky change [The prompting guide in the Lovable docs](https://docs.lovable.dev/prompting/prompting-one) > **Explanation:** These come from the prompting guide in the Lovable docs, and they match what Working with AI says about coding agents. Bookmark a version before every risky change: a revert is free, but the credits you spent are gone either way. Real content instead of lorem ipsum matters more than you think: a model designs around the text it gets. ### Knowledge *Project knowledge* ```md Booking app for the foosball table, KdG student lounge. Users are students, mostly on their phone. - Times are always Europe/Brussels - Show first names only, never an email address - Every new table gets RLS, insert and delete only on your own rows - Ask before adding a new package ``` Instructions Lovable adds to every message of the project, up to 10,000 characters. Put in the rules it would otherwise forget. It also reads an `AGENTS.md` in the root of the repo. See [Knowledge](https://docs.lovable.dev/features/knowledge) in the docs. > **Explanation:** Knowledge is sent with every message, so keep it short and only put in what Lovable gets wrong without it. Workspace knowledge applies to every project in the workspace, project knowledge to one. A long conversation can drift away from it, the docs say so themselves. Lovable also reads an AGENTS.md or CLAUDE.md in the root of the repo, which is handy once you sync with GitHub: the same file then briefs Lovable and your own agent. ### When it breaks #### Don't - Press "Try to fix" until it works. Every attempt stacks code on the last one. - Keep going in Build mode while you do not know what is wrong - Count on a revert to undo your data. It restores code, not rows. #### Do - One or two tries, then ask "What is the root cause?" in Plan mode - Revert to the last version that worked, and send a better prompt - Paste the error, a screenshot and what you expected. See [debugging](https://docs.lovable.dev/prompting/prompting-debugging). > **Explanation:** Try to fix is free, ten times, and each one comes back 24 hours after you used it. The trap is pressing it five times: every attempt piles code on top of the previous one, and the real problem gets buried. The docs themselves say to stop after one or two tries. A revert restores code and edge functions, not the rows in your database. ### Task: Plan your own app In your own free Lovable account. Stuck? The slides Prompting that works and When it breaks have the links to the docs. 1. Pick something small with one main action and a few rules 2. Switch Plan mode on. Describe the app in four sentences and ask for questions first. 3. Answer the questions. Write your own answer where its options are wrong. 4. Read Technical details in the plan: which tables, which RLS 5. Approve and let it build 6. Done when the preview works and you can explain every table in the plan > **Explanation:** Start small: an app with one main action and a few rules. The most common mistake is a prompt that lists ten features and no main action. The second most common is approving the plan without reading Technical details. Out of credits? Chat mode is free, so plan the next step there and build tomorrow. No idea what to build? A lending list for the camera gear of your programme, a sign-up page for a student event, a shared shopping list for your kot. ## 3. The backend > **Explanation:** Lovable Cloud is what turns a nice prototype into an app with users and data. It is also where most of the incidents with Lovable apps happened. So first how it works, then what went wrong. ### Lovable Cloud ![The Cloud overview of the demo project: the tables bookings and profiles, users, storage and secrets](https://slides.mctantwerp.be/decks/en/extra-webdev/11-lovable/cloud.png) - Postgres, with migrations, constraints, triggers and RLS - Logins with a password or a magic link - Edge functions for what the browser may not do - Storage for files, Secrets for API keys See [Lovable Cloud](https://docs.lovable.dev/features/cloud) in the docs. > **Explanation:** Lovable Cloud is Supabase underneath, run by Lovable. You can also connect a Supabase project of your own instead. There is no migration from Supabase to Cloud, and removing Cloud from a project deletes the data, permanently. The screenshot is the demo project right after the build: two tables, no users yet. Lovable AI lives next to it: models your app can call without a key of its own, billed in credits. ### RLS decides 1. Browser → Supabase API, **GET /rest/v1/bookings**: The request carries the publishable key. It sits in the .env of the project and in the JavaScript of the app, anyone can copy it from the browser. 2. Supabase API → Postgres, **select \* from bookings**: The API passes the query on with the role of the visitor: anon, or the logged in user. 3. Postgres, **RLS policies**: Postgres checks every row against the policies. RLS switched off on a table: every row goes back. 4. Postgres → Browser, **The rows it may see**: No server of yours in between. What RLS lets through is what the visitor gets, also when they call the API by hand. > **Explanation:** In a Laravel app the browser talks to your server, and your server decides what the user may see. In a Supabase app the browser talks to the database directly, through the Supabase API, with a key that is in the JavaScript of every visitor. In the demo project it is in .env as VITE_SUPABASE_PUBLISHABLE_KEY, and that is fine: it is meant to be public. Supabase called it the anon key until 2025, and most articles still do. RLS is not an extra layer of security, it is the only one. ### The policies it wrote *drizzle/migrations/0000_migration.sql, shortened* ```sql ALTER TABLE public.bookings ENABLE ROW LEVEL SECURITY; CREATE POLICY "own bookings read" ON public.bookings FOR SELECT TO authenticated USING (auth.uid() = user_id); CREATE POLICY "own bookings insert" ON public.bookings FOR INSERT TO authenticated WITH CHECK (auth.uid() = user_id); CREATE POLICY "own bookings delete" ON public.bookings FOR DELETE TO authenticated USING (auth.uid() = user_id); CREATE FUNCTION public.get_board(p_date date) ... SECURITY DEFINER ``` Each policy only lets a logged in user touch rows where `user_id` is their own id. `USING (true)` would be a policy too, and let everyone through. See [Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security). > **Explanation:** This is the real migration Lovable wrote for the demo, shortened. You read, book and cancel only your own rows. There is no policy that lets a visitor read bookings, so the public board goes through get_board, a function that runs with the rights of its owner (security definer) and only returns the time, a first name and whether it is yours. That is what the plan promised, and it held. In your own app, check exactly that: does the migration do what the plan said? ## 4. Security > **Explanation:** Lovable apps have a reputation, and part of it is earned. Most incidents were not bugs in Lovable itself but apps that nobody checked. One was Lovable's own API. Both kinds matter as soon as you build something for a client: their users' data is on the line, and your name is on the project. ### CVE-2025-48757 In 2025 Matt Palmer scanned 1,645 apps built with Lovable. 170 of them, about one in ten, let anyone with the public anon key (now called the publishable key) read or write data in 303 endpoints: emails, phone numbers, payment details, API keys. > [!WARNING] > The cause was RLS: missing, or a policy that let everything through. Nobody broke in. They asked the API, and the database answered. Read the [statement by Matt Palmer](https://mattpalmer.io/posts/statement-on-CVE-2025-48757/). > **Explanation:** Matt Palmer found it in March 2025 and reported it the next day. Lovable shipped a security scan in April, the CVE was published in May. His criticism of that first scan: it checked whether a policy exists, not whether it is any good. Whether you call this a Lovable bug or a mistake by the people who built the apps is up for debate. The data of the users leaked either way. ### Not only your own app | When | What | Whose mistake | | --- | --- | --- | | 2025 | One in ten scanned apps without working RLS | The apps, on a platform that made it easy | | April 2025 | Lovable builds working phishing pages with the least pushback in a test by Guardio | Lovable | | April 2026 | A free account could read chats and source code of older public projects through the Lovable API, 48 days after the report | Lovable | A key you hardcode in a project is as safe as the platform that stores it. Put keys in Secrets, never in the code. See [The Next Web](https://thenextweb.com/news/lovable-vibe-coding-security-crisis-exposed). > **Explanation:** The BOLA (broken object level authorization) was reported through HackerOne on 3 March 2026 and stayed open for 48 days, until it went public on 20 April. Lovable said it did not suffer a data breach, blamed unclear docs and the triage, and later partly apologised. Some security blogs make bigger claims that are not confirmed. Guardio's VibeScamming test is from April 2025: they asked several tools to build a phishing kit, and Lovable did it with the least resistance. ### The security scan ![The security tab of the demo project: deep scan not run yet, quick scan found no issues, dependencies with 3 known issues](https://slides.mctantwerp.be/decks/en/extra-webdev/11-lovable/security.png) - The quick scan runs on every publish and looks for the usual misconfigurations - The deep scan lets agents read all the code, only when you start it - Then you: log in with two accounts and try to reach what belongs to the other > [!WARNING] > "No issues found", with three known issues in the box below. A finding does not stop a publish either. > **Explanation:** This is the demo project, right after the build. The quick scan runs on every publish and looks at RLS, leaked password protection, dependencies and exposed MCP servers. It says no issues found, while the box under it lists three known issues in the dependencies. The deep scan reads the whole codebase with agents, only when you start it. On the demo it took four minutes, was free, and found nothing either, which matches the migration: the policies are right. Use both, they catch real things. Just do not confuse a green scan with a review: it does not know that bookings of other students should stay hidden, unless that is in a policy it can check. ### The scan says every table has RLS enabled, with policies. Is your data safe? - A. Yes, that is what RLS is for - B. Not necessarily: a policy can let everyone through - C. Only if you also have a custom domain - D. Yes, as long as the publishable key stays secret **Answer:** B. Not necessarily: a policy can let everyone through A policy with USING (true), or a select for anon on a table with personal data, counts as a policy and protects nothing. The tempting answer about the key is wrong too: the publishable key is never secret, it ships in the JavaScript of every visitor. A domain changes nothing about who can call the API. Two accounts tell you more than the scan. > **Explanation:** This was the exact criticism of the first scanner Lovable shipped in 2025: it checked whether a policy exists. USING (true) is a policy. So is a select policy for anon on a table with email addresses. If you remember one thing from this chapter: test with two accounts. ## 5. Getting your code out > **Explanation:** This is where Lovable gets interesting for developers. The code is a normal TypeScript project in a git repo. You can take it home, work on it with your own coding agent, and push it back. That also means you can finish a Lovable project a client hands you. ### Inside the project ![The file tree of the demo project: .lovable/plan, drizzle/migrations, src/routes, src/integrations/supabase and .env](https://slides.mctantwerp.be/decks/en/extra-webdev/11-lovable/files.png) | Folder | What is in it | | --- | --- | | `.lovable/plan` | The plan you approved | | `drizzle/migrations` | The tables, constraints and RLS policies, as SQL | | `src/routes` | One file per page, TanStack Router | | `src/integrations/supabase` | The client that talks to Lovable Cloud | | `.env` | The Supabase url and the publishable key. Public by design. | > **Explanation:** The file tree of the demo project in the Code tab. A normal TypeScript project: routes per page in src/routes (TanStack Router), the Supabase client in src/integrations/supabase, the database in drizzle/migrations, and the plan you approved in .lovable/plan. The .env holds the Supabase url and the publishable key, nothing secret. Real secrets live in Cloud, under Secrets, and only edge functions can read them. Editing code in the browser needs a paid plan, reading it does not. ### Your code on GitHub ```console $ git clone git@github.com:you/foosball-booker.git $ cd foosball-booker && npm install $ npm run dev $ git commit -am "Show the current slot in yellow" && git push ``` - Two-way, on one branch: your push shows up in Lovable, its edits show up on GitHub - A rejected push lands on a branch called `lovable-sync` - Only from Lovable to git: you cannot import a repo you already have. See [Git sync](https://docs.lovable.dev/integrations/github). > **Explanation:** Git sync works with GitHub, GitLab and Bitbucket, on every plan, also the free one. It syncs one branch, by default main. A push from your laptop shows up in Lovable within seconds. If your push is rejected, by branch protection or a conflict, Lovable pushes its own changes to a branch named lovable-sync instead. What does not work: importing an existing repo into Lovable. Sync only starts from a Lovable project. ### Lovable and your agent 1. **Lovable**: The first version, the screens, quick visual changes, the database migrations. 2. **Git**: One branch both sides use. Pull before you start, push when you are done. 3. **Your laptop**: Tests, a refactor, a review of the policies, with your own coding agent and a diff you read. **[AI in practice](https://slides.mctantwerp.be/en/extra-webdev/10-ai-in-practice)**: Plan, build step by step, review and push: the same workflow, on your own laptop. > **Explanation:** An AGENTS.md in the root is read by Lovable and by your own agent, so the conventions live in one place. Never work on the same thing in both at the same time, or you end up merging your own conflicts. Pull before you start on your laptop, push when you are done, and only then go back to Lovable. ### Publishing and leaving | | How | Plan | | --- | --- | --- | | **Publish** | `yourapp.lovable.app`, only after Publish changes | Every plan | | **Own domain** | Connect it in the project settings | Paid plans | | **Download** | The codebase as a zip | Paid plans, or Git sync on any plan | | **Host elsewhere** | Vercel, Netlify or Cloudflare, with server rendering | Your own work | | **Database elsewhere** | Your own Supabase project, with `pg_restore` | Your own work, storage and secrets too | See [hosting elsewhere](https://docs.lovable.dev/tips-tricks/external-deployment-hosting) in the docs. > **Explanation:** Publishing to a lovable.app subdomain is free. Changes only go live when you press Publish changes, so the preview and the live app can differ. On the free plan, check whether the app is public or invite only before you send the link. Leaving Lovable completely is possible but not free of work: the TanStack apps need a host that runs server code, and the database moves with pg_restore to your own Supabase project, while storage, functions and secrets you set up again yourself. ### Credits | Plan | Price | Credits | | --- | --- | --- | | **Free** | $0 | 5 a day, at most 30 a month. No code editing, no download, no own domain. | | **Pro** | $25 a month | 100 a month plus the 5 a day, unused ones roll over | | **Students** | 50% off Pro | Up to 12 months, with your school email on [lovable.dev/students](https://lovable.dev/students) | Examples from the docs: a button in grey costs 0.5 credits, a login 1.2, a landing page with images 2. A revert gives nothing back, and a fix loop eats your month. See [the plans](https://docs.lovable.dev/introduction/subscription-plans). > **Explanation:** Prices from the docs on 14 October 2026. The docs say themselves that the chat pricing applies through 31 October 2026, so check the plans page before you pay for anything. Since June 2026 there is one credit balance, split into build credits and run credits (Cloud, the AI gateway, connectors). Unused credits on Pro roll over. The student discount needs an academic email and a free workspace, and you get it once. ## 6. When to use it > **Explanation:** The honest answer depends on two questions: who maintains it, and whose data is in it. A prototype that lives for two weeks is a different thing from an app a client runs for three years. ### Good fit, bad fit #### Good fit - A clickable prototype to test an idea with real users - A landing page or a site for one event - An internal tool for a small team, without sensitive data - The first version, before you know what to build #### Bad fit - A project that has to run on the stack of the client - Payments, health data, anything under heavy legal rules - A big codebase that a team maintains for years - A backend full of queues, jobs and integrations > **Explanation:** The left column is where Lovable saves you days. The right column is where it costs you later: a stack you did not choose, a backend you cannot easily move, and code nobody on the team has read. None of the right column is impossible in Lovable. It just stops being faster than doing it yourself. ### Not the only one | Tool | From | Strong at | | --- | --- | --- | | **Bolt.new** | StackBlitz | A full stack app that runs in your browser tab | | **v0** | Vercel | React and Next.js frontends, deploys to Vercel | | **Replit Agent** | Replit | Builds and hosts the whole app in Replit | | **Figma Make** | Figma | A prototype from your design and design system | | **Google AI Studio** | Google | Small apps on Gemini, deployed to Cloud Run | > **Explanation:** They all move fast. Bolt runs everything in a WebContainer in your browser. v0 is strongest on the frontend and deploys to Vercel. Replit Agent builds and hosts full stack apps in Replit. Figma Make turns a design into a prototype inside Figma. Google AI Studio builds small apps on Gemini. Give two of them the same prompt, and you see quickly which one fits your project. ### Lovable or not Pick what you would do in each situation, then read why. **1. A client wants to test two versions of a sign-up flow with ten users next week.** - **Lovable, two projects or two versions** ✓ - A Laravel project with Inertia - A Figma file with screenshots A clickable prototype that lives for a week is what Lovable is best at. Laravel takes too long for something you will throw away, and screenshots do not tell you where people get stuck. **2. The client runs on Laravel and asks for a new module with invoices.** - Build it in Lovable and link to it - **A coding agent in their Laravel project** ✓ - Lovable, then convert it to PHP Lovable only makes React with Postgres. The module has to live in their stack, with their auth and their tests, so you work in their repo with your own agent and review every diff. **3. Your Lovable app for a student association has 300 members with phone numbers. The scan is green.** - Publish, the scan checked it - **Log in as two members and try to read the other one** ✓ - Remove RLS, it makes queries slower A green scan means nothing was found. Two accounts and a few tries tell you whether one member can see the phone numbers of the others, which is exactly what went wrong in 2025. **4. You pressed Try to fix four times and the booking page still crashes.** - Press it once more, it is free - **Ask for the root cause in Plan mode, or revert** ✓ - Switch to another browser Every fix stacks code on the last attempt. Stop, ask for the root cause without changing anything, or revert to the last version that worked and send a better prompt. > **Explanation:** The question behind every situation is the same: who maintains this, and whose data is in it? Read the explanation after every answer, also when you got it right. ### Task: Take it home With the app from the previous assignment. Stuck? The slides Your code on GitHub and The policies it wrote have the commands and the links. 1. Connect your Lovable project to GitHub 2. Clone it, npm install, npm run dev. Does it run on your laptop? 3. Read the policies of every table, in the Cloud tab or in the migrations 4. Log in as two users and try to read or delete what belongs to the other 5. Make one change with your own coding agent, push it, and find it back in Lovable 6. Done when your change shows up in the Lovable preview and you know which tables are safe > **Explanation:** Start with step 1 in the project settings of Lovable, under Git. Out of credits? You can still do steps 2 to 5: Git sync works on every plan. For step 5 a small change is enough: a colour, a text, a test for a helper. If Lovable does not show your change, check that you pushed to the branch it syncs, usually main. ## Glossary - **Lovable**: A Swedish AI app builder in the browser. You describe an app in a chat, it writes a full stack TypeScript app with a Postgres database and hosts it for you. (slide 4) - **Vibe coding**: Building software by prompting and judging the result in the preview, without reading the code. Fine for a prototype, risky for anything with real users and real data. (slide 5) - **Plan mode**: The mode in Lovable where the agent asks questions and writes a plan to .lovable/plan.md without touching the code. You approve the plan before anything gets built. (slide 9) - **Knowledge**: Instructions Lovable sends along with every message of a project, up to 10,000 characters. The Lovable version of an AGENTS.md, which it also reads. (slide 15) - **Lovable Cloud**: The backend Lovable sets up for you: Postgres, auth, storage, edge functions and secrets, built on Supabase. (slide 19) - **Row Level Security**: Postgres policies that decide per row who may read, insert, update or delete it. In a Supabase app the browser talks to the database with a public key, so RLS is the only lock on the data. (slide 20) - **Publishable key**: The public key a Supabase app ships in its JavaScript, called the anon key before. Everyone can read it, so it protects nothing on its own. RLS policies decide what it may do. (slide 20) - **Credits**: What Lovable bills you in. Every message in Build or Plan mode costs credits depending on how much work it is, a revert gives none of them back. (slide 32) - **Git sync**: The two-way link between a Lovable project and one branch of a repo on GitHub, GitLab or Bitbucket. A push from your laptop shows up in Lovable, and the other way round. (slide 29) ## Links and sources ### In the deck - [FAQ](https://docs.lovable.dev/introduction/faq) (slide 6) - [Lovable: Plan mode](https://docs.lovable.dev/features/plan-mode) (slide 9): .lovable/plan.md, questions first, approve to build - [Lovable: prompting](https://docs.lovable.dev/prompting/prompting-one) (slide 14) - [Lovable: Knowledge](https://docs.lovable.dev/features/knowledge) (slide 15): Project and workspace knowledge, AGENTS.md - [Lovable: debugging prompts](https://docs.lovable.dev/prompting/prompting-debugging) (slide 16): Try to fix, then find the root cause - [Lovable: Lovable Cloud](https://docs.lovable.dev/features/cloud) (slide 19) - [Supabase: Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security) (slide 21) - [Statement on CVE-2025-48757](https://mattpalmer.io/posts/statement-on-CVE-2025-48757/) (slide 23): Matt Palmer on missing RLS in Lovable apps - [Lovable's vibe coding security crisis](https://thenextweb.com/news/lovable-vibe-coding-security-crisis-exposed) (slide 24): The BOLA in the Lovable API, April 2026 - [Lovable: Git sync](https://docs.lovable.dev/integrations/github) (slide 29) - [Lovable: hosting elsewhere](https://docs.lovable.dev/tips-tricks/external-deployment-hosting) (slide 31) - [Lovable for students](https://lovable.dev/students) (slide 32) - [Lovable: plans](https://docs.lovable.dev/introduction/subscription-plans) (slide 32): Checked on 2026-10-14 ### Sources - [Lovable docs](https://docs.lovable.dev) - [Lovable: Build mode](https://docs.lovable.dev/features/agent-mode): Formerly Agent mode - [Lovable: version history](https://docs.lovable.dev/features/projects/history): A revert does not restore database data - [Lovable: AI gateway](https://docs.lovable.dev/features/ai) - [Lovable: security](https://docs.lovable.dev/features/security): Quick scan on publish, deep scan on request - [Lovable: publishing](https://docs.lovable.dev/features/publish) - [Lovable: upgrade to TanStack Start](https://docs.lovable.dev/features/upgrade-to-tanstack-start): The default stack since May 2026 - [Lovable: credits and usage](https://docs.lovable.dev/introduction/credits-and-usage) - [Lovable raises $400M Series C](https://lovable.dev/blog/series-c) - [Lovable found most vulnerable to VibeScamming](https://thehackernews.com/2025/04/lovable-ai-found-most-vulnerable-to.html)