You've just learned the layers of a tech stack — the dining room, the kitchen, the pantry, the building. Now we'll build one. In this module you'll use Lovable to create a personal café tracker, watching each layer come to life as you prompt.
Before AI builds anything, it needs a spec — the kind you learned to write in the previous session. Here's the one we'll use. Read it, then paste it into a fresh Lovable project.
We're starting everyone with the same spec so you can follow along and compare notes. After the workshop, you can run this whole module again with your own app idea.
Right now, you have the building (Lovable is hosting it) and the dining room (the interface users see). In the next three lessons, we'll furnish the dining room, stock the pantry, and open for business.
You have a working V1 of Coffee Shop Crawl — the dining room exists, even if it forgets everyone who visits. Now we'll make it feel more intentional.
Your V1 works, but it probably looks like a prototype. This lesson is about teaching AI to make targeted, outcome-driven changes to the frontend — the dining room your users actually see. The move here is specificity. Watch what happens when we go from vague direction to precise direction.
The second prompt doesn't tell Lovable how to build anything — it describes what the user should feel and experience. This is the outcome-driven spec pattern applied to an iteration, not just a V1. Use it every time you want to change something.
We're keeping this to a single frontend layer on purpose. If you want to go deeper after the workshop, here's how each kitchen-metaphor layer would show up in Coffee Shop Crawl:
The waiters (APIs) — If you wanted each café to autofill its real neighborhood and address when you type the name, Lovable can wire up the Google Places API. You bring the API key; Lovable handles the rest.
The bouncer (authentication) — We're keeping this as a single-user app, but if you wanted private collections per person: "Add Supabase auth with email login, and scope the cafés table so each user only sees their own entries." Lovable sets up both the auth flow and the database rules.
Your dining room is set. The form and the list feel like they belong together. Next: teach the app to remember what you put into it.
Right now, everything you add to Coffee Shop Crawl disappears when you refresh. That's because the app has no pantry — nowhere to store ingredients between services. In this lesson we'll set up the database, then add the logic (filter and sort) that makes the data useful.
Lovable will likely ask you to connect a Supabase account when you run this prompt. Follow its prompts — it takes about 2 minutes. If you don't have a Supabase account, it'll walk you through signing up (it's free).
You just asked Lovable to do two things: read from the pantry (filter and sort query the database) and show different results in the dining room (the list updates). Both layers talking to each other — that's your app working as a system, not just a collection of parts.
The backend logic — In a traditional app, the filtering and sorting logic would live in backend code. Lovable abstracts this: it writes the database queries for you based on your plain-English description. If you wanted more sophisticated logic (like "show me cafés I haven't visited in more than 3 months"), you'd describe the outcome and Lovable handles the query.
Your pantry is stocked and the kitchen is running. The app remembers every café, and you can slice the collection any way you want. One step left.
Your app exists, but only you can see it. Coffee Shop Crawl isn't really open for business until someone else can walk in. Let's publish it — which in Lovable is a single click — and send the link to one real person.
coffee-shop-crawl-abc123.lovable.app. Copy it.You can iterate on an app forever in preview mode and never know if it works. The moment you send a friend a link, you find out three things at once: whether the app loads for someone who isn't you, whether they can figure out what it does without a tutorial, and whether it makes them want to use it.
Custom domains (the building's street address) — Lovable deploys to an auto-generated URL by default. If you want to use your own domain (like coffeecrawl.me), Lovable supports it: just add your domain in project settings and it walks you through the DNS setup.
The kitchen metaphor, complete — You've now touched every layer we talked about. The dining room (frontend) was Lesson 2. The pantry (database) and the kitchen's logic were Lesson 3. The building (hosting) was this lesson. The two layers we skipped deliberately — the waiters (APIs to external services) and the bouncer (authentication) — are the natural next steps when you want to make this app more connected or more private.
You've built and deployed a real app. Not a tutorial example — your actual café collection, live on the internet. Keep the URL. Add to it every time you find a café worth remembering.