Vibe coding for e-commerce: the 20% of Shopify you can build in a weekend

The honest version of “build a Shopify alternative with AI” is this: you can ship the 20% of Shopify that 80% of small merchants actually use in a weekend. You cannot replace Shopify. Knowing which is which is the difference between a useful exercise and a wasted month.

This article is for the small subset of e-commerce use cases where vibe coding your own store actually makes sense: the single-product store, the side project, the artist selling prints, the maker with 10 SKUs and a story to tell. For anything bigger or more complex, use Shopify or a similar platform — and the FAQ at the end of this article explains why in detail.

If you’re still here, you’re in the right place. Let’s build the 20%.

The 20% of Shopify that 80% of small stores use

When you strip out the operational features (inventory, shipping, tax, multi-channel, etc.), an e-commerce store is just three things: a way to show products, a way to take payment, and a way to fulfill the order. Everything else is decoration until you’re operating at scale.

The minimum viable store has exactly these features:

1. Product pages — one page per product with photo, description, price, “add to cart” button
2. Cart — a session-based cart that persists across page loads
3. Checkout — Stripe Checkout (or similar) for payment
4. Order confirmation — a page that shows after payment, with order details
5. Order email — a confirmation email sent to the customer and an order notification to the store owner
6. Basic admin — a list of orders, a list of products, a way to mark an order as shipped

That’s it. Six features. The total build time with AI is 1-2 days. The total code is maybe 800-1,200 lines. You can do it in a weekend.

What you’re skipping (and why it’s fine for a small store):

• Inventory tracking — assume infinite stock. Manually mark a product as “sold out” if you run out. For a small store, this is fine. (See FAQ for when this breaks.)
• Tax calculation — use Stripe Tax or do it manually in your order admin. For a small store selling in one state/country, this is fine.
• Real-time shipping rates — use flat-rate shipping (“$5 shipping, free over $50”). For a small store with one product line, this is fine.
• Abandoned cart recovery — emails that go out 1 hour after a cart is abandoned. Nice to have, not day-one.
• Multi-currency — assume USD. For international sales, Shopify handles this better.
• Customer accounts — optional. Most small stores have the customer check out as a guest, get the order email, and that’s it.
• Discount codes — easy to add later. For a launch, skip it.
• Reviews / ratings — nice to have. Add when you have products to review.
• Wishlists — nice to have. Add when you have data showing people want this.
• Search — for <50 products, just use a tag/category filter. Real search is overkill.
• Subscriptions — separate problem. Build a recurring-revenue SaaS, not a store.
• Multi-channel (selling on Amazon, eBay, Instagram) — Shopify wins here. Don’t try.

The principle is the same as with the CRM article: build the smallest store that a real customer would use, get it in their hands, learn what they actually need, then add features. The opposite approach — building a “complete” store with all the features — is how teams spend 6 months building something that loses to Shopify in a day.

The data model (same as a CRM, with one new table)

A small e-commerce store has a similar data model to a CRM, with one addition: orders and order items.

The five tables:

• Products — what you’re selling. Fields: name, slug, description, price, images (array of URLs), tags, status (draft/active/sold-out), created_at, updated_at
• Customers — the buyer. Same as CRM contacts: name, email, address (for shipping), created_at
• Orders — a purchase. Fields: customer_id, status (pending/paid/shipped/delivered/refunded), subtotal, shipping, tax, total, stripe_session_id, stripe_payment_intent_id, shipping_address, created_at, updated_at
• OrderItems — one row per product in an order. Fields: order_id, product_id, quantity, unit_price, line_total
• Cart (optional) — if you want logged-in customers with persistent carts. Most small stores use session-based carts in a cookie and skip this table.

The relationships: each Order has one Customer and one or more OrderItems. Each OrderItem has one Product.

The build: 1-2 days, with AI prompts

Here’s the prompt-by-prompt build, in order. Each prompt assumes you’re using Blink, Cursor, or a similar AI app builder, and that you have an existing project with auth and a database.

Build 1: The product page

Build a product page at /products/[slug]. It should show:
- The product image (large, centered)
- The product name (h1)
- The price (large, prominent)
- The product description (rendered from markdown)
- A quantity selector (1-10)
- An "Add to cart" button
- A "View cart" link that shows when the cart has items

The data comes from a `products` table with fields: name,
slug, description, price, images, status. Use the existing
database connection.

Iterate on the styling until the page looks like a real product page (clear hierarchy, the price is the most prominent element after the image, the add-to-cart button is the most prominent action). The AI will produce something generic; the iteration is making it feel like a real store.

Build 2: The cart (session-based, no login required)

Add a session-based cart. Cart state should be stored in a
signed cookie (not the database) so it works for guest
visitors. The cart should:
- Be addable to from any product page
- Show a "Cart (3 items)" indicator in the top nav
- Have a /cart page that lists all items, quantities, and
  the subtotal
- Have an "Update quantity" form on each line
- Have a "Remove" button on each line
- Have a "Checkout" button that creates a Stripe Checkout
  session and redirects

Use a JSON-serialized cart structure: { items: [{ productId,
quantity }] }.

The session cookie is the part that often breaks. The pattern: use a library (iron-session, cookie-session, or your tool’s built-in) to sign and verify the cookie, and store a versioned payload. Don’t roll your own crypto.

Build 3: The Stripe checkout

Add Stripe Checkout integration. The flow is:
1. User clicks "Checkout" on the cart page
2. Server reads the cart, validates all products are still
   available, calculates the total
3. Server creates a Stripe Checkout session with the cart
   items as line items
4. Server returns the session URL
5. Frontend redirects the user to Stripe's hosted checkout
6. User pays
7. Stripe redirects back to /order/success?session_id=...
8. Server listens for the `checkout.session.completed`
   webhook, creates the order in the database, sends the
   confirmation email

Test the full flow in Stripe test mode before going live.

This is the part that matters for security. The full Stripe integration is covered in detail in my article on adding Stripe to AI-built apps, but the key thing for an e-commerce store: the order is only created when the webhook fires, not when the user clicks “Pay”. Frontend success is not authoritative; the webhook is.

Build 4: The order confirmation page and email

Build a /order/success page that:
- Reads the session_id from the URL
- Looks up the order in the database
- Shows the order number, items, total, and shipping address
- Says "You'll receive a confirmation email shortly"

Build a confirmation email that:
- Is sent to the customer
- Contains the order number, items, total, shipping address
- Has a link to the order details page
- Is sent via the email service configured for the project

Test the email send by triggering an order in test mode.

The order confirmation email is the one email you cannot skip. It’s the customer’s proof of purchase, and it’s the thing they look for in their inbox 5 minutes after they buy. If it doesn’t arrive, they think the order failed and they email you in a panic.

Build 5: The basic admin

Build an /admin route (protected by admin role) with:
- /admin/orders: a list of all orders, sortable by date,
  with a "Mark as shipped" button on each
- /admin/products: a list of all products with edit/delete
  buttons
- /admin/products/new: a form to add a new product
- A login link in the admin section if the user isn't
  logged in as admin

The admin user is identified by a role column on the users
table. The /admin routes should redirect to /login if the
user isn't an admin.

The admin is intentionally minimal. For a small store, you don’t need a fancy product editor with image cropping and SEO fields. You need: see the orders, ship the orders, manage the products. That’s it. A full-featured admin is a project of its own.

The two things that will eat your weekend if you let them

These are the parts that look small but consume infinite time. Plan for them.

Image hosting. Your products need photos. Those photos need to live somewhere accessible by URL. Your options:

• Use a third-party service (Cloudinary, imgix, or a simple S3 bucket). Reliable, fast, costs money.
• Use your own server’s public folder. Cheaper, but you need to handle upload, resizing, and storage limits.
• Use a vibe coding tool’s built-in file storage (Blink, Lovable, Bolt all have this). Easiest, but you may hit size limits.

For a small store, the built-in option is fine until you have more than ~50 products or product images larger than 1MB. After that, switch to a dedicated service.

Email deliverability. Your order confirmation email needs to land in the inbox, not the spam folder. The setup: use a real email service (Postmark, Resend, SendGrid) with proper SPF, DKIM, and DMARC records. The vibe coding tools usually default to a generic email service that’s fine for development but gets flagged in production. The fix: configure a real email service before you launch, and test by sending to Gmail, Outlook, and Yahoo addresses to confirm they all land in the inbox.

When to abandon the weekend-build and use Shopify

After 1-2 days, you should have a working store with the six core features. If you find yourself wanting to add:

• Multi-warehouse inventory
• Real-time shipping rates from carriers
• Tax calculation for multiple states/countries
• Subscription billing
• Multi-currency
• Multi-channel selling (Amazon, eBay, Instagram, TikTok Shop)
• Affiliate program
• Wholesale pricing tiers
• B2B features (purchase orders, net-30 terms, custom catalogs)

…that’s the signal. Stop building and switch to Shopify or a similar platform. The features on that list are what Shopify spent 15 years building. You can rebuild them, but it’ll take you 2-3 months and you’ll lose to a Shopify store in the meantime. The right move is to use Shopify for the operational features and consider the “headless” pattern (Shopify backend + custom vibe-coded frontend) if you need a unique buying experience.

The honest takeaway

Vibe coding an e-commerce store in a weekend is real, and the resulting store is genuinely useful for a small business with a single product line, <100 SKUs, and a clear value proposition. It’s not a real alternative to Shopify for anything bigger, and trying to make it one is how people waste months.

The right mental model: vibe coding is the right tool for the 20% of Shopify that small stores use. Shopify is the right tool for the 80% that big stores use. Know which you’re building, and don’t pretend the line doesn’t exist.

If you build the weekend version and find yourself wanting features from the 80% list, that’s a great problem — it means your business is working. Switch to Shopify then, with real revenue to fund the switch.

FAQ

Should I really not use Shopify?

For most small businesses, you should use Shopify. The total cost of ownership is often lower than building it yourself when you factor in: payment processing, security, PCI compliance, hosting, support, the abandoned-cart recovery system, the tax calculation, the email integrations, the shipping integrations, the inventory system, the multi-channel sync. These are 10+ features that would each take weeks to build, and Shopify has all of them on day one. Vibe coding your own store is the right call only when: (a) you need a custom feature no SaaS offers, (b) your unit economics don’t support $39/month + transaction fees, or (c) you want to learn how e-commerce platforms work.

What’s the realistic cost of building my own e-commerce store with AI?

Time: 1-2 days for the minimum viable version (the article’s 20%), 1-2 weeks for the useful version (the 50%), 2-3 months for the comprehensive version (the 80%). Money: $20-50/month for the AI tool subscription + $0-25/month for hosting + Stripe transaction fees (2.9% + 30¢) + whatever you pay for product photos, email service, etc. The big variable is your time: if you value it at $100/hour, a 2-day build is worth $1,600 in time, which is more than 4 years of Shopify Basic. The break-even depends on how you value your time and how long you plan to run the store.

What about payments? Can I just use Stripe Checkout?

Yes, and you should. Stripe Checkout is the right default for a vibe-coded store. You get: hosted payment page (PCI compliance handled by Stripe), support for all major cards, Apple Pay, Google Pay, Link, and the major European payment methods, automatic tax calculation in some regions, subscription support if you need it. The integration is the same as the article I wrote on adding Stripe to AI-built apps — accept the customer’s cart on your site, redirect to Stripe Checkout, listen for the webhook, mark the order as paid in your database. Don’t roll your own payment form. Ever.

How do I handle shipping and tax?

Two paths. The hard path: integrate with shipping carriers (USPS, UPS, FedEx, DHL) directly to calculate rates, print labels, and track packages. This is 1-2 weeks of work and you’ll fight with carrier APIs constantly. The easy path: use a third-party service (Shippo, ShipStation, EasyPost) that handles all the carrier integration. You call their API, they handle the carriers. The middle path: skip real-time rate calculation and just use flat-rate shipping (one price for everything). Flat-rate is fine for small stores with a single product line. For tax: use Stripe Tax (auto-included if you use Stripe Checkout) or a service like TaxJar. Don’t try to maintain a tax table yourself.

What about inventory management? What if I have 500 SKUs?

This is where Shopify wins decisively. Shopify’s inventory system handles: stock levels per SKU, low-stock alerts, multi-warehouse stock, bundle SKUs, kit assembly, purchase orders, supplier management, and restock forecasting. A vibe-coded store can do basic stock tracking (count down when an order is placed) but it won’t have the rest. For 500+ SKUs or any multi-warehouse operation, use Shopify or a similar dedicated platform. Vibe coding is the right call for stores with <100 SKUs and a single warehouse.

What if I want both — use Shopify for the backend but a custom vibe-coded frontend?

This is a real pattern. Shopify has a ‘headless’ mode (Storefront API) where you can use Shopify for products, inventory, orders, and payments, but build your own custom frontend. The vibe coding tools can connect to the Shopify API and render the product pages however you want. You get the best of both: Shopify handles the boring operational stuff (which is genuinely hard), you control the buying experience (which is where you differentiate). The tradeoff: you’re paying Shopify AND building a custom frontend, so you save on the dev cost of building operational features but you spend on the custom-frontend dev cost. Best for stores that have a strong brand and need a unique buying experience.