Help me plan and build [ECOMMERCE FEATURE OR SITE] using [TECH STACK]. The store sells [PRODUCT CATALOG], serves [TARGET CUSTOMERS], and must support [PAYMENT AND FULFILLMENT]. These are the design and business requirements: [REQUIREMENTS]. Existing code, APIs, or constraints are: [EXISTING CONTEXT]. Act as a senior ecommerce engineer. Start by identifying what should be handled by the storefront, backend, commerce platform, and payment provider. Do not invent API capabilities, security compliance, or production credentials. Ask up to 3 clarifying questions only if a required input is missing. Then produce: 1. A concise architecture and data model: products, variants, inventory, cart lines, orders, customers, addresses, taxes, discounts, and fulfillment status as applicable. 2. A user-flow checklist for browse, search/filter, product detail, cart, checkout, payment success/failure, order confirmation, returns or support routing. 3. An implementation plan ordered by dependency, including environment variables, server-side validation, webhooks, and tests. 4. Working code for the first requested feature, with filenames, setup instructions, and comments only where behavior is non-obvious. Keep secret keys server-side; calculate price, availability, tax, and discounts from trusted server data, never browser input. 5. Edge cases and tests: out-of-stock variants, stale cart prices, invalid promotions, duplicate payment events, failed payment, address validation, mobile layout, keyboard use, and accessible error messages. Before answering, self-check that the checkout path cannot trust client-supplied totals and that every external payment or inventory event is handled idempotently. Flag anything requiring legal, tax, accessibility, security, or platform-specific review.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [ECOMMERCE FEATURE OR SITE] | Describe the storefront or feature you want to build. | A product page and cart for a small coffee subscription store. |
| [TECH STACK] | Name the framework, language, hosting, commerce platform, and payment provider if chosen. | Next.js 15, TypeScript, PostgreSQL, Stripe Checkout, and Vercel. |
| [PRODUCT CATALOG] | Describe products, variants, pricing model, and inventory behavior. | Three coffee blends, each with 12 oz and 2 lb variants; one-time and monthly subscription purchases; inventory tracked by variant. |
| [TARGET CUSTOMERS] | Describe the intended customer group and locations served. | US consumers buying specialty coffee on mobile and desktop. |
| [PAYMENT AND FULFILLMENT] | State payment methods, currencies, shipping or delivery rules, and returns process. | USD cards and Apple Pay through Stripe; flat-rate US shipping; subscriptions ship monthly; returns handled by support email. |
| [REQUIREMENTS] | List required pages, interactions, branding rules, integrations, and success criteria. | Product detail with variant picker, cart drawer, subscription choice, promo code display, accessible form errors, and order confirmation email. |
| [EXISTING CONTEXT] | Provide relevant repository structure, APIs, constraints, or code snippets. | New repository with Next.js App Router; Stripe account exists but no environment variables are committed. |
How to use
- Paste the prompt with your real platform constraints and attach the relevant files when requesting code changes.
- Build payment and order creation behind a test-mode provider before designing the final checkout styling.
- Test a sold-out variant, a declined payment, a repeated webhook, and a changed price in a separate browser session.
- Follow up with: “Write the tests for the cart and webhook behavior you proposed, using the test framework already in this repository.”
Variations
Product page
Use this to build or improve a product-detail page before checkout work.
Build a product-detail page for [PRODUCT] in [TECH STACK]. The variants are [VARIANTS], inventory source is [INVENTORY SOURCE], and required content is [CONTENT REQUIREMENTS]. Produce component code, server data fetching, variant-selection behavior, structured product data if appropriate, and accessible loading/error states. The add-to-cart action must use the selected variant ID and current server-authoritative price. Cover unavailable combinations, low-stock messaging rules, image alt text, keyboard selection, and mobile layout. Do not claim inventory is reserved unless the supplied system supports it.
Checkout integration
Use this when you need a secure payment flow with an existing storefront.
Design and implement [PAYMENT PROVIDER] checkout for [STORE CONTEXT] using [TECH STACK]. Existing cart and order models are [DATA MODEL]. Give server routes, environment variables, webhook verification, idempotency strategy, order state transitions, and test-mode setup. Explain how the server recalculates line prices, shipping, taxes, and discounts before creating a payment session. Include handling for abandoned checkout, declined payment, duplicate webhooks, and delayed events. Do not expose secret keys or mark an order paid from a client redirect alone.
Store requirements
Use this before coding a larger commerce site or platform migration.
Turn these ecommerce requirements into a technical specification: [REQUIREMENTS]. The business sells [PRODUCTS] to [CUSTOMERS], using [CURRENT PLATFORM OR STACK]. Produce prioritized user stories, nonfunctional requirements, data entities, integration boundaries, acceptance criteria, analytics events, and launch risks. Include browsing, search, variants, inventory, cart, checkout, confirmation, customer support, and fulfillment as relevant. Separate must-haves from later enhancements. Identify choices that require input from payments, tax, privacy, accessibility, or operations specialists rather than guessing.
Tips
- Use the payment provider’s signed webhook as the source of truth for paid status; the browser return page is only a confirmation experience.
- Store a snapshot of the purchased item name, price, tax, and shipping on the order, because catalog details can change after a sale.
- Validate promotions and inventory again on the server immediately before payment creation, even if the cart was validated earlier.
- Design error states before launch: customers need a recovery path for expired carts, failed payments, unavailable stock, and duplicate clicks.
FAQ
Can AI build an entire ecommerce store from one prompt?
It can generate a starting implementation, but production stores need tested integrations, real content, security review, tax decisions, and operational setup.
Can I calculate order totals in the browser?
Use browser calculations for display only. The server must recompute authoritative totals from trusted product, promotion, shipping, and tax data.
What ecommerce tests matter most before launch?
Test variant availability, cart persistence, checkout failure and success, webhook retries, order confirmation, mobile behavior, keyboard navigation, and transactional email delivery.