Building an online store in Lovable works best in one order: ship the storefront UI first, then wire products, cart, and Stripe checkout to the backend. Lovable turns plain English into a full React + Tailwind app, and Lovable Cloud provisions a native Supabase backend (Postgres, auth, storage, RLS, real-time) so orders and inventory are real, not mocked.

The 22 prompts below are grouped so each one builds on the last. Use Chat Mode to plan and Build Mode to implement, keep each prompt scoped to save credits, and put shared facts (product fields, roles, tax rules) in your Knowledge file. If you are new to the tool, start with the best Lovable prompts, then branch into full-stack app prompts and reusable prompt templates.

Advertisement

Storefront & catalog

Build the shopper-facing surface first. These six prompts create the pages customers browse before any backend exists, so use static placeholder data now and connect it to Supabase in the backend section.

1. Full store homepage

Build the homepage for an online store called [STORE NAME] selling [PRODUCT TYPE, e.g. handmade ceramics].

Layout, top to bottom:
- Sticky header: logo left, category nav center ([CATEGORY 1], [CATEGORY 2], [CATEGORY 3]), search icon and cart icon right (cart shows an item-count badge).
- Hero: headline, one-line subhead, primary "Shop now" button linking to the catalog.
- Featured products: responsive grid of 8 product cards (image, name, price, "Add to cart").
- Category tiles: 3 large clickable tiles with image + label.
- Trust row: free shipping, easy returns, secure checkout (icon + short text each).
- Newsletter signup band and a footer with links.

Use React + Tailwind. Use placeholder product data for now; do NOT add a backend or cart logic yet. Keep it clean and mobile-first.

Why it works: It scopes the first build to layout only, so Lovable ships a fast homepage without burning credits on backend guesses.

2. Product grid with categories

Create a "Shop all" catalog page at /shop.

- Responsive product grid (4 columns desktop, 2 tablet, 1 mobile).
- Each card: product image, name, price, and an "Add to cart" button on hover.
- A category chip bar at the top: "All", [CATEGORY 1], [CATEGORY 2], [CATEGORY 3]. Clicking a chip filters the visible products.
- Show a result count ("48 products") and a "Load more" button for pagination.

Reuse the product card component from the homepage. Use placeholder data. Do not build checkout yet.

Why it works: Reusing the existing card keeps the design consistent and tells Lovable not to reinvent components.

3. Product detail page with gallery + variants

Build the product detail page at /product/[slug].

- Left: image gallery with a main image and clickable thumbnails.
- Right: product name, price, star rating summary, short description, and variant selectors for [size] and [color] (buttons, not dropdowns). Selecting a variant updates the shown price and availability.
- Quantity stepper and a large "Add to cart" button.
- Accordion sections: full description, shipping & returns, materials.
- Below: a "You may also like" row of 4 product cards.

Use placeholder data with at least 3 variants. Disable "Add to cart" when the selected variant is out of stock.

Why it works: Naming the exact variant fields and the out-of-stock rule prevents Lovable from shipping a generic gallery you have to rebuild.

4. Category page with filters + sort

Create a category/collection page at /category/[slug].

- Page header with the category name and a short intro line.
- Left sidebar filters (collapsible on mobile): price range slider, [color] checkboxes, [size] checkboxes, and an in-stock-only toggle.
- Top bar: sort dropdown (Featured, Price low-high, Price high-low, Newest) and active-filter chips that can be removed individually.
- The product grid updates instantly as filters and sort change.

Keep filters in URL query params so the view is shareable. Use placeholder data.

Why it works: URL-driven filters make results shareable and give Lovable a concrete state model instead of ad-hoc component state.

5. Search with autocomplete

Add site search.

- Clicking the header search icon opens a full-width search overlay with an input focused automatically.
- As the user types (debounced), show an autocomplete dropdown: up to 6 matching products (thumbnail + name + price) and a "See all results for '[query]'" link.
- Enter or clicking "See all" navigates to /search?q=[query] showing the full result grid, reusing the catalog layout.
- Show a friendly empty state when there are no matches.

Match on product name and category. Use placeholder data for now.

Why it works: Debouncing and a capped result count are stated up front, so search feels instant instead of firing on every keystroke.

6. Wishlist / favorites

Add a wishlist feature.

- A heart icon on every product card and on the product detail page toggles that product's favorite state.
- Show a wishlist count badge next to the cart icon in the header.
- Add a /wishlist page listing saved products in a grid with a "Move to cart" and "Remove" action on each.

For now, persist the wishlist in localStorage so it survives refresh. Later we will store it per logged-in customer in Supabase. Do not change the cart yet.

Why it works: It sets a clear interim (localStorage) and future (Supabase) plan, so Lovable does not over-build before accounts exist.

Cart & checkout

Now make buying possible. These five prompts add the cart, wire real payments through a Stripe edge function, and confirm the order. Keep the Stripe secret in secrets, never in client code.

7. Slide-out cart

Add a slide-out cart drawer.

- Clicking the header cart icon slides a panel in from the right over a dimmed backdrop.
- Each line item: thumbnail, name, selected variant, unit price, quantity stepper, remove (x), and line total.
- Footer: subtotal, a note that shipping and taxes are calculated at checkout, a "Checkout" button, and a "View cart" link to the full cart page.
- Empty state with a "Start shopping" button.

Store cart state in a shared React context and persist it to localStorage. Update the header badge count live. "Add to cart" anywhere should open this drawer.

Why it works: A single shared cart context stops duplicate, conflicting cart state across the drawer, badge, and cart page.

8. Cart page with quantity + totals

Build the full cart page at /cart.

- Table of line items (image, name, variant, unit price, quantity stepper, line total, remove).
- Order summary card on the right: subtotal, estimated shipping, estimated tax, and order total; a "Proceed to checkout" button; and a promo code input (wire the logic in a later prompt).
- Editing quantity or removing an item updates totals immediately and syncs with the slide-out cart.
- Show a clear empty-cart state.

Reuse the cart context. Keep money math in cents to avoid rounding errors.

Why it works: The cents instruction heads off floating-point money bugs that are painful to fix after checkout is live.

9. Stripe checkout (edge function)

Add Stripe checkout using Lovable Cloud.

- Create a Supabase edge function "create-checkout" that takes the cart line items, re-reads each product's price from the database (never trust client prices), creates a Stripe Checkout Session, and returns the session URL.
- Store STRIPE_SECRET_KEY in secrets. Do not expose it client-side.
- The "Checkout" button calls this function and redirects to the returned Stripe URL.
- Create a second edge function "stripe-webhook" that verifies the Stripe signature and, on checkout.session.completed, writes an order row (items, totals, customer email, status = paid) to the orders table.

Ask me for my Stripe keys, then confirm the webhook endpoint I need to register in Stripe.

Why it works: Re-reading prices server-side and verifying the webhook signature are the two rules that keep checkout from being tampered with.

10. Order confirmation page + email

Add order confirmation.

- After Stripe redirects back, show /order/[id] with a success header, order number, purchased items, totals, shipping address, and estimated delivery.
- Load the order from the orders table by id; if payment is still pending, show a "confirming your payment" state that polls until the webhook marks it paid.
- Send a confirmation email to the customer via an edge function (order summary + order number). Store the email-sent status on the order.

Handle the case where a user reloads or shares the confirmation URL without exposing other customers' orders (enforce with RLS).

Why it works: Polling until the webhook lands avoids showing "paid" before Stripe actually confirms, and the RLS note protects other customers' orders.

11. Discount / coupon codes

Add coupon codes.

- Create a coupons table: code, type (percent or fixed), value, min_order_amount, usage_limit, times_used, expires_at, active.
- On the cart and checkout, the promo input validates a code against the table (case-insensitive) and applies the discount to the order summary, showing the discount line and new total.
- Re-validate and re-apply the discount inside the create-checkout edge function so the discounted amount is authoritative server-side. Reject expired, inactive, or over-limit codes with a clear message.
- Increment times_used only after a successful paid order.

Do not let the client set the final price.

Why it works: Validating the coupon again in the edge function is what stops shoppers from forging their own discounts in the browser.

Advertisement

Products & orders backend

These six prompts turn placeholder data into a real Supabase backend and give you the tools to run the store. Build the schema first, then the admin on top of it.

12. Product database schema

Set up the product database in Supabase via Lovable Cloud.

Tables:
- products: id, title, slug, description, base_price_cents, category, image_urls (array), status (draft/active/archived), created_at.
- variants: id, product_id, name (e.g. "M / Black"), sku, price_cents, in_stock (int for inventory).
- categories: id, name, slug.

Then:
- Migrate the storefront (homepage, catalog, product detail, category page, search) to read from these tables instead of placeholder data.
- Product images go in a Supabase storage bucket.
- RLS: anyone can read products/variants where status = active; only admins can write.

Seed 12 sample products across 3 categories so the store isn't empty.

Why it works: Defining tables, storage, and RLS in one brief keeps the schema coherent instead of accreting mismatched columns across prompts.

13. Admin product CRUD

Build a protected admin at /admin/products.

- List all products in a table (thumbnail, title, category, price, status, stock) with search and status filter.
- "New product" and "Edit" open a form: title, slug (auto from title), description (rich text), category, base price, image upload to storage, and a variants editor (add/remove rows with name, sku, price, stock).
- Save writes to the products and variants tables. Support archiving instead of hard delete.

Gate the whole /admin area behind an "admin" role; non-admins are redirected. Enforce admin-only writes in RLS, not just in the UI.

Why it works: Requiring the role check in RLS (not only the UI) means a hidden admin URL cannot be abused by a normal signed-in user.

14. Inventory tracking + low-stock

Add inventory tracking.

- When an order is marked paid (in the stripe-webhook function), decrement in_stock on each purchased variant. Never let stock go below zero; if a variant is out of stock at payment time, flag the order for review.
- On the storefront, hide or disable "Add to cart" for out-of-stock variants and show a "Low stock" badge when in_stock <= [LOW_STOCK_THRESHOLD].
- In /admin, add a "Low stock" view listing variants at or below the threshold, and let an admin adjust stock manually with an audit note.

Do stock decrements server-side inside the webhook, not on the client.

Why it works: Decrementing stock in the webhook ties inventory to confirmed payment, so browsing or abandoned carts never oversell.

15. Order management dashboard

Build an order dashboard at /admin/orders.

- Table of orders: order number, date, customer email, item count, total, and status (paid, fulfilled, shipped, refunded). Search by order number or email; filter by status; sort by date.
- Clicking a row opens the order detail: line items, totals, shipping address, payment reference, and a status timeline.
- Let an admin update status and add a tracking number; changing to "shipped" triggers a shipping-notification email to the customer.
- Show top-line counts: today's orders, unfulfilled orders, revenue this week.

Admin-only via RLS. Use real orders from the orders table.

Why it works: One dashboard with status transitions and counts turns raw order rows into an operations tool a shop owner can actually run.

16. Customer accounts + order history

Add customer accounts using Supabase auth.

- Email/password sign-up and login, plus password reset. After login, show the customer's name in the header with a menu.
- /account page with tabs: Profile (name, email, saved shipping address), Orders (list from the orders table filtered to this customer, each opening its confirmation view), and Wishlist (migrate the localStorage wishlist to a per-user table on first login).
- Attach customer_id to new orders at checkout when the user is logged in; still allow guest checkout by email.

RLS: customers can read and update only their own profile, orders, and wishlist.

Why it works: The RLS rule scoping each customer to their own rows is stated explicitly, which is the core of a secure multi-user store.

17. Product reviews + ratings

Add product reviews.

- reviews table: id, product_id, customer_id, rating (1-5), title, body, created_at, status (published/pending).
- On the product detail page: show the average rating and count in the header, a reviews section with a rating breakdown bar and a paginated list, and a "Write a review" form available only to logged-in customers who have purchased that product.
- New reviews save as pending; add an /admin/reviews queue to publish or hide them.
- Recompute and cache each product's average rating when a review is published.

RLS: anyone reads published reviews; only the author writes their own; only admins moderate.

Why it works: Restricting reviews to verified purchasers and moderating before publish keeps ratings trustworthy and spam-free.

Convert, ship & grow

The store works; now make it convert and go live. These five prompts polish responsiveness, recover lost sales, and get you onto a real domain safely. For deeper structure, see how to prompt Lovable for full apps and the prompt cheat sheet.

18. Make the store fully responsive

Audit and fix responsiveness across the whole store on mobile, tablet, and desktop.

Check and correct: header nav collapses to a hamburger with the cart and search still reachable; product grids reflow (1/2/4 columns); the slide-out cart is full-width on mobile; filters collapse into a bottom sheet on the category page; forms and the checkout summary stack cleanly; tap targets are at least 44px; no horizontal scroll at 360px width.

Do not change colors, copy, or the backend. Only adjust layout and spacing. List each page you changed and what you fixed.

Why it works: The explicit "do not change colors, copy, or backend" fence keeps a layout pass from silently rewriting working logic.

19. Abandoned-cart reminder email

Add abandoned-cart recovery.

- When a logged-in customer (or a guest who entered their email) has cart items but no completed order after [N] hours, mark the cart as abandoned.
- A scheduled edge function sends one reminder email with the cart contents and a link that restores the cart and jumps to checkout. Send at most one reminder per cart.
- Optionally include a [PERCENT]% comeback coupon code (reuse the coupons table).
- Track sent/opened/recovered so I can see recovery rate in the admin.

Store emails and cart snapshots server-side; do not email anyone who has completed the order.

Why it works: Capping it at one email and excluding completed orders prevents the classic bug of spamming customers who already bought.

20. Related products / upsell section

Add upsell and cross-sell.

- On the product detail page, show a "Complete the look" / related-products row based on the same category (fall back to bestsellers if fewer than 4).
- In the slide-out cart and cart page, add a "Frequently bought together" strip suggesting up to 3 add-on products with one-tap "Add".
- On the order confirmation page, show a "You might also like" row to drive a follow-up purchase.

Keep suggestions server-driven from real product data and exclude items already in the cart. Do not slow the page down; lazy-load images.

Why it works: Excluding cart items and falling back to bestsellers stops the empty or repetitive rows that kill upsell placements.

21. Store analytics dashboard

Build a /admin/analytics dashboard from real order data.

- KPI cards: revenue, orders, average order value, and conversion (orders / sessions) for a selectable date range (today, 7 days, 30 days).
- Charts: revenue over time (line), orders by day (bar), and top 10 products by units and by revenue.
- A low-stock alert count and a pending-reviews count.
- Traffic-source breakdown if session data is available; otherwise leave a clear placeholder.

Compute metrics from the orders, variants, and products tables. Admin-only via RLS. Cache heavy queries so the page loads fast.

Why it works: Pointing metrics at the real order tables gives you an owner's dashboard rather than a vanity chart on fake data.

22. Security review + publish to a custom domain

Run a pre-launch security review, then help me go live.

Security checklist:
- Run Lovable's security scan and fix every finding.
- Confirm no secrets (Stripe keys, service keys) are in client code; all live in secrets/edge functions.
- Verify RLS on every table: products read-only public, orders/wishlist/reviews scoped to their owner, admin routes gated by the admin role.
- Confirm the stripe-webhook verifies signatures and that prices/discounts are re-read server-side.

Then walk me through: switching Stripe to live mode with live webhook keys, one-click publishing, and attaching my custom domain [yourstore.com]. Give me a final go-live checklist to confirm before I point the domain.

Why it works: Bundling the security scan, RLS review, and live-mode switch into the launch step catches the exact gaps that get e-commerce stores compromised.

Frequently Asked Questions

Can Lovable build an online store?

Yes. Lovable generates a full React + Tailwind storefront from plain English, and Lovable Cloud wires a native Supabase backend for products, carts, orders, and auth. Build the storefront UI first, then connect products, cart, and checkout to the backend.

How do I add payments with Stripe?

Ask Lovable to run Stripe checkout through an edge function with webhooks. Your Stripe secret and webhook signing keys live in Supabase secrets, never in client code. The client creates a checkout session server-side and the webhook marks the order paid.

Where are products stored?

In the Supabase Postgres database that Lovable Cloud provisions. You get products, variants, inventory, orders, and customer tables with row-level security. Storage holds product images and auth handles customer accounts.

How do I build an admin to manage products and orders?

Prompt Lovable for a protected admin route with product CRUD, inventory tracking, and an order dashboard. Gate it behind an admin role checked in RLS policies so only admins can read or write, and specify exactly which tables and fields the admin can edit.

Is checkout secure?

It is when payment logic runs server-side. Keep the Stripe secret in secrets, verify webhook signatures, and enforce RLS so customers only see their own orders. Run Lovable's built-in security scan before launch to flag exposed keys or weak RLS.

Can I connect a real domain and go live?

Yes. Lovable publishes in one click and lets you attach a custom domain. Run a security review first, confirm Stripe is in live mode with real webhook keys, and verify RLS on every table before you point your domain at the store.

Advertisement