Verified against Bolt.new · 2026-07-22
Build an e-commerce storefront with a real cart and a Stripe test checkout
A Bolt.new brief for a storefront where the cart total, tax, and one coupon code all compute from a single shared state, ending in a clearly labeled test-mode Stripe checkout or an explicitly-named mock fallback.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Build a storefront web app for Northgrove Coffee, selling bagged whole-bean coffee, using Bolt.new. This needs a real, working shopping cart with correct math — not a UI mockup where the numbers don't actually update. CATALOG 8 products: 4 single-origin bags ($16-$22) and 4 blends ($14-$18), each with a name, roast level, and one product photo Store the catalog as a static array or JSON file inside the project, not hardcoded duplicated inline inside multiple components — one source of truth the cart and product pages both read from. CART BEHAVIOR — THIS IS THE PART THAT HAS TO ACTUALLY WORK - Adding an item to the cart, adjusting its quantity, and removing it must all update a single shared cart state that persists across a page reload — use localStorage as the persistence layer, since Bolt.new has no database of its own to fall back on for this. - The cart total must recompute correctly every time: 8.25% tax applied after any discount, not before, and a running subtotal, discount line, tax line, and grand total all shown separately, not just a single final number. - Support one coupon code, FIRSTBAG10, which applies a 10% off the subtotal — show an inline error for an invalid code, and show the applied discount as its own line item, not folded silently into the item prices. - If bagged whole-bean coffee items have a quantity_available field, decrement it visually in the cart (never let the cart quantity stepper go above what's available) — but since there's no real backend, do not pretend this is a real inventory system; a comment in the code should note that this is a display-only stock limit, not enforced server-side. CHECKOUT - A checkout page collecting shipping details and showing the final order summary from the cart above. - Wire the "Pay" button to Stripe Checkout in TEST MODE ONLY, using a publishable test key — never a live key — and clearly label the page as a test-mode demo. If Stripe isn't connected, build the button to show a mock "Payment succeeded" confirmation screen instead, and say explicitly in your output which of the two you built. - On successful (or mock) payment, clear the cart from localStorage and show an order confirmation with the items and total that were just purchased, pulled from the state at time of purchase, not recomputed from the now-empty cart. CONSTRAINTS No user accounts or login — this is a guest-checkout-only storefront. warm cream background, deep brown accent, one large product photo per card Keep all state management in a single cart context or store so the header cart-count badge, the cart page, and the checkout page can never disagree about what's actually in the cart.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A "build a shopping cart" prompt with no shared-state instruction commonly produces a Bolt.new app where the header badge, the cart drawer, and the checkout page each hold their own copy of the cart array, updated inconsistently by whichever handler happens to fire first during generation. The badge says three items while the cart page shows two — a bug invisible in whatever single click-path the model happened to test against itself, and immediately visible to a real person clicking around in a different order. Naming a single shared cart context as a hard constraint is what prevents three independently-generated pieces of UI from drifting out of sync with each other. The tax-after-discount ordering closes a genuinely common arithmetic ambiguity: whether tax is computed on the pre-discount or post-discount subtotal changes the final total by a real amount, and a generated cart with no stated order will pick one silently and inconsistently if the coupon logic and the tax logic happen to get written in separate passes of the same build conversation — one path applying tax first, the other applying the discount first, producing two different totals for the identical cart depending on which code path executes. The test-mode-only, explicitly-branching Stripe instruction addresses Bolt.new's real constraint directly. Because it runs inside a StackBlitz WebContainer with no backend server of its own, a genuine Stripe integration needs a server endpoint to create a PaymentIntent while holding a secret key safely — something a pure-frontend WebContainer session structurally cannot do without an external server piece. Naming the test-key-only path, and requiring the model to state plainly which of the two branches — real Stripe test mode or a mock confirmation screen — it actually built, stops it from silently faking a "Payment succeeded" screen while implying a real integration exists underneath it, which is the single most common way a Bolt.new checkout demo ends up misleading whoever it's shown to next.
Verified against
Bolt.new Bolt.new web app (StackBlitz WebContainers) · 2026-07-22
Changelog
- 2026-07-22 — Initial publish, verified against Bolt.new with a single shared cart context and an explicit test-mode-vs-mock Stripe branch.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
