Bolt.new Ecommerce Store: The Full Prompt Template (2026)

The Short Answer

• Use Bolt.new alone if you want to ship a single landing page with a buy button, you have fewer than ten products, and you're fine wiring Stripe yourself. The free or $25/mo Pro plan covers it.
• Use Bolt.new + Supabase + Stripe if you want a small custom store with a real database and you are comfortable owning the schema, the auth, the webhooks, and every edge case around inventory and refunds. Realistic time to live: a weekend if you know what you're doing, a week if you don't.
• Use Your Next Store if "describe what you want and have a working store with admin, products, cart, checkout, and tax" is the actual job. The AI builds the storefront; the commerce backend is already there.

The rest of this post is the prompt template, the failure modes, and the line that separates "Bolt is enough" from "you need an actual ecommerce platform."

What Bolt.new Actually Is (and Isn't)

Bolt.new is a chat-based AI builder by StackBlitz. You describe an app in a text box, an agent generates a Vite + React + TypeScript codebase in your browser, and you can preview, edit, deploy, and push to GitHub from the same interface. The platform also has its own built-in database and hosting (Bolt Cloud), so you can ship without leaving the tab.

What it isn't: a commerce engine. There is no product catalog, no cart, no checkout, no tax engine, no fulfillment, no inventory. There is no Shopify integration the way Lovable has one. Bolt.new will gladly write code that calls Stripe, queries Supabase, or fetches from the Shopify Storefront API, but the commerce primitives belong to whatever service you wire it up to.

That distinction matters because the difference between a Bolt.new "ecommerce store" that works for ten orders and one that works for ten thousand is entirely about what's underneath the UI. The prompt is the easy part. The backend is the actual business.

Quick Comparison

Three honest paths to a live store you can describe in a chat box. Pick by where you want the work to land.

Native Shopify themes, Hydrogen, and a hand-rolled Next.js stack are legitimate fourth, fifth, and sixth options. They are out of scope here because none of them are describe-it-in-a-chat-box, which is the job Bolt.new is competing for.

The Full Prompt Template

What follows is a five-prompt sequence that consistently produces a working storefront on Bolt.new. Each prompt is meant to be sent in order, in a fresh project. Edit the bolded fields before you paste; everything else is load-bearing and worth leaving as written.

Prompt 1: The scaffold

Build me an ecommerce storefront for a brand called **[BRAND NAME]**.

The brand sells **[ONE-SENTENCE PRODUCT DESCRIPTION]**.
The voice is **[minimalist / playful / luxury / earthy]**.
Primary color: **[#HEX]**. Accent: **[#HEX]**. Font: **[Inter / Geist / Playfair]**.

Pages I need:
- Homepage with a full-bleed hero, a featured collection of 6 products, an
  "About" section with one image, and a footer with social links and an
  email signup.
- /shop product listing with filter chips for category and price.
- /product/[slug] product detail with sticky image gallery on the left,
  details and an add-to-cart button on the right, related products below.
- /cart with line items, a quantity stepper, and a "Checkout" button.
- /checkout/success and /checkout/cancel.

Stack: Vite + React + TypeScript + Tailwind. Use Lucide icons. Mobile-first.
Don't add a backend yet. Use a hard-coded products.ts with 8 mock products
including image, name, price in cents, description, and slug. I'll wire
the real backend next.

This prompt produces a clean static storefront in roughly 90 seconds. Resist the urge to keep iterating on the design here. Move to Prompt 2 first; layout changes are cheaper to make once the backend is wired than the other way around.

Prompt 2: Stripe Checkout

Add Stripe Checkout to this project.

Use the official @stripe/stripe-js package on the frontend and a serverless
function for creating checkout sessions. Don't store card details. Don't
build a custom payment form. Use Stripe-hosted Checkout.

Flow:
- Cart "Checkout" button calls /api/create-checkout-session with the cart
  line items.
- The function creates a Stripe Checkout Session with line_items derived
  from the cart, and a success/cancel URL pointing at /checkout/success
  and /checkout/cancel.
- Redirect the browser to the returned session URL.
- After redirect to /checkout/success, show a confirmation message and
  empty the cart from local storage.

Use environment variables STRIPE_SECRET_KEY (server) and
VITE_STRIPE_PUBLISHABLE_KEY (client). Don't hard-code keys.

Add a webhook handler at /api/stripe-webhook that listens for
checkout.session.completed and logs the order. I'll replace the log with
a real persistence layer next.

This is the prompt that turns a static demo into a real store. The output is a working test-mode checkout: you can charge a real card, the webhook fires, and the cart-to-payment loop is closed. Most teams hit this milestone in well under thirty minutes.

Prompt 3: Real products with Supabase

Replace the hard-coded products.ts with a Supabase database.

Tables:
- products(id uuid pk, slug text unique, name text, description text,
  price_cents int, image_url text, category text, inventory int,
  created_at timestamp).
- orders(id uuid pk, stripe_session_id text unique, total_cents int,
  email text, status text, created_at timestamp).
- order_items(order_id uuid fk, product_id uuid fk, quantity int,
  price_cents int).

Generate row-level security policies that allow anonymous read on products
and write only via the service role key for orders. Use @supabase/supabase-js
on the frontend with the anon key and on the server with the service role.

In the Stripe webhook, after checkout.session.completed:
- Create an orders row with stripe_session_id, total_cents, email, status='paid'.
- For each line item, decrement products.inventory by quantity in a single
  transaction. If any product has insufficient inventory, mark the order
  status='oversold' and log it.

The race-condition language in the last paragraph is intentional. Without it the agent will write the inventory decrement as a non-atomic read-then-write, which is fine for a demo and a disaster on Black Friday.

Prompt 4: The admin you'll regret skipping

Build a minimal admin at /admin protected by a hard-coded password
in an environment variable ADMIN_PASSWORD.

Pages:
- /admin/products: table of all products with a "New product" button
  and inline edit for name, price, inventory, image_url.
- /admin/orders: table of orders with status, email, total, and a
  "View" link to the Stripe dashboard.
- /admin/settings: form with the brand name, primary color, and footer
  text. Save to a settings table or a single JSON document.

This is intentionally minimal. Don't build user management, roles, or
audit logs. I just need to add a product without redeploying.

Skip this prompt and you will redeploy every time inventory changes. We have watched this movie. It does not end well.

Prompt 5: Polish

Polish the storefront:
- Add Open Graph and Twitter card meta tags on every page using the page
  title, a description, and the first product image as og:image.
- Add structured data (JSON-LD) on the product detail page using
  schema.org/Product with name, description, image, sku, price, and
  availability.
- Add a /sitemap.xml dynamically generated from the products table.
- Add a /robots.txt that allows everything.
- Lazy-load product images below the fold.
- Cache the products list with stale-while-revalidate for 60 seconds.

This is the prompt that decides whether your store gets indexed. Bolt.new's default output is a single-page React app where the initial HTML is empty until the JavaScript runs. Most AI crawlers (ChatGPT, Claude, Perplexity) don't execute JavaScript at all, and even Googlebot indexes JS-rendered content slower than HTML-rendered content. The structured data and meta tags help, but they don't replace server-side rendering. If organic traffic is part of your plan, this is the limit Bolt.new can take you to.

Where the Bolt.new Stack Breaks

Across the hands-on reviews we've read and the teams we've talked to, the same five pressure points come up. Worth knowing before you commit a launch to it.

Client-side rendering versus SEO. Bolt.new generates Vite + React, which means a near-empty HTML shell ships to the browser and crawlers. Meta tags and OG cards work because the agent can put them in the initial HTML. Product names, descriptions, prices, and JSON-LD all render after JavaScript executes. For an Instagram-driven brand it's fine. For a store that depends on Google or AI search, it's a structural ceiling. Hosting the same code on Next.js or Vercel with server-rendered routes solves this, but that means leaving Bolt.new's hosted preview behind. The same constraint applies to Lovable, see our Lovable Shopify integration deep dive for the full version of this argument.

The database is the boss fight. Prompt 3 above looks like five lines of work. In practice, the moment you have real orders, the model needs to know about: idempotent webhook handling (Stripe retries on 5xx), atomic inventory writes (the product is reserved between cart-add and checkout-complete), fraud holds, partial refunds that restock inventory, oversold orders, currency rounding, tax calculation that respects nexus, and shipping rules that are not "flat $5." Each of those is a multi-hour conversation with the agent, and at least one of them will surprise you in production. This isn't a Bolt.new problem. It's a "you are now a commerce platform" problem.

The admin is fragile. Prompt 4 produces an admin that works for one person typing carefully. The minute a second team member needs to update inventory, you need real auth, roles, audit logs, and a recovery path if someone deletes a product. Prompting your way through that is possible. It is also where most Bolt-built stores stop being maintainable, because every change to the schema means re-prompting every screen that touches the schema.

Loss of context on long projects. Bolt.new and every other AI app builder share this failure mode: after a few dozen edits the agent starts forgetting earlier instructions, looping on the same fix, and occasionally regressing features it shipped two prompts ago. Independent reviewers of Lovable document the same pattern. The first build is fast. The fortieth is a battle. For a static landing page this is academic. For a store you maintain for a year, it's the actual reason these builds eventually need a rewrite or a platform behind them.

Lock-in to Bolt Cloud (or a manual migration). You own the generated code and can push it to GitHub at any time. You also lose Bolt's built-in hosting, database, and deployment if you move it. Self-hosting on Vercel + Supabase + your own Stripe keys is doable, takes most teams half a day, and removes Bolt.new from the runtime path. The product data stays portable because Stripe and Supabase are the system of record.

None of this is a reason to skip Bolt.new. The first hour of using it is the kind of leverage that makes other tools feel slow. It is a reason to know which problems it doesn't solve before you bet a launch date on it.

What It Costs

For a Bolt.new + Supabase + Stripe stack:

Bolt.new. Free covers about 1M tokens a month, which is enough for a few short projects but not for sustained iteration. Pro is $25/mo and bumps you to 10M tokens monthly with no daily cap. Tokens roll over for one extra month on paid plans. Token usage scales with project size, so a mature store eats more tokens per edit than a fresh project.

Supabase. Free tier covers 500MB database and 50K monthly active users, which is plenty for a starter store. Pro is $25/mo and unlocks point-in-time recovery, larger databases, and email support.

Stripe. No subscription, but standard processing fees apply: 2.9% + $0.30 per successful card charge in the US, with international and currency conversion fees on top.

Floor: roughly $25-50/mo before card processing, depending on whether you stay on the Supabase free tier. Cheaper than Shopify Basic at $29/mo, more expensive than a one-page static landing page with a Stripe Payment Link. Where it sits on the cost curve depends entirely on whether the value you get from the AI offsets the time cost of being your own commerce platform.

Who This Stack Is For (and Who It Isn't)

The sweet spot is a founder who wants a custom-looking storefront with under fifty products, can describe what they want clearly, and has either some development background or a high tolerance for living with whatever the agent ships. Drops, capsule collections, creator merch, side-project commerce, MVPs that need to look better than a Stripe Payment Link. Bolt.new will get you there in an afternoon, and the result will look like the kind of brand whose founder cares about design.

It is the wrong fit when:

1. You need a real admin from day one. Multi-user editing, roles, audit logs, and recovery from mistakes are not what an AI app builder ships well. They're what a commerce platform exists to provide.
2. Organic traffic is your acquisition channel. Client-side rendering is a real ceiling for SEO and an absolute one for AI search. You'll either re-platform later or ship a parallel server-rendered version.
3. You expect the catalog to grow past a hundred products. Inventory, pricing rules, variants, translations, and merchandising stop being a manageable schema and start being the business. That's the moment a generic database becomes a liability instead of an asset.
4. You don't want to learn what idempotency means. That's not a criticism, it's a question of where you want to spend your time. Some founders want to talk to customers and find product-market fit. Some founders want to debug a webhook retry loop on a Friday night.

The fourth case is the one this post exists to flag.

The Alternative: An AI That Already Owns the Backend

The Bolt.new + Stripe + Supabase stack is an app builder on top of a commerce backend you assemble yourself. That's a legitimate split, and for the right project it's the right one. It's also why you're spending Friday nights on webhook retries.

Your Next Store takes the opposite position. The AI builder, the product catalog, the admin dashboard, the cart, the inventory, the orders, the refunds, the tax rules, and the storefront template are one system. When you ask the AI to add a quiz, a size guide, a countdown, or a new product line, it edits a Next.js storefront that already knows about your products, your inventory, your customers, and your Stripe account. Webhooks are wired. Refunds restock inventory. Inventory writes are atomic. The admin is built. None of that is a prompt. It's the platform.

The trade is honest:

• You give up: the chat-with-an-agent-and-also-build-a-Slack-clone generality. YNS only builds stores. Bolt.new builds anything.
• You get: a working store that survives ten thousand orders without a rewrite, an admin your operations person can use, server-rendered HTML that actually ranks, and one bill instead of three.

When you outgrow the platform, the storefront is an open-source Next.js template you can fork and host yourself. The data exits via REST API. The escape hatch is real. That's the part most managed platforms don't ship.

Plans start at $30/mo with 0% transaction fees on every tier. You see the AI builder before you pay; cancel from the dashboard with no support email required.

The Honest Thing to Say About Bolt.new and Ecommerce

Bolt.new is one of the best general-purpose AI app builders shipping today, and it can build an ecommerce store. What it can't do, by design, is be an ecommerce platform. If you want to ship a small custom store and you have the engineering instinct to know when an inventory write is racing, Bolt.new is a leverage tool you should be using. If you want a real store with a real admin and you don't want to spend six months becoming a part-time commerce platform engineer, you want a stack where the AI and the commerce backend are the same product. Two different tools. Two different jobs. The prompt template above is for the first one. The second one starts with a different chat box.

FAQ

Can Bolt.new build a complete ecommerce store?

It can build a working storefront with cart and Stripe Checkout in about thirty minutes. "Complete" depends on what you mean: a store you can take orders on, yes. A store with admin, inventory, refunds, tax, shipping rules, and SEO that ranks, only if you keep prompting and own each of those problems yourself. Bolt.new generates the UI; the commerce primitives belong to whatever you wire it to.

Does Bolt.new have a Shopify integration like Lovable?

No. Lovable has an official Shopify integration that connects a generated React storefront to a Shopify backend. Bolt.new does not, as of April 2026. You can prompt Bolt.new to call the Shopify Storefront API yourself, but you write the wiring; nothing about that flow is a one-click setup.

What's the best prompt for a Bolt.new ecommerce store?

The five-prompt template above. The two non-negotiable parts are Prompt 2 (Stripe Checkout, hosted, with a webhook handler) and Prompt 3's specific language about atomic inventory writes inside a transaction. Without those, you ship a demo. With those, you ship a store.

How much does it cost to run a Bolt.new ecommerce store?

Floor is around $25-50/mo for Bolt Pro and Supabase Pro, plus Stripe's standard 2.9% + $0.30 per transaction. Add a custom domain ($10-15/year) and a transactional email service ($0-20/mo) once you start sending order confirmations. The cost is competitive; the time cost depends on how comfortable you are owning every commerce edge case yourself.

When should I use a real ecommerce platform instead?

When the catalog passes about fifty products, when you need a multi-user admin, when organic traffic is part of the plan, or when you've spent more than two hours debugging a webhook. The line is roughly "the moment commerce stops being a feature you're prompting and starts being the business you're running." For a comparison of platforms purpose-built for that job, see our guide to AI store builders.

Is the Bolt.new generated code portable?

Yes. You can push the project to GitHub and self-host on Vercel, Netlify, or your own infrastructure. You'll lose Bolt.new's preview, hosted database, and integrated deploy, and you'll need to wire your own Supabase and Stripe environment variables. Most teams who hit Bolt.new's ceilings make this move before they re-platform.

Related Blog Posts

• Lovable Shopify Integration: How It Works in 2026 — the closest comparison: AI builder + an actual commerce backend
• Best AI Store Builders in 2026 — Bolt.new, Lovable, YNS, Shopify Magic, and seven others compared
• AI Ecommerce: The Two Revolutions Nobody's Connecting — why AI changes both how stores are built and how they are shopped
• What Is Headless Commerce? — the architecture every "AI builder + Shopify/Supabase" stack is actually using
• Shopify Transaction Fees, Explained — what the alternative to a Bolt.new + Stripe stack actually charges
• How to Start an Online Store in 2026 — the broader strategic guide for first-time founders
• How Is Your Next Store So Fast? — why server-rendered storefronts beat client-rendered ones for ecommerce SEO