Build real apps
without writing code

New here? Start on this page. In about half an hour you'll go from a blank screen to a real app live on the internet — a public link like nest.lovable.app you can open on your phone and send to anyone. You won't write any code. You describe what you want in plain English, Lovable builds it in front of you, and you press one button to publish. Each step below is the short version and links to its full Part for when you want the detail.

Words you'll see (in plain English)

Step 1 — Make a free account (2 min)

Go to lovable.dev and sign up. You'll land in the workshop with a small daily allowance of credits — enough to build your first app. The full tour is in Part 1: Setup.

Step 2 — Describe your app (your first prompt)

In the prompt box, tell Lovable what you want in plain English. Keep the first one simple — you'll add to it later.

Build me a simple to-do app called Nest.
I can type a task, see my list of tasks, and check one off when it's done.
Keep it clean and modern, and make it work well on a phone.

Step 3 — Watch it build in the preview

Lovable gets to work and your app appears in the live preview beside the chat. Try it: add a task, check it off. Don't love something? Just say so in the prompt box — "make the header pink," "add a delete button" — and watch it change. The full build loop is Part 3, and Part 4 shows how you can always roll back — you can't break it permanently.

Step 4 — Publish to a live link

Happy with it? Open the Publish dialog and publish. Lovable gives your app its own public address ending in .lovable.app. That link is now live on the internet.

Step 5 — You did it 🎉

Open your .lovable.app link on your phone. That's your app, live on the internet, made from a few sentences. Everything after this makes it bigger and realer: a memory, logins, security, your own domain, and eventually payments.

Where to go next

Two things make everything ahead easier: seeing that every app is really just four pieces, and having plain-English meanings for the words you'll meet. Skim this once now, then come back whenever something doesn't click. Nothing here needs memorizing.

The big picture: every app is four pieces

1. Building with Lovable

2. The four pieces up close — data & backend

3. Shipping & owning it

4. The pro workflow (Lane 2)

5. Getting found & plugging in

You don't have to read the whole course before you build. This is a paced, ten-day path: a little each day, always with something real to show for it. Days 1–6 get a full app live the Lovable way. Days 7–10 turn it into a pro product other people can rely on.

The 10-day path

You only do this once. In about ten minutes you'll have a free Lovable account and know your way around the screen. There's nothing to install and no terminal — Lovable runs entirely in your web browser.

Step 1 — Create your free account

Go to lovable.dev and sign up for a free account. That's the whole setup — you're in, with a small daily allowance of credits to start building (more on credits below).

Step 2 — Meet the two halves of the screen

The workshop has two main halves. Learn these and almost nothing else will feel confusing:

Step 3 — Two ways to work: Build mode vs Plan mode

Lovable can work two ways, and knowing the difference is the single biggest thing that separates people who love Lovable from people who burn through their credits.

You'll use plan mode for real in Part 2. For now, just know it's there.

The temptation is to start typing prompts. Don't — not yet. The people who get great apps out of Lovable all do the same unglamorous thing first: they write down what they're building. Ten minutes here saves hours (and a lot of credits) later.

2.1 — Write your MASTERPLAN

You don't have to write it alone. The easiest way is to have a chat assistant (ChatGPT or Claude) interview you and turn your answers into a tidy plan. Paste this and answer its questions honestly:

I'm going to build an app in Lovable, and I'm not a developer. Act as an expert product manager and interview me to create a clear PRD (Product Requirements Document) for it. Ask me ONE question at a time, wait for my answer, then ask the next — don't ask everything at once, and don't write the document until you've covered everything. Work through: the problem I'm solving, who it's for, the main things a user must be able to do (and what can wait for later), what "done"/success looks like, and anything else you'd need to build it well. If an answer of mine is vague, ask a follow-up. When you have enough, give me the finished plan in Markdown. My idea is: [describe your idea in as much detail as you can].

Save what it gives you as your MASTERPLAN. Here's the shape a good one takes:

# MASTERPLAN: Nest

## What this is
A to-do app where people can sign in and keep a private list of tasks.
A paid "Pro" tier unlocks more lists.

## Who it's for
Busy people who want a dead-simple task list that syncs to their phone.

## What a user must be able to do
1. Sign up and log in
2. Add, see, and check off their own tasks
3. Only ever see their own tasks (never anyone else's)
4. Upgrade to Pro for more lists

## What "done" looks like
Live at a real web address, works great on a phone, and my tasks
are still there when I come back tomorrow.

## Style
Clean, modern, calm. Works beautifully on mobile.

2.2 — Let plan mode interview you

Now bring your MASTERPLAN into Lovable — but switch to Plan mode first. Instead of building right away, plan mode slows down on purpose, and for a first build that's exactly what you want. Here's what happens:

1. It asks you clarifying questions. Rather than guessing, Lovable asks about the parts you left fuzzy — who logs in, what a task needs, what "done" means to you.
2. It writes a plan you can edit. You get a structured, written plan laid out for you, and you can change it directly — add a rule, delete a step, rewrite a line — like marking up a document.
3. Nothing is built until you approve. Only once you approve the plan does Lovable switch to Build mode and start writing code. Read it first: editing the plan yourself is free; fixing a half-built app costs credits.

2.3 — A shortcut: let AI write your Lovable prompt

There's a trick pros use called meta-prompting: instead of writing the perfect Lovable prompt yourself, you ask a chat assistant to write it for you — and you tell it to read Lovable's own docs first, so its advice matches how Lovable actually works today. Paste this into ChatGPT or Claude:

Act as an expert Lovable app builder. Before you answer, read the official docs at https://docs.lovable.dev so your advice matches how Lovable works today.

I'm going to build this app in Lovable: [paste your MASTERPLAN, or describe your app in detail].

Write me ONE clear, well-structured prompt I can paste into Lovable's plan mode to kick it off. Include: the app's purpose, who it's for, the main screens, the data it needs to remember, and the visual style. Keep it in plain English. Ask me any question you need answered before you write it.

2.4 — Set your project rules (the app's rulebook)

One more thing pros set up early: a short set of standing rules the builder should follow on every prompt — things you'd otherwise have to repeat over and over. Think of it as house rules pinned to the wall.

Lovable lets you save this kind of standing context with your project. The exact place it lives can change as Lovable updates, so check docs.lovable.dev for where to put it today. What matters most is what you write. Here's a starter rulebook for Nest — adapt it to your app:

# Project rules for Nest

## What this is
A to-do app with logins and a paid "Pro" tier.

## Rules for the builder
- Build one feature at a time; show me a plan before big changes.
- Never put passwords or API keys in the code — use Secrets.
- Every user must only ever see their own tasks.
- Keep the design clean, simple, and great on phones.
- Ask me before adding anything I didn't request.

Now the fun part: you talk, and an app appears. The secret isn't typing fast or knowing magic words — it's a simple loop you'll repeat a hundred times: say what you want → watch it build → look at the result → say the next thing. This Part is about running that loop well, so every turn moves you forward instead of in circles.

Write a prompt that lands the first time

A good prompt answers three questions before Lovable has to guess: what you're building, how it should look, and what's on the screen. Vague in, vague out — the clearer you are, the closer the first build lands to what's in your head.

Build the first screen of Nest, a simple to-do app.
Purpose: I can keep a private list of tasks.
On screen: a text box to add a task, the list of tasks below it,
and a checkbox on each task to mark it done.
Style: clean, calm, modern — and it must look great on a phone.

Build mode vs plan mode — the habit that saves you the most

You met these two modes in Part 1. Here's the rule the pros live by: for anything bigger than a tiny tweak, switch to plan mode first. It asks you a few clarifying questions, writes out a plan you can read and edit, and only starts building once you approve it. You catch misunderstandings while they're still free words on a screen, not half-built features you have to pay to redo.

One step at a time — never one giant prompt

The most common beginner mistake is trying to describe the whole app in a single enormous message: logins, payments, settings, dark mode, all at once. Lovable will attempt it — and when something's off, you won't know which part broke. Build the way you'd eat a big meal: one bite at a time.

• First: the basic screen (add a task, see the list).
• Then: check a task off.
• Then: make it remember tasks (that's Part 5).
• Then: logins, then security, then publish.

Each small step gives you a working thing to look at, and a clean place to fix or roll back if you don't like it.

Show, don't just tell

Words are great, but sometimes a picture is faster. If you have a screenshot of an app you like, a rough sketch, or a design, you can add it to your prompt and say "make the layout look like this." A picture removes a lot of guessing. Lovable also lets you talk instead of type in places, which is handy on a phone. The exact controls for attaching an image or using your voice move around as Lovable updates — the current how-to is in the docs.

Prompt queuing — stack your next moves like a playlist

Lovable works on one task at a time. But you don't have to sit and wait — while it's building, you can keep typing your next instructions, and they line up in a visible queue above the chat box, ready to run in order. It's like queuing songs in a playlist: the current one plays while the next ones wait their turn. You can reorder, edit, or remove anything in the queue, and pause or resume the whole thing.

The 5 mistakes that trip up beginners

Almost every "Lovable isn't working for me" story comes down to one of these five. Dodge them and you're already ahead of most people:

Here's the fear that stops a lot of people from experimenting: "What if I change something and wreck the whole thing?" With Lovable, you basically can't — not permanently. Every version of your app is saved as you go, and you can step back to any earlier one whenever you like. This Part is your safety net, and it's worth reading before you start building boldly.

Your version history

As you build, Lovable keeps a running history of versions — a timeline of every meaningful change. Think of it like the version history in Google Docs: every save is there, in order, ready to revisit. Nothing you do overwrites the past; it just adds a new entry to the list.

Bookmark the versions you love

When you reach a version that really works — the design finally clicks, everything runs — you can bookmark it so it's easy to find again later. It's the equivalent of folding down the corner of a page you'll want to come back to, so you're not scrolling through dozens of entries hunting for "the good one."

Preview before you leap

Before you jump back to an older version, you can preview it — see how the app looked at that moment — without giving up where you are now. It's like re-reading the old draft before deciding to restore it, so you're never guessing blind.

Revert — the undo button for your whole app

If you decide an earlier version was better, you revert to it and that becomes your working app again. One move rolls the whole project back to a known-good moment — no code, no panic. And because reverting is just loading a save, it doesn't erase the versions in between; they're still in the history if you change your mind again.

So far, Nest can show a list of tasks — but close the tab and they're gone. That's because your app has no memory yet. In this Part you give it one: a place to write things down so they're still there tomorrow, on any device. In Lovable, that memory is called Cloud.

Turn on Cloud

Lovable has a built-in backend called Cloud — a database, logins, and file storage, with nothing to install and no separate account to create. You just switch it on (or simply ask Lovable to save your tasks, and it'll offer to enable Cloud for you). Under the hood it's built on Supabase, the same professional foundation big apps use — you'll meet Supabase directly in Lane 2. Cloud is available on every plan, including free.

Tables and rows — a spreadsheet you don't have to touch

Inside the database, information lives in tables and rows — and if you've ever used a spreadsheet, you already understand both:

You mostly won't build these by hand. You describe what Nest needs to remember — "each task has text, a done/not-done status, and belongs to one person" — and Lovable creates the right tables for you.

Fake data vs. real data

Here's a subtle trap. Early on, Lovable often fills the screen with mock data — realistic-looking placeholder tasks that make the app look finished. But mock data is a painted-on prop: it isn't saved anywhere, and it's the same for everyone. The moment that matters is when your app switches to real, saved data — tasks genuinely written to your database and read back later. A quick way to tell them apart: add a task, then refresh the page. If it's still there, it's real. If it vanishes, you were looking at a prop.

Right now anyone who opens Nest sees the same single list. To make it a real app, each person needs their own account — their own private tasks, their own login. The old way of adding "Sign in with Google" meant developer consoles, secret keys, and a lot of fiddly setup. Lovable removes almost all of that.

The magic part: Google sign-in with no developer consoles

Normally, adding "Sign in with Google" means registering your app in Google's developer console, generating credentials, and wiring up redirects — the kind of chore that stops beginners cold. Lovable offers a "Managed by Lovable" option that handles all of that for you: Lovable owns the setup, the credentials, and the security updates behind the scenes. The docs call it the default, recommended way to do it. You get a working "Sign in with Google" button without ever touching a cloud console.

Later, if you'd rather use your own Google credentials, you can switch — it's a setting under your Cloud users' auth options, and switching doesn't disturb accounts people have already made. Managed Google sign-in is a Lovable Cloud feature, so it rides on the Cloud you turned on in Part 5.

Other ways to sign in

The classic email-and-password sign-up is available too, and it's a perfectly good default. Lovable supports other sign-in methods as well; which ones are offered, and how each is set up, changes over time — so check the authentication docs for exactly what's available today before you promise your users a particular button.

Managing your users

Once login is on, Lovable gives you a users area in your Cloud settings — the guest list of everyone who's signed up. You can see who has an account and manage them as your app grows. You don't need to do anything fancy here on day one; just know it's where "who's using my app" lives.

Decide roles up front (user vs. admin)

One decision worth making before you build login, not after: what kinds of people use your app? Almost every app has at least two:

• A regular user — signs in, sees and manages only their own tasks.
• An admin — you, the owner, who may need to see more or manage the app.
• Later, a paying "Pro" user — a regular user with extra features unlocked (that's Part 16).

Telling Lovable these roles up front is one of the biggest things separating a clean build from a messy one — it's literally on the list of common beginner mistakes from Part 3. Retrofitting roles onto an app that assumed everyone was the same is a headache; naming them at the start is a sentence.

This is the most important Part in Lane 1, and the one beginners most often skip. You've got accounts now — but an account only feels private if the data behind it truly is. Keeping data safe isn't one big scary task; it's three plain ideas and one habit. Get these and you can let real people in without losing sleep.

Row Level Security, in practice

Under the hood, RLS quietly adds a rule to every request — in effect, "…and only where this row belongs to the person asking." Without it, an app's data door can be wide open: anyone poking at the raw data can pull everyone's rows. That's the single most common way vibe-coded apps leak private information. The good news: on Lovable Cloud, tables created through the normal flow get RLS switched on for you. Your job is to ask for it and confirm it's really there — say to Lovable, "make sure every table has Row Level Security so each user can only see their own rows," and then verify it (the open-the-table habit from Part 5 applies here too). Background reading: how RLS works.

Secrets — the vault for keys

As your app grows it'll use keys — secret passwords that let it talk to services like a payment provider or an AI. The one rule: keys never go in your code, where anyone could read them. Lovable gives you a Secrets vault to store them safely instead. It's so serious about this that if you ever paste a key straight into the chat, Lovable notices and offers to move it into Secrets for you — like a friend catching you about to write your PIN on the back of your debit card.

Edge functions — the trusted middleman

So if the key lives in the vault, how does your app use it without exposing it? Through an edge function — a small piece of code that runs on a server, away from the user's browser. Think of it as a back-office clerk: the customer (the browser) never walks into the safe. They hand a request to the clerk, the clerk goes to the safe, does the sensitive thing, and comes back with just the result.

Edge functions are the right home for three kinds of work:

You usually won't write these by hand — you ask Lovable to "use an edge function so the key stays server-side," and it sets up the clerk for you.

Run the security scan before every publish

Lovable has a built-in security scan that reads your app looking for trouble — exposed keys, unsafe handling of what users type, data left readable, information leaking through error messages. When you open the Publish dialog, a quick basic scan runs on its own in the background; you can also run a deeper scan for a fuller check. Best of all, the security view has a "Try to fix all" button that lets Lovable repair the issues it found.

Make this a routine, not a one-off. Tick these every time before you go live:

Your app doesn't have to do everything by itself. When it needs to take a payment, send an email, or use some clever AI, it can plug into a service that already does that — the way a new appliance plugs into the wall instead of you generating your own electricity. Lovable calls these plug-ins connectors, and there are two very different kinds. Knowing which is which saves a lot of confusion.

The two types at a glance

App Connectors — wired into your live app

These are the ones that become part of Nest itself. Your app calls them while real people use it — for example, a payment service like Stripe to take money (that's Part 16), or a service to send email. They're set up once by a workspace admin and then available to any app in that workspace, so you don't reconnect the same thing over and over. The exact catalog of available services grows over time; the current list is in the connectors docs.

Chat (MCP) Connectors — the agent's own toolbelt

These don't go into your app at all. They give the Lovable chat live access to your other tools while you build, so it has real context instead of guessing. "MCP" is just the industry name for this kind of connection — you don't need to understand the plumbing. Prebuilt ones include tools like Notion, Linear, Jira, Miro, n8n, Sentry, PostHog, and Granola, among others — so you could tell Lovable "match the spec in my Notion doc" and it can actually read it. These are per-person connections, and custom ones are supported on every plan.

No connector? You're still not stuck

What if the service you want isn't on any connector list? No problem — a connector is a convenience, not a requirement. Almost every online service offers an API (a way for apps to talk to it) and a key (your password to it). Put the key in Secrets, and have Lovable call the service from an edge function — the exact safe pattern from Part 7. If a service has an API and a key, Lovable can almost certainly connect to it, connector or not.

This is the payoff Part: the moment Nest stops being "a thing on your screen" and becomes "a thing on the internet with its own address." You've done the hard parts — data, logins, security. Publishing is the easy, satisfying button at the end. Then we'll make it truly yours: your own web address, your own icon, and even an app icon on your phone's home screen.

The Publish flow

When you're ready, open the Publish dialog. It walks you through a few simple steps — the address, who's allowed in, a little info about your app, a review, and any security findings — and then puts your app online. By default your app gets a free public address ending in .lovable.app, like nest.lovable.app. That link is live immediately; you can open it on your phone and text it to a friend.

One thing to remember, because it trips everyone up once: changes are not published automatically. After you edit, your live app stays on the old version until you open Publish again and choose Update. Lovable shows a small dot on the Publish button when you have changes that aren't live yet — that dot is your reminder.

Your own web address

The free .lovable.app link is perfect to start with. When you're ready for something like getnest.com, Lovable's Domains page gives you two paths: buy a new domain right inside Lovable, or connect one you already own from any registrar (Namecheap, Cloudflare, GoDaddy, and the like). Connecting can be automatic — Lovable detects your provider and sets up the technical DNS records for you — or you can enter them by hand if you prefer.

Make it look finished: favicon and social preview

Two small touches make an app feel real. The favicon is the tiny icon in the browser tab. The social preview image (also called an OG image) is the picture that appears when someone shares your link in a chat or on social media. You don't need a designer for either — you can ask Lovable to generate both to match your app, and set them in the app's metadata during publishing. It's five minutes that makes a shared link look legit instead of blank.

Hide the "Edit with Lovable" badge

Published Lovable apps show a small "Edit with Lovable" badge by default. Removing it is a paid-plan feature (Pro and above) — on the free plan the badge stays. If keeping your brand clean matters, that's one reason to upgrade; if you're still learning, the badge is harmless. The exact on-screen wording can differ slightly from the docs' label, so glance at your own published app to see what it says today (details in the publish docs).

Put it on your phone's home screen (PWA)

Here's a delightful trick: a published Lovable app can be made installable. Visitors can choose "Add to Home Screen," and your app gets its own icon that opens full-screen — no browser bars, with offline support — just like an app from an app store, without ever going through one. It's the closest thing to "I made a real phone app" you'll feel all course.

See who's visiting: built-in analytics

Once you're live, you'll want to know if anyone's actually showing up. Lovable includes built-in analytics for published apps that show things like how many visitors and pageviews you're getting, how long people stay, where they came from, and what devices they're on. No extra tool to install — it's right there for your published project.

Your app is live — but "live" and "found" aren't the same thing. A shop with no sign, on a back street, is open yet empty. This Part is about the sign: helping both Google and the new AI assistants know your app exists and send people to it. Lovable now has a built-in dashboard that does most of the heavy lifting.

Lovable's SEO & AI-search dashboard

Lovable has a built-in SEO & AI search dashboard (under Services). It scans your app and gives you a checklist of things that would help you get found — a missing description here, a weak title there — and offers to fix them for you. Running the review is free on every plan, as of 2026, so there's no reason not to look.

Research your keywords with Semrush

The dashboard can also help you figure out what people search for. Lovable has a tie-in with Semrush — a well-known keyword-and-competitor research tool — that you can chat with about which words to target and what similar apps are doing. Here's the catch worth knowing: as of 2026, this Semrush-powered research is offered free, with no separate account, as a limited-time promotion running through mid-August 2026. Treat it as a bonus that may change, not a permanent fixture — check the SEO docs for what's currently included before you lean on it.

Sitemap and robots, in plain English

Two bits of jargon you'll see, demystified:

• A sitemap is simply a list of all your pages, written for search engines — like handing a new employee a directory of every room so they don't miss any.
• A robots file is a short note telling search engines which pages they may look at and which to skip — the "staff only" sign on certain doors.

You rarely touch these by hand — Lovable and its SEO tools handle them — but now the words won't spook you when they come up.

Why SSR helps (just a little)

One quiet advantage under the hood: as of 2026, new Lovable apps are server-side rendered (SSR) by default. In plain terms, the page arrives already written out from the server, instead of being assembled inside the visitor's browser after it loads. That matters for getting found because search engines and AI crawlers see your real content right away rather than a blank page — and it tends to load faster for people, too. You don't have to do anything to get this; it's just good news you inherit.

AEO — getting recommended by AI

When someone asks an AI assistant "what's a good simple to-do app?", you want it to say yours. AI assistants recommend things they can clearly understand, so the same tidiness that helps Google helps here: a clear name and description, plain explanations of what your app does and who it's for, real content rather than vague marketing. Lovable's dashboard checks the AI-search side too — that's the "AI search" half of its name.

Welcome to Lane 2 — where you stop just "making an app" and start working the way real software teams do. Almost no tutorial teaches this part, which is exactly why it's the most valuable stretch of the course. It all begins with one free, one-time step: connecting GitHub. Until now, everything that makes Nest exist has lived in a single place — inside Lovable. This Part gives your code a second home you actually own.

Repo and commit, in plain English

A repository is the folder that holds every file of your app plus its entire history — the master binder for Nest. A commit is one snapshot filed into that binder, each with a little note ("added login," "fixed the header") and a timestamp. Remember the version history from Part 4 — your save points inside Lovable? GitHub is those same snapshots kept safely outside it. And you don't write commits by hand: once GitHub is connected, Lovable files them for you as you build.

Turning it on

Connecting is a one-time click in your project settings: authorize GitHub, and Lovable creates a repo for your app and starts syncing to it automatically. Good news for your wallet — GitHub integration works on every Lovable plan, including free; it's not a paid feature. (It works with GitLab too, if that's the tool you use.)

What actually changes now

Your code moving outside Lovable unlocks four real things:

That last row is the quiet reason this Part comes first in Lane 2. Everything ahead — branches, your own database, professional hosting — hangs off your code living in GitHub. Wire it up once and the rest of the lane opens.

This is the idea that separates people who "made an app" from people who work like a software team — and almost no tutorial teaches it. It sounds technical. It isn't. It's one habit, borrowed straight from live theater.

Why pros never edit opening night

Picture fixing a typo directly on the live stage, mid-performance, in front of the whole audience. If your change breaks something, everyone watching sees it break — instantly, publicly. That's exactly what editing production (main) directly feels like. The entire point of a rehearsal stage is that mistakes there are free: you try the risky scene, it flops, you fix it, and nobody in the audience ever knew. Only the version that actually works graduates to opening night.

In app terms: staging is a copy of Nest where you build, break, and experiment safely. main is the exact code your real users are running right now. Keeping the two separate means your live app stays calm and working while you do messy, creative work off to the side.

How this is actually wired (the honest mechanics)

Here's the part tutorials get wrong, so read it slowly. Lovable syncs exactly one branch at a time. It does not have a "staging vs main" toggle, and it cannot build two branches at once. What it does have is a branch picker: you choose which single branch Lovable is currently building on, and you can create new branches from there.

A branch you create forks from whichever branch is currently active. So if you want a staging branch that starts from your live code, switch Lovable to main first, then create staging from it. One heads-up worth remembering: commits made on a branch Lovable isn't currently synced to won't appear in Lovable until you either merge them in or switch the synced branch to them.

So the pro setup is refreshingly simple: point Lovable's one synced branch at staging, and build there. Your live main sits untouched. When the rehearsal is ready for the audience, you promote staging into main — not inside Lovable, but over on GitHub, with a pull request.

Promoting with a pull request

A pull request (PR) is a formal "please move these rehearsed changes onto the main stage" — with a moment to look them over before they go live. On GitHub you open a PR from staging into main, glance at what changed, and merge it. The instant it merges, main holds your new, tested version. (In the next two Parts, that merge is what will automatically update your real, hosted app.)

Think of the PR as the stage manager's nod before a scene goes on: a deliberate, reviewable checkpoint between "it works in rehearsal" and "the audience sees it." That pause is the whole benefit — it's your last chance to catch something before it's public.

In Lane 1 you flipped on Lovable Cloud and got a database without having to think about it. That was the right call to start. Now you graduate: move to your own Supabase project, where you hold the keys, see the real dashboard, and truly own your data. It's also the piece that makes the Vercel lane possible.

The real dashboard

Connect your own Supabase and you get the full Supabase dashboard — the professional control room that Cloud kept tidied away. That's where you see your tables (your data, laid out like spreadsheets), your auth (the list of users and how they sign in), and your policies (the security rules that decide who can read what). It's the same information Lovable showed you in a friendlier wrapper — now in the tool professionals actually use every day.

Two honest ways to get there

There are two real paths, and it's worth being clear-eyed about both:

• Start fresh on your own Supabase. In your project settings under Integrations, choose Connect Supabase, authorize it, and pick your organization and project. From then on, your app talks to a database you own.
• Migrate an existing Cloud database. Be honest with yourself here: there is no one-click "move from Cloud to Supabase" button. The documented path is manual — export your database from the Cloud tab → Overview → Advanced settings, move your code via the GitHub integration from Part 11, and separately re-export your stored files and reconnect your auth and secrets. It's doable, but it's a real chore — so most people who know they'll go pro connect their own Supabase early, before there's much data to move.

Why this matters for what's next

Owning your Supabase project isn't just about pride. Professional hosting — Vercel, the next Part — needs to connect directly to your database using its keys (a project URL and a public key). Your own Supabase project is what gives you those keys to hand over. This Part is the groundwork; Part 14 is where it pays off.

You've got your code in GitHub (Part 11), a branch habit (Part 12), and your own Supabase (Part 13). Now you put it all on a professional stage. Vercel is where serious web apps get hosted — and thanks to a change in how Lovable builds apps, getting there is almost embarrassingly easy.

The setup (genuinely zero-config)

Here's the change that makes this easy. As of 2026, new Lovable apps are built on TanStack Start and are server-side rendered (SSR) — and Vercel recognizes that framework automatically. In plain terms: you don't set a build command, you don't set an output folder, you don't configure anything technical. You point Vercel at your repo and it just knows what to do. Walk it through:

• 1 · Sync to GitHub — already done in Part 11; Vercel reads your code from there.
• 2 · Import the repo — go to vercel.com/new, choose your Nest repository, and click Import. Vercel auto-detects the TanStack Start framework — leave the build settings alone; there's nothing to fill in.
• 3 · Set main as the production branch — it usually already is. From now on, every push to main deploys to your public production site.
• 4 · Get preview URLs for free — every push to any other branch (like staging) or any pull request automatically gets its own preview URL: a private, live copy to test before it ever reaches the public. This is the payoff of the two-branch habit.
• 5 · Add your environment variables — in the project's settings, add your Supabase keys (the project URL and public key from Part 13) as environment variables. These are how your hosted app finds your database. Each environment can hold its own values, so staging and production can even point at different data if you want.

What you end up with

Two live homes for Nest, kept in sync automatically: a public production site (from main) and a private preview for whatever you're testing (from staging). Push code, and the right site updates itself. That automatic, two-address setup is exactly how professional teams ship — and you now have it. The daily rhythm that ties it all together is the final Part.

Every piece of Lane 2 is now in place — GitHub, two branches, your own Supabase, and Vercel. This last Part is the choreography that connects them into one smooth daily rhythm. Learn this loop and you're not "someone who made an app" anymore — you work the way real software teams work.

The loop, step by step

Then you start again at step 1. In one line, the rhythm is:

Build in Lovable → staging → preview link → test on phone → main (via PR) → production

Once it's set up, most of it runs itself — Vercel handles steps 2, 3, and 6 automatically. Your only real jobs are building on staging and deciding when a change is good enough to promote.

Why the loop keeps you safe

Every safeguard you built in Lane 2 shows up in this loop. Your own Supabase (Part 13) means the data is yours and secured with RLS. Two branches (Part 12) mean your experiments never touch live users. Vercel previews (Part 14) mean you always test the real, hosted thing — not just how it looked inside Lovable — before the public sees it.

This is the Part where Nest stops being a project and becomes a product. You wrote a paid "Pro" tier into your MASTERPLAN back at the start; now you wire up the part that actually takes money. The tool for that is Stripe — the same payment engine behind a huge share of the internet's checkouts.

Test mode first — always

Stripe has two worlds: test mode and live mode. Test mode is a complete, fake copy of the payment system — it uses pretend card numbers, moves pretend money, and can't charge anyone a real cent. You build and rehearse the entire purchase here first. Only when you've bought Pro from yourself in test mode, start to finish, and watched Nest unlock — do you flip the switch to live.

The two Stripe pieces you'll use

You don't need to learn all of Stripe. For Nest, two hosted pages do almost everything — and "hosted" is the magic word: Stripe builds and runs these pages, so you don't have to.

Connect Stripe in Lovable

Payments is an App Connector (the "wired into your live app" kind from Part 8). You connect your Stripe account, and — exactly like every other key in this course — your Stripe secret key lives in Secrets, never in your code, and the actual charge happens server-side in an edge function. Lovable does the plumbing when you ask; your job is to describe what you want and to keep that key in the vault. The exact connect steps shift as Lovable updates, so follow the current connectors docs and Stripe's docs.

Add a paid "Pro" tier to Nest using Stripe, in TEST MODE only for now.
- Use Stripe Checkout (Stripe's hosted payment page) so we never handle card details ourselves.
- Add a "Manage subscription" link that opens the Stripe customer portal.
- Keep the Stripe secret key in Secrets and call Stripe from a server-side edge function — never in the browser.
Walk me through connecting my Stripe account, and don't switch anything to live mode until I say so.

Gate the Pro features (the important part)

Taking the money is only half the job. The other half is making sure only paying users actually get the Pro perk — for Nest, extra lists. This is called feature gating: the app checks "is this person an active Pro subscriber?" and shows or hides the feature accordingly.

One rule matters more than any other here, and it's the same lesson as Part 7: check the subscription on the server, never trust the browser. If the only thing standing between a free user and Pro features is code running in their browser, a determined person can flip it. The real check — "is this account paid?" — has to happen server-side, where the user can't reach it.

Gate Nest's "extra lists" feature behind an active Pro subscription.
Check the subscription status on the server (in an edge function), not just in the browser, so it can't be bypassed.
Free users should see a friendly "Upgrade to Pro" prompt instead of the locked feature.

Nest works. That's a huge deal — but "works" and "feels finished" aren't the same thing. This Part is the layer that makes people trust your app on sight: it looks right on their phone, it explains itself to a stranger, and the small details feel considered instead of accidental. None of it is hard; it's mostly a handful of well-aimed prompts.

Check every screen size — especially the phone

Most people will open Nest on a phone, but you've been building on a big laptop screen — so that's the view you've never really checked. Fix that before anything else. Open your live link on your actual phone, and look at a tablet width too. When something's wrong — a button spilling off the edge, text too tiny to read, things overlapping — the trick is to be specific. "Make it responsive" gives the AI nothing; "on mobile, this exact thing is broken, do this exact fix" lands every time.

Go through Nest at phone and tablet widths and fix the responsiveness. Be specific about each fix:
nothing should overflow the screen, tap targets should be big enough for a thumb, and text should be readable without zooming.
Show me the mobile layout when you're done.

Do focused design passes

Rather than one vague "make it prettier," ask for one improvement at a time so you can judge each change. Consistent spacing. A calmer color balance. A friendly empty state — what a brand-new user sees before they've added any tasks — which is one of the most overlooked screens in any app. And remember the trick from Part 3: if you've seen a look you like, paste a screenshot (Ctrl+V) and say "aim for this feel."

A little motion goes a long way

Small animations make an app feel responsive and alive — a task gently fading when you check it off, a button that reacts to a tap. The keyword is subtle: a touch of motion feels premium, while a screen full of things flying around feels like a toy. Ask for "small, tasteful animations," look at the result, and dial it back if it's too much.

A landing page that sells the app

Right now Nest probably drops visitors straight into the app or a login box. But a stranger who clicks your link needs to know, in five seconds, what this is and why they'd want it. That's a landing page: a simple front page for logged-out visitors — a clear headline, a sentence on who it's for, a screenshot, and one obvious "Sign up" button. It's the difference between people bouncing and people trying it.

Add a landing page that logged-out visitors see first, before the app.
Include: a clear headline saying what Nest is, one line on who it's for, a screenshot of the app, and a single obvious "Sign up free" button.
Keep it clean and calm, and make sure it looks great on a phone.

Everything breaks sometimes — even apps built by professional teams. What separates people who get unstuck fast from people who spiral isn't talent; it's having a calm order of operations. This Part gives you one. Follow it and most bugs fall over in a few minutes instead of ruining your afternoon (and your credit balance).

First move: ask the app to test itself

Before you do anything else, hand the problem back to the builder and ask it to reproduce the trouble itself. As of 2026, per Lovable's own updates, you can ask the Lovable agent to try your app the way a real user would — walk through the flow, find where it goes wrong, fix it, and check again — instead of you describing the bug secondhand. Exactly what the agent can do here keeps expanding, so treat it as "ask and see," and check the current docs for what it does today.

Test the whole "sign up, log in, add a task, check it off" flow in Nest yourself, as if you were a new user.
Tell me exactly which step breaks and what the error is, then fix it and run the flow again to confirm it works.

Copy the exact error → paste → "explain and fix"

When you see a red error message, resist the urge to retype it or paraphrase it. Copy the exact text and paste it into the chat — those precise words are the single most useful clue you can give. Then ask for the meaning first, so you learn something, and the fix second.

I got this error: [paste the exact error message here].
First, explain in plain English what it means and what likely caused it. Then fix it, and tell me how to check that it's really fixed.

Read the logs

When something fails silently — no error on screen, it just doesn't work — the answer is usually in the logs: your app's running diary of what it did and where it tripped. You don't have to read them like code; ask Lovable to check them for you: "look at the logs and tell me why saving a task didn't work." The logs often name the exact problem the screen was too polite to show.

For a stubborn bug, diagnose in plan mode

If a bug won't die after a couple of tries, stop firing fixes and switch to plan mode. Ask it to investigate and explain the cause before changing anything. You read the diagnosis, make sure it's aiming at the real problem, and only then approve the fix — so you don't pay to "fix" three innocent things on the way to the guilty one.

This isn't the glamorous Part, but it's the grown-up one. The moment real people log into Nest — and especially once they pay — you're handling their information, and a few plain-language legal pages come with that territory. The good news: they're mostly generatable, they're not as scary as they look, and this section walks you through the honest version.

The pages you'll likely need

You can have Lovable draft all of these in plain, readable English — not intimidating legal jargon. Just don't let it guess the facts that are specific to you.

Create a Privacy Policy, Terms & Conditions, and a cookie notice for Nest, each as its own page.
You already know from the app what data we collect (accounts, tasks, and Stripe payments). Do NOT guess these — use exactly what I give you:
- Business name and contact email: [your name/company, contact@yourdomain.com]
- Country where the business operates: [your country]
Write in plain, accessible English, not heavy legalese. Link the three pages together in the footer.
If there's an important third-party service in the app you're unsure about, ask me instead of inventing it.

The cookie banner

Create the legal pages first, then the banner that links to them. A decent cookie banner shows up on a visitor's first arrival, lets them accept or reject (with reject as easy as accept), remembers their choice so it doesn't nag, and links to your Privacy Policy.

Add a cookie banner to Nest that appears on a visitor's first visit, lets them accept all or reject all (reject as prominent as accept),
remembers the choice so it doesn't show again, links to the Privacy Policy, and matches the app's style.

The honest disclaimer

Here's the part it would be irresponsible to skip.

You've built the whole thing. This appendix is the drawer you keep by your desk afterward — copy-paste prompts for the moves you'll make again and again, three quick cheat sheets for the rhythms worth memorizing, and where to go when you want more. Bookmark this page.

The prompt library

1 · Kickoff — start a new app

Build the first screen of [app name], a [one-line description].
Purpose: [what a user can do]. On screen: [the main elements]. Style: [look and feel] — and it must look great on a phone.
Use plan mode: ask me any clarifying questions and show me a plan before you build.

2 · Meta-prompt — have another AI write your Lovable prompt

Act as an expert Lovable app builder. Before answering, read the official docs at https://docs.lovable.dev so your advice matches how Lovable works today.
I want to build: [describe your app]. Write me ONE clear prompt I can paste into Lovable's plan mode, covering purpose, users, main screens, the data to remember, and the visual style. Ask me anything you need first.

3 · Project rules — the app's rulebook

Save these as standing project rules you follow on every prompt:
- Build one feature at a time; show a plan before big changes.
- Never put keys or passwords in the code — use Secrets.
- Every user only ever sees their own data (Row Level Security on every table).
- Keep the design clean, simple, and great on phones.
- Ask me before adding anything I didn't request.

4 · Feature-add — build the next thing

Add [one feature] to [app name]. Just this one feature for now.
It should: [what it does]. Show me a plan first, then build it. When you're done, test it and tell me how to check it works.

5 · Test-it — ask the app to check itself

Test the [name the flow, e.g. "sign up and add a task"] flow yourself, as if you were a new user.
Tell me exactly which step breaks and what the error is, then fix it and run the flow again to confirm.

6 · Fix-it — paste an error

I got this error: [paste the exact error].
Explain in plain English what it means and what likely caused it, then fix it and tell me how to confirm it's fixed.

7 · Security — lock down the data

Make sure every table has Row Level Security so each user can only see their own rows. Confirm no keys are in the code — they belong in Secrets.
Then run the security scan and use "Try to fix all," and show me anything that's left.

8 · SEO & AI search

Run the SEO & AI-search review on [app name] and apply the important fixes: a clear title and description, good page metadata, and a sitemap.
Explain each change in one line so I understand what it does.

9 · Responsiveness — fix the mobile view

Go through [app name] at phone and tablet widths and fix the responsiveness, being specific about each fix:
nothing overflows the screen, tap targets are thumb-sized, and text is readable without zooming. Show me the mobile layout when done.

10 · Landing page — sell the app

Add a landing page that logged-out visitors see first: a clear headline of what [app name] is, one line on who it's for, a screenshot, and one obvious "Sign up free" button. Clean, calm, and great on a phone.

11 · Payments — add a paid tier (test mode)

Add a paid tier to [app name] with Stripe, in TEST MODE only. Use Stripe Checkout so we never handle cards ourselves, and add a customer-portal link to manage the subscription.
Keep the Stripe key in Secrets and call Stripe from a server-side edge function. Gate the paid feature with a server-side subscription check. Don't switch to live mode until I say so.

12 · Legal pages

Create a Privacy Policy, Terms, and a cookie notice for [app name], each as its own page, in plain English.
Don't guess my details — use: business name/email [ … ], country [ … ]. Link the pages together in the footer. (Reminder to self: have a human review these before launch.)

Cheat sheet 1 — the build loop

Cheat sheet 2 — pre-publish checklist

Cheat sheet 3 — the pro daily loop

Where to go next

• Official docs — the source of truth for anything that's changed since this course: docs.lovable.dev.
• Community & Discord — ask questions and see what others build; find the current invite link on lovable.dev.
• Templates & remix — start from someone else's project instead of a blank box; browse the gallery on lovable.dev.
• Forget a word? Every term in this course is defined in The Big Picture & Glossary.