Add logins, save user data and accept payments — still without code
This week adds the foundations of a real product: identity, saved data, and payments. The goal is a simple and safe flow, not a complex technical architecture.
Authentication answers who the user is. Authorisation answers what that user may see or change. Test account creation, sign in, sign out, password recovery, and restricted pages. Never assume a hidden button protects private information.
A database stores organised records so the app can retrieve and update them. Define the minimum fields you need and who may access each record. Collecting less data reduces risk and makes the product easier to maintain.
Choose whether the offer uses a one time payment or a subscription. Build the checkout in test mode first. Confirm the price, currency, billing period, cancellation language, receipt, and what happens after success or failure.
Do not place secret keys in public prompts, screenshots, or front end code. Use the platform's secure secret storage. Add a privacy notice, protect user records, and know how to remove test accounts. Ask for technical review before handling sensitive or regulated information.
Approximately 45,000 views within its first few months
Why it fits: A current, end-to-end tutorial covering Supabase, authentication, databases, storage, Stripe and deployment. Its lower view total is offset by its recency and unusually close match to the curriculum.
Recommended use: Assign only the authentication, Supabase and Stripe chapters.
Add user accounts and save one type of user-generated data. Treat payments as a sandbox exercise.
The video supports the lesson above — it doesn't replace it.
Add secure user accounts and a test checkout to this product. First explain the proposed data fields, access rules, and payment states in plain language. Use the platform's secure authentication and secret storage. Do not expose keys. Provide a test plan for signup, login, logout, recovery, checkout success, checkout failure, and cancelled checkout.
Week 6 · Case study
Source note: Documented product profile. The ordering flow discussed here is an instructional breakdown of the product, not a reported customer outcome. The student-sized version below is an illustrative exercise, not part of the reported case.
QuickTables is a restaurant-management platform built with Lovable and added to the Made with Lovable showcase in July 2025. It brings together mobile restaurant pages, direct ordering, SMS marketing, and loyalty features.
For students, the useful lesson is the underlying data flow. A customer has an account, selects menu items, places an order, receives a status, and may earn loyalty credit. The product does not need to begin with every restaurant-management feature.
Build a test-mode ordering application for one imaginary café. Include customer login, five menu items, an order table, three order statuses, and a Stripe test checkout. Never use real card information during class.
Which information must belong to the customer, and which information may the restaurant staff change?
Respond in your submission →Add accounts and a working test checkout to your product. Submit a short test report with screenshots of the main states. Do not submit passwords, secret keys, or real payment details.