Build and Deploy an Online Store With Claude Code

Plan the Online Store

Open your project in Claude Code, fill in the three fields, and use this prompt. It only plans — nothing is built yet.

Plan the Online Store

Tell Claude what you sell, what each product should show and how customers will receive their orders before anything is built.

I want to build a focused online store for physical products using Claude Code. Store: {{STORE_TYPE}} Product information: {{PRODUCT_INFORMATION}} Fulfillment: {{FULFILLMENT}} Do NOT build anything yet. First inspect the existing project. If this is an existing website, preserve the correct stack, design system and working functionality. If this is a new project, plan the smallest appropriate full-stack implementation. 1. CUSTOMER WORKFLOW Plan this exact path: 1. The customer opens the store 2. Browses published products 3. Opens a product 4. Adds the product to the cart 5. Changes quantities 6. Reviews the cart 7. Starts checkout 8. Pays in Stripe Checkout 9. The application receives a verified Stripe payment event 10. The paid order becomes visible to the merchant Customers do not create accounts. Use guest checkout. 2. MERCHANT WORKFLOW Plan this exact path: 1. The merchant signs in 2. Opens the Store Dashboard 3. Creates and edits products 4. Uploads product images 5. Publishes products 6. Marks products available or unavailable 7. Sees paid orders 8. Opens an order 9. Moves fulfillment: Paid → Processing → Fulfilled The merchant must NOT manage normal store operations through the Supabase dashboard. The Store Dashboard is the operational interface. 3. DATA MODEL Plan the smallest useful model. The likely concepts are a PRODUCT, an ORDER, an ORDER ITEM and AUTHORIZED STORE STAFF. Do not create customer-account tables. 4. PRICE AUTHORITY — CRITICAL The browser and the cart display are NOT authoritative for prices. The customer may send a product id and a quantity, but must never be able to authoritatively send price = 0.01, a subtotal, a total, a currency or a paid state. The trusted checkout path must retrieve current prices from the trusted product data. 5. ORDER SNAPSHOT Changing a product's price tomorrow must NOT change yesterday's paid order. Snapshot the product name, the quantity, the unit price and the line amount where needed, and keep the product relationship where it is useful. 6. STOCK Do not plan quantity-based inventory. A product is simply AVAILABLE or UNAVAILABLE, and the merchant can change that from the Store Dashboard. 7. EXCLUDED FROM VERSION 1 Do not plan: customer accounts, a customer dashboard, wishlists, reviews, ratings, coupons, promo codes, product variants, size or colour options, stock quantities, stock reservation, suppliers, purchase orders, a multi-vendor marketplace, multiple currencies, subscription products, digital downloads, abandoned-cart or transactional email, SMS, a loyalty program, product recommendations, an AI shopping assistant, a returns portal, refund automation, shipping carrier APIs, live shipping rates, a tax engine, advanced analytics or an affiliate system. Return: ONLINE STORE PLAN Public pages: Merchant pages: Product fields: Cart model: Fulfillment model: Payment flow: Order model: Order statuses: Product image model: Merchant authentication: Authorization: Features deliberately excluded: Then return exactly one: READY TO BUILD or: NEEDS A DECISION Do not modify anything yet.

What does this store sell?

Coffee products, handmade candles, clothing accessories, home decor...

What information should each product show?

Name, description, price, images, materials, dimensions...

How will customers receive their order?

Review the plan before continuing. Keep version 1 focused on products, checkout and paid-order fulfillment.

Confirm the MVP

Make sure the approved plan includes exactly this:

Product catalog

Product detail

Cart

Stripe Checkout

Verified paid order

Protected Store Dashboard

Product management

Order fulfillment

No unnecessary ecommerce features

This is a small custom store, not a Shopify replacement. It also does not change the tax, legal or operational responsibilities of running a real shop.

Create or Reuse Supabase

If this project already uses the correct Supabase project, reuse it — do not create a second backend. If Supabase is missing, create the project first:

Open Supabase

Create the project, or open the one this store should use.

https://supabase.link/r4gdwhi

The browser side of the store needs only the Project URL and the Publishable key, under the environment-variable names this project already uses.

IMPORTANT

The Supabase Secret key and the service-role key are server-side values only. Never put either one in browser code or in the repository.

Add a Database to Any AI-Built Website or Web App With Supabase

Use this if this is your first Supabase project.

/video/add-a-database-to-any-ai-built-website-or-web-app-with-supabase

Create the Store Data

Now create the products, orders and merchant access the approved plan needs.

Create the Store Database

Create the smallest Supabase structure for products, paid orders and protected merchant management.

Using the approved online-store plan, create the minimum database, Storage and authorization this store requires. Reuse correct existing authentication and admin structures where possible. Do not duplicate an existing backend, and never print secret values. 1. PRODUCTS Create the product model using only the approved fields. Typical fields where useful: id, name, slug, description, price, available, published, a primary image or image relationship, created_at and updated_at. Do not automatically add every ecommerce field you can think of. 2. MONEY Use a money representation that is correct for Stripe and consistent with this project's architecture. Do not use floating-point arithmetic that can produce rounding errors. Keep one currency for this MVP and do not add currency conversion. 3. PUBLIC PRODUCTS Public visitors may read only PUBLISHED and AVAILABLE product data that is intended to be public. A draft or unpublished product must not be readable just because the frontend filters it out of a list. 4. PRODUCT IMAGES Use Supabase Storage where product images need uploading. Public product images may be publicly readable where that is appropriate, but only authorized merchant staff may upload, replace or remove product media. Never give anonymous visitors Storage write access. 5. ORDERS Create the smallest order structure needed. Store trusted information such as the Stripe checkout or payment relationship, the customer and fulfillment information the approved workflow actually needs, the payment state, the fulfillment state, the totals and the created time. Do not store card information. 6. ORDER ITEMS Preserve an order-item snapshot: the product reference, the product name at purchase time, the quantity, the unit price at purchase time and the line total where useful. Changing or deleting a product later must not rewrite a historic paid order. 7. MERCHANT AUTHORIZATION Use proper staff or admin authorization. Signed in is NOT the same as store staff. Store staff status somewhere a signed-in user cannot change about themselves, and check it in the database rules. Do not rely on hidden dashboard navigation, localStorage, frontend role state or client-editable metadata. Tell me how to grant the FIRST merchant account safely — for example one reviewed SQL statement run once in the Supabase SQL Editor — never through self-service sign-up. 8. ROW LEVEL SECURITY Enable Row Level Security on every table. Public reads expose only the product data intended to be public. Orders are not publicly readable at all, and no browser role may change a fulfillment state. Do not use a broad USING (true) for private or merchant operations, and do not disable RLS to make something work. Give me: 1. Existing structures reused 2. Tables created 3. The product model 4. The product publication model 5. The product-image Storage model 6. The order model 7. The order-item snapshot model 8. Merchant authorization 9. The public access model 10. ONE reviewed SQL / migration block where appropriate 11. The Storage setup 12. Any blocker Do not use destructive DROP statements. If a table with the same name already exists, warn me instead of replacing it. Do not execute destructive database changes automatically, and do not build the UI yet.

Review the SQL before you run it in the Supabase SQL Editor, and grant your first merchant account the way the answer describes.

Build the Storefront

Build the public catalog and the product page on top of the real product data.

Build the Online Store

Build the public product catalog and reusable product pages using real Supabase data.

Build the approved public store using the Supabase product data we just created. Reuse the project's existing design system and components. Do not redesign unrelated pages. 1. PRODUCT CATALOG Load real published and available products from Supabase. Show useful card information such as the image, the name, the price and a short description where it helps. Do not hardcode demo product arrays once Supabase is connected. 2. PRODUCT PAGE Use ONE reusable dynamic product page. Show the approved images, title, price, description, product information, availability and an Add to Cart action. A draft or unpublished product must stay private — do not render it from a direct URL. 3. ROUTES Use clean product slugs or routes where appropriate, and make sure refreshing a direct product route works in production rather than only in local development. Do not turn this into a full ecommerce SEO project. 4. RESPONSIVE Product browsing and the product page must work well on a phone. When finished, report: - the public routes and components - how published and available products are loaded - how a draft product is kept private - the product-page structure

Add two or three test products from the Supabase table for now. The merchant will create real ones from the Store Dashboard in step 5.

Build the Cart

Let customers collect products and review the order before paying.

Add the Shopping Cart

Let customers add products, change quantities and review the order before starting secure checkout.

Build a simple shopping cart for this store. Allow the customer to add a product, increase the quantity, decrease the quantity, remove an item, clear the cart where that is useful, and see a subtotal. Cart state may be kept client-side, because it is temporary interface state. 1. THE CART IS NOT THE PRICE AUTHORITY The displayed subtotal is a convenience for the customer. It never decides what anyone is charged. The trusted checkout path built in the next step is what determines the real amount. 2. AVAILABILITY If a merchant marks a product unavailable, prevent new adds in the interface AND make sure the trusted checkout path rejects it too. A customer may still be holding a stale cart from before the change, so a disabled Add to Cart button is not enough on its own. 3. QUANTITY Use simple positive integer quantities. Do not add stock limits — quantity-based inventory is deliberately outside this store. 4. CHECKOUT Add one clear Checkout action. Do not collect raw card details anywhere in the app; Stripe Checkout handles payment entry. When finished, report: - where cart state lives - the cart operations you added - how an unavailable product is handled in the interface - what the Checkout action currently does

The cart is convenience, not accounting. The amount the customer is actually charged is decided by the trusted checkout path in the next section.

Add Secure Checkout

Create the Checkout session on a trusted path, from prices the browser cannot touch.

Add Stripe Checkout

Create Stripe Checkout from trusted product data so customers cannot change prices from the browser.

Add one-time Stripe Checkout to this store, reusing the secure Stripe patterns this project already uses. 1. THE CHECKOUT REQUEST The browser may send product identifiers, quantities and the approved fulfillment selection where that is relevant. The browser must NOT authoritatively send a unit price, a subtotal, a total, a currency or a paid state. Ignore any such values if they arrive. 2. THE TRUSTED CHECKOUT PATH On the trusted server-side path: 1. Validate the requested products 2. Verify each one is still published and available 3. Load the authoritative product prices from the trusted product data 4. Validate the quantities 5. Build the Stripe Checkout line items from those authoritative values 6. Attach enough trusted metadata or a reference to reconcile the final order later 7. Return the Checkout session safely 3. STRIPE KEYS Never expose the Stripe Secret key in browser code. Use this project's real environment-variable naming conventions rather than inventing names. 4. FULFILLMENT INFORMATION For shipping, configure Stripe Checkout to collect only the customer and address information the approved plan requires, using the current supported Stripe approach. Do not build a shipping carrier integration. For local pickup, do not request an unnecessary shipping address. If the approved plan supports both, keep the implementation simple and do not create two separate applications. 5. SHIPPING COST Do not build a carrier-calculated shipping engine. If the approved MVP needs a shipping cost, use the simplest legitimate Stripe-supported fixed or configured shipping option. Do not calculate real carrier pricing yourself. 6. TAX Do not invent tax rules and do not hardcode a tax percentage. If this store needs to collect tax on real sales, that is done through Stripe's current supported tax configuration and the merchant's own business setup — not by a number written into the code. 7. TEST MODE Implement and verify this in Stripe Test Mode. Real transactions are not required to complete this build. When finished, report: - the trusted checkout path and where it runs - exactly what the browser sends and what is ignored - how authoritative prices are loaded - how unavailable products are rejected - the metadata attached for reconciliation - the environment variable names used - any blocker

IMPORTANT

The Stripe Secret key never reaches browser code. The browser may send product ids and quantities — never a price, a total or a currency.

Protect API Keys Before Deploying an AI-Built Website or Web App

Use this if you are unsure whether a key is exposed.

/video/protect-api-keys-before-deploying-ai-built-app

Confirm Payment With a Webhook

Create the paid order from Stripe's verified event, not from the page the customer lands on.

Add Verified Order Creation

Create paid orders only from verified Stripe events instead of trusting the checkout success page.

Complete the store's payment flow using the established secure Stripe webhook pattern. 1. CRITICAL RULE Do NOT use the success page, or the fact that Checkout returned successfully, as authoritative proof of payment. The customer may close the browser, the redirect can be replayed, and the page is only interface. Stripe's verified event is the payment authority. 2. WEBHOOK Verify the Stripe webhook signature before anything else happens, reading the raw request body first. Handle the relevant successful Checkout or payment event using the current supported pattern. If the signature is invalid, reject the request and do nothing else. 3. ORDER CREATION After a verified successful payment, create or finalize the trusted order using the checkout reference attached earlier. Store the trusted totals, the Stripe identifiers needed for reconciliation, the approved customer and fulfillment information, the order-item snapshots, the payment state and the initial fulfillment state. The initial merchant fulfillment state is PAID, or the closest clear convention this project already uses. Re-read the authoritative session and line items from Stripe rather than trusting a copy in the request body. 4. IDEMPOTENCY Stripe retries and replays events. The same successful payment or Checkout session must never create a second order — key order creation on a unique Stripe identifier so a retry does nothing. 5. FAILED AND ABANDONED CHECKOUT Creating a Checkout session is not a sale. An abandoned or failed payment must never appear as a paid order. 6. TEST MODE Verify all of this in Stripe Test Mode first. When finished, report: - the webhook path and how the signature is verified - which events are handled - how the order is created and what it stores - the exact identifier that prevents duplicates - what happens on an abandoned or failed payment - the secret names required, and where they are configured - any blocker

IMPORTANT

Reaching the success page proves nothing — anyone can open that URL and the redirect can be replayed. Only a signature-verified Stripe event may create a paid order, and a retried event must never create a second one.

Add Stripe Subscriptions to Any AI-Built Web App With Supabase

Use this for a deeper walkthrough of the verified Stripe webhook pattern.

/video/add-stripe-subscriptions-supabase

Build the Store Dashboard

This is where the merchant actually runs the shop.

Build the Store Dashboard

Create the protected merchant dashboard for products and paid-order fulfillment without touching Supabase manually.

Build the merchant-facing Store Dashboard. This is the store's operational interface — the merchant must never need the Supabase dashboard to run the shop. 1. MERCHANT LOGIN Use Supabase Auth, and reuse trusted staff or admin authentication if this project already has it. Do not create customer accounts. After sign-in, verify the account is actually store staff. A signed-in account without staff access sees a clear "no access" state. 2. PRODUCT MANAGEMENT Let authorized staff create a product, edit a product, upload and manage product images, publish or unpublish a product, and mark it available or unavailable. Editing a product must NOT rewrite historical order items. 3. ORDER LIST Show paid orders with useful information such as the order reference, the customer, the total, the fulfillment method, the fulfillment status and the created time. Put the work that needs attention first, and do not expose unnecessary Stripe internals. 4. ORDER DETAIL Show the purchased items, the quantities, the captured unit prices, the trusted order total, the customer and fulfillment details the merchant needs, the payment state and the fulfillment state. 5. FULFILLMENT Use a small controlled workflow: Paid Processing Fulfilled Payment and fulfillment are separate states. Never mark an order fulfilled automatically just because the payment succeeded, and do not build shipping-carrier tracking. 6. SECURITY Dashboard routes and database operations must be protected by real authorization. A public visitor, or a signed-in account that is not staff, must not be able to list orders, read order details, change a fulfillment state or edit products. 7. RESPONSIVE This has to work on desktop, tablet and phone — a small merchant will check orders from a phone. When finished, report: - the dashboard routes - how sign-in and the staff check work - where staff permissions are enforced in the database - the product management actions - the order list and order detail - the fulfillment transitions

Once the dashboard works, create your real products here — name, price, images, publish — instead of editing Supabase rows. Payment state and fulfillment state stay separate: a paid order is not a shipped order.

Verify the Full Store

Test the whole commerce path in Stripe Test Mode before deploying anything.

Verify the Online Store

Test products, cart, payment verification, order creation and merchant access before deployment.

Perform a focused verification of this online store, using Stripe Test Mode with test products and test orders. Do not add features. 1. PRODUCTS Verify that a published, available product is public; that a draft product is not exposed, including from a direct URL; that an unavailable product cannot enter a new checkout; and that unauthorized users cannot modify products. 2. CART Verify adding an item, changing a quantity, removing an item, and that the displayed subtotal is correct. Remember that the displayed subtotal is not payment authority. 3. PRICE TAMPERING Attempt a modified checkout request that supplies a fake amount such as price = 0.01. Verify the trusted checkout path ignores or rejects any browser-supplied price and uses the authoritative product pricing. 4. PAYMENT In Stripe Test Mode, verify that Checkout opens, that a successful test payment works, that the webhook signature is verified, that a paid order is created, and that the order contains the correct item snapshots and the trusted total. 5. SUCCESS PAGE Open the success URL manually. Verify that doing so creates no paid order. 6. WEBHOOK RETRY Verify that a repeated or retried successful event does not create a duplicate order. Use the smallest appropriate test. 7. MERCHANT Verify that authorized staff can see the order, that a public user cannot list orders, that a public user cannot change a fulfillment state, and that the Paid → Processing → Fulfilled transitions work. 8. PRODUCT EDIT AFTER PURCHASE Change a test product's price after the paid test order. Verify the historical order keeps its original purchased price. 9. SECRETS Confirm the browser code exposes no Stripe Secret key, no Stripe webhook secret and no Supabase Secret or service-role key. Return exactly one: STORE VERIFIED or: NEEDS ATTENTION Use STORE VERIFIED only when products work, the cart works, authoritative pricing works, a verified payment creates the order, webhook retries do not duplicate it, the merchant dashboard works, and private order data stays protected. If NEEDS ATTENTION, list only the issues that block this store from being deployed safely.

Complete one final Stripe Test Mode purchase and fulfill the order from the Store Dashboard before deployment.

Deploy the Store

Before pushing to GitHub, check:

The project builds successfully

No .env or other secret files are being published

No Stripe Secret key, webhook secret or Supabase service-role credential is in browser code

You know the production environment variable names

You know which Stripe callback and webhook URLs the production store will use

Direct product routes work with production routing, not only locally

Push the project to GitHub with Claude Code or your normal GitHub workflow. If the store already has a repository, use it.

Deploy on Hostinger

Recommended plan: Business

USED IN TUTORIAL

https://www.hostg.xyz/SHK1P

Hostinger Websites Add Website Node.js Web App

Choose Import Git repository Connect GitHub and select the store's repository Review the detected framework and build settings Add the environment variables with your project's exact names Click Deploy and wait for the result

IMPORTANT

Keep public client values and private server secrets separate, under the names the project already uses. Never move a private secret into a VITE_ or NEXT_PUBLIC_ variable to make the deployment work.

Fix a Failed Website or Web App Deployment With AI

Use this if the Hostinger deployment fails.

/video/fix-a-failed-website-or-web-app-deployment-with-ai

Verify the Live Store

Once the live URL exists, point Stripe and Supabase at it:

Add the production Stripe webhook endpoint for the live store URL, and if merchant sign-in needs it, set the Site URL and Redirect URLs for production:

Supabase Authentication URL Configuration

IMPORTANT

Keep Test Mode and Live Mode clearly apart. This build is complete in Test Mode — a store on test keys is not accepting real money, and switching to live keys is a separate decision that comes with the usual business and payment setup.

Verify the Live Online Store

Check the complete Hostinger store from product browsing through verified checkout and merchant fulfillment.

Perform a focused production verification of this online store. Do not add features. 1. GITHUB Verify the intended source is current and that no secret files are committed. 2. HOSTINGER Verify the deployment succeeded, the correct repository and branch are connected, the build and runtime configuration are correct, and the required environment variables exist. 3. PUBLIC STORE Verify the catalog loads, product routes work including a direct refresh, the cart works, and unavailable and draft products behave correctly. 4. STRIPE Using the mode this store is currently in, verify that Checkout loads, that trusted prices are used, that the webhook reaches the production endpoint, that signature verification succeeds, and that one successful payment creates exactly one order. 5. MERCHANT Verify merchant login works, the order appears in the Store Dashboard, the Paid → Processing → Fulfilled transitions work, and a public or unauthorized user cannot reach merchant order data. 6. SUPABASE Verify the intended project is in use, that product and order data persists, and that authorization is still enforced. 7. MOBILE Verify products browse correctly, the cart is usable, and the Checkout flow works on a phone. Return exactly one: STORE LIVE or: NEEDS ATTENTION If Stripe is still in Test Mode, make the summary line explicitly say "Stripe Test Mode" so nobody reads it as accepting real payments. If NEEDS ATTENTION, list only production blockers.

Complete one final live-environment Stripe test purchase and fulfill it from the Store Dashboard before adding real products or taking real payments.

Build and Deploy an Inventory Management System With Claude Code

Use this when the store outgrows available / unavailable and needs real stock quantities.

/video/build-inventory-system-claude-code