Detailed content
🧱 Website vs. app: what are you really building?
One site is generally read-only: people arrive, view the content, and leave—nothing is saved. A app responds to whoever uses it: receives data, stores that data, remembers you, and triggers actions. It's the difference between a poster on the wall and an ATM.
The four pieces of an app: front end (what you see), back end (what processes things), database (where things are stored), and integrations (external services).
Knowing the right tool for each problem keeps you from asking Claude for the wrong thing and wasting time.
Front end · back end · database · integration · deterministic vs. probabilistic.
✓ It’s time to turn it into an app when…
- ✓You need to store data from users (emails, responses).
- ✓Each person must sign in and see their own area.
- ✓Something needs to happen afterward (send an email, record an order).
✗ It’s still just a website when…
- ✗The person only reads the content, and nothing is saved.
- ✗There’s no login or private areas.
- ✗No action happens after the visit.
🍽️ The restaurant analogy
O front end is the dining room (tables, menu). The back end is the kitchen (where the order is processed). The database is the pantry and ledger. The integrations are the suppliers and the payment terminal—the outside services the restaurant calls when it needs them.
🗄️ The database: where data lives
Without a database, all collected data is lost when the tab closes. With a database, it becomes your asset. Think of Supabase as a supercharged spreadsheet: the tables are tabs, the rows are records, and the columns are fields — only it's reliable, with a ready-to-use API that works directly with Claude Code.
A trusted place to store records — names, emails, form responses, user accounts.
The database is the app’s deterministic "firm skeleton" — saving an email has to save that one email, always the same.
Table · row · column · "record of record" (the source of truth) · connector/MCP.
Open the connectors
In Claude Code, click the "+" button and then "connectors".
Connect Supabase
Find Supabase in the list and click Connect—it opens a window to authorize.
Create the project and confirm
Ask Claude to create a new project. Then confirm on supabase.com that it appeared.
Connect and create the database
Conecte este projeto a um banco de dados Supabase. Crie um projeto novo para este app.
🔐 Login and accounts: capture data securely
Two pieces work together: the form, which turns each response into a table row, and the authentication, which identifies each person (sign-up, login, logout). Without login, everyone sees everything; with login, you have private areas and per-user content—all managed by Supabase.
Form → table (field becomes a column), combined with the account system: sign-up, sign-in, and session.
It’s the leap from “a site that displays” to “an app that collects and protects”—the beginning of real value.
Field → column · validation · session · "authenticated area".
✓ Do it in the test
- ✓Ask for registration and login with a required password, managed in Supabase.
- ✓In Authentication → Sign-in providers, turn off email confirmation during testing only.
- ✓Consider "Sign in with Google"—it's the standard today and makes things easier for users.
✗ Don’t forget before launch
- ✗Leave email confirmation turned off in production (it fills the database with fake signups).
- ✗Forget to test logging out and logging back in with the same password.
- ✗Unlock private areas without a valid session.
Basic authentication
Add sign-up and login with a required password, all authenticated and managed in Supabase. After login, take the user to a simple dashboard in the same style as the site.
Original (EN):
Add sign-up and login with a required password, fully authenticated and managed in Supabase. After login, take the user to a simple dashboard in the same style as the site.
💬 Build in layers: ask, test, repeat
You don't write everything at once. You layered conversation: "add a form," test it, "now save it to the database," test it, "now make it look better," test it. Each request is small and verifiable — that's how you build with confidence.
Describe a small change in natural language, review the result, and adjust — instead of trying to do everything at once.
Small changes are easy to test and fix. That’s what keeps the project under control.
Ask → test → feedback loop · describe the "what," not the "how" · lean context (/compact, fork).
Make just one request
Describe one small change and wait for Claude to finish.
Open the app and check
Test it for real. Don’t trust “done”—see for yourself.
Give feedback and repeat
Describe what’s wrong or missing and send the next request. Repeat until you’re happy with it.
🧠 Practical tip: manage your context
Conversations that are too long make answers worse. When the history gets too large, use /compact. For an isolated experiment without mixing everything together, rename the current conversation and create a fork from it.
✅ Test end to end
"It seems to work" isn’t enough. You test the full flow like a real person — fill it out, submit it — and only then check Supabase to see the exact record in the table. The screen says "sent"; the database tells the truth.
Go through the app as a user, then manually check in Supabase’s Table Editor.
Seeing "sent successfully" on the screen doesn't prove it was saved. Confirming it in the database is what gives you certainty.
End-to-end test · source of truth · manual review.
Use the actual app
Fill out the form, create a test account, and log in as anyone would.
Open Table Editor
In Supabase, go to the Table Editor and look for the exact row you just created.
Confirm the right data
The name and email you entered must appear there—field by field. Only then is it validated.
⚖️ Deterministic vs. probabilistic
Language models are probabilistic: the same question can produce different answers. An app needs deterministic parts—saving an email must save that one email, always the same. That’s why the truth lives in the database, not in text generation.
🚀 Publish (deploy)
An app that only runs on your PC is no use to anyone. Publish is to “put” the code on the internet, at an address anyone can open. It’s the step that makes the app real—and completes the concept → functional app cycle.
Deploy the app to Vercel, with a public address anyone can open.
Publishing is what turns a local experiment into something other people actually use.
Deploy · production environment · "live" · pre-launch checklist.
Publish it live
Quando estas mudanças estiverem prontas, publique e coloque o app no ar na Vercel.
Original (EN):
When these changes are ready, deploy and publish the app live on Vercel.
Going deeper (optional): the checklist before sharing
Before sending the link to anyone: confirm on vercel.com that the deployment went through, open the generated address, and run through the full flow again in an incognito browser. Most importantly: reactivate email confirmation in Supabase — you had only turned it off for testing.
Self-check (optional): how do you have certainty that a lead was saved?
✏️ Exercises
1. Connect and create the table (easy)
Connect Supabase to your project and create the table leads. Criterion: the table appears in the Table Editor with the right columns.
2. Capture a real lead (easy)
Add the form and submit a test response. Criterion: the row with the name and email you entered appears in the table leads.
3. Add Login (medium)
Implement sign-up and password login. Criterion: you create an account, sign out, and sign back in with the password—and see an area that only appears after login.
4. Iterate with feedback (medium)
Make at least three small improvements (one per request), testing between them. Criterion: each change was described in one sentence, tested, and confirmed before the next one.
5. Publish (medium)
Deploy the app to Vercel. Criterion: you open the public address in an incognito browser, and the complete flow works.
⌨️ Ready-to-use prompts
Use these as a starting point and adapt them to your app. When the prompt is canonical, we also include the original in English. The complete bank is at Library → Prompts.
Form that saves to the database
Add a form with name, email, and “what's your biggest challenge today?” When someone submits it, save the responses in Supabase, in the `leads` table.
Ask for feedback before building
Before implementing, tell me what you need from me and which decisions you’ll make. Ask clarifying questions if anything is ambiguous.
Iterate based on a screen
Aqui está um print da tela atual. Há espaço demais acima e abaixo da imagem. Ajuste para caber bem, sem cortar o conteúdo importante.
Let Claude execute instead of asking you to do it (canonical)
Sempre que possível, execute você mesmo as tarefas (CLI, scripts) em vez de me pedir para fazer manualmente. Só me peça quando for algo que só eu posso fornecer (login, chave, decisão).
Original (EN):
Whenever possible, run the tasks yourself (CLI, scripts) instead of asking me to do them manually. Only ask me for things only I can provide (login, key, decision).
⚠️ Common errors
- ✗Try everything all at once. One giant request produces a result that's hard to test and fix. Break it into small steps.
- ✗Not validating in the database. Seeing "sent successfully" on the screen doesn't prove it was saved. Open the Table Editor and check the row.
- ✗Forget to re-enable email confirmation. Turning it off to test is fine; leaving it off in production fills the database with fake sign-ups.
- ✗Expect identical responses from AI. Models are probabilistic. For what needs to be the same every time, rely on the database and logic.
- ✗Let the context bloat. Conversations that are too long make answers worse. Use
/compactand consider a fork for parallel workstreams.
✅ Module summary
Completion checklist
- ☐ I can explain the difference between a website and an app and name the four parts (front end, back end, database, integrations).
- ☐ I connected Supabase to my project and created a new database project.
- ☐ I have a form that saves real responses to the table
leads. - ☐ I confirmed the record directly in the Supabase Table Editor.
- ☐ I added sign-up and password login, and tested creating an account, signing out, and signing in.
- ☐ I built incrementally: small request → test → feedback → next step.
- ☐ I deployed the app to Vercel and validated the complete flow (with email confirmation re-enabled).
Next module:
2.3 — Build Anything: Beyond Websites and Apps, Custom Automations and Tools