Bolt prompt to build an e-commerce store
This spec makes Bolt treat money carefully without pretending the store is production ready: prices are integer cents in Supabase, and the cart stores ids and quantities only, so /cart recomputes subtotals from freshly fetched product rows instead of trusting localStorage. You get a seeded browsable catalog, a refresh-proof cart, and a checkout that writes orders in a single RPC and stops at the payment TODO.
Last updated
Build a small e-commerce store for selling {{resource}} in this Bolt project: Vite + React + Tailwind, Supabase for the catalog, cart kept client-side.
Data, as Supabase migrations with seed data:
- products: id, name, slug, description, price_cents, currency, image_url, stock, active.
- orders: id, email, total_cents, status, created_at, plus order_items with product_id, qty, unit_price_cents.
Seed 8 products so the preview is browsable immediately.
Screens:
- / : product grid with image, name, price, and a sold-out overlay when stock is 0.
- /product/:slug : gallery placeholder, quantity stepper capped at available stock, Add to cart.
- /cart : line items with qty editing and removal, subtotal recomputed from freshly fetched product rows, never from values stored in the cart itself.
- /checkout : email and shipping form with inline validation, and a Place order button that writes the order and its items to Supabase in one RPC call, then shows a confirmation with the order id. Payment is a stub marked TODO, do not fake a card form.
Cart rules: persists in localStorage under cart_v1, merges duplicate lines, and drops items whose product went inactive while telling the user which ones were removed.
Empty and error states: an empty grid says the store has no products yet, the empty cart links back to the grid, and a failed order write keeps the form filled and shows a retry banner.
Money: always integer cents, formatted at render, no floating point arithmetic anywhere.
Acceptance: add two items, refresh the preview and confirm the cart survives, place an order, then open Supabase's table view and find the order row with its items.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Build a small e-commerce store for selling users in this Bolt project: Vite + React + Tailwind, Supabase for the catalog, cart kept client-side. Data, as Supabase migrations with seed data: - products: id, name, slug, description, price_cents, currency, image_url, stock, active. - orders: id, email, total_cents, status, created_at, plus order_items with product_id, qty, unit_price_cents. Seed 8 products so the preview is browsable immediately. Screens: - / : product grid with image, name, price, and a sold-out overlay when stock is 0. - /product/:slug : gallery placeholder, quantity stepper capped at available stock, Add to cart. - /cart : line items with qty editing and removal, subtotal recomputed from freshly fetched product rows, never from values stored in the cart itself. - /checkout : email and shipping form with inline validation, and a Place order button that writes the order and its items to Supabase in one RPC call, then shows a confirmation with the order id. Payment is a stub marked TODO, do not fake a card form. Cart rules: persists in localStorage under cart_v1, merges duplicate lines, and drops items whose product went inactive while telling the user which ones were removed. Empty and error states: an empty grid says the store has no products yet, the empty cart links back to the grid, and a failed order write keeps the form filled and shows a retry banner. Money: always integer cents, formatted at render, no floating point arithmetic anywhere. Acceptance: add two items, refresh the preview and confirm the cart survives, place an order, then open Supabase's table view and find the order row with its items.
Same task in other tools
Questions about this prompt
Why does the cart store ids and quantities but never prices?
A price kept in localStorage is a price the user can edit. The cart holds references only, and the subtotal recomputes from fresh product rows whenever the cart page renders, so a price change in Supabase, or a tampered localStorage entry, can never produce a wrong total.
Where does payment fit when I am ready?
The checkout writes the order first with a pending-style status, which is the right seam. Add your payment provider behind a server route that confirms the order on success, and use the provider's hosted fields rather than building a card form into the page. Ask Bolt for that route as a separate follow-up.
Two tabs both bought the last item in stock and both orders succeeded. Why?
The stock check only ran in the UI. Move the decrement into the same Supabase RPC that writes the order, guarded by a condition that stock covers the quantity, and treat zero affected rows as out of stock. The single-RPC checkout exists so this race has exactly one place to fix.