I Built a Full-Stack E-Commerce Platform in One Session. Here's Exactly How.

Lumière is a full-stack luxury jewelry e-commerce platform. Not a frontend with a fake cart. Not a demo with hardcoded products. A real, deployable system.

On the customer side: a cinematic homepage with a dynamic category system pulled live from the database, a filterable shop page with server-side queries, a product detail page with image gallery and recommendations, a persistent cart powered by Zustand, Stripe Checkout with webhook-driven order confirmation, an order tracking page, and a contact form that saves to Supabase.

On the business side: a complete admin panel with a custom dark glassmorphism design — product CRUD with multi-image upload to Supabase Storage, order management with status transitions (pending, confirmed, out for delivery, delivered, cancelled), category management where adding a new category instantly appears on the live site, and a dashboard with order stats.

The tech stack: Next.js 15 App Router, Tailwind CSS v4, Supabase for the database and file storage, NextAuth v5 with a Credentials provider and role-based access, Stripe for payments, Zustand for cart state, and Zod for validation throughout. TypeScript everywhere.

Here is the thing most people get completely wrong with AI-assisted development. They treat the AI like a junior developer they can message in real time — one feature at a time, one component at a time, one bug at a time. Every message costs credits. Every context switch costs coherence. By the time they have a working product, they've spent three times the credits they needed to, the codebase is inconsistent, and half the features don't connect to each other properly.

Before writing a single prompt for this project, the work happened offline. Two reference jewelry sites were studied in depth — their homepage sections, their category navigation patterns, their product card hover states, their shop page filter layouts, their admin-facing workflows. Every page was mapped. Every feature was listed. Every edge case was considered: what happens when a category has no products? What does the empty cart look like? What if a payment fails mid-checkout?

All of that thinking went into one comprehensive prompt. The design system was specified — exact font pairings, CSS custom properties for color tokens, the glassmorphism card utility class with precise blur and border values. The database schema was included in full, with RLS policies. The API route security requirements were explicit: server-side price validation, Stripe webhook signature verification, admin role checks on every mutation. The Zustand store was specced out. The admin panel's visual language was described in detail.

The result was a single output that built the entire platform coherently, because the AI had every constraint and requirement in context at once rather than learning them one message at a time. This is not a trick. It is just the correct way to use these tools.

E-commerce security is not optional and it is not boilerplate. There are specific decisions in this build that exist for specific reasons, and understanding them is more valuable than copying the code.

Server-side price validation. The cart total shown in the browser is never trusted during checkout. When the user hits 'Pay', the server fetches current prices fresh from Supabase, builds the Stripe line items from those server-fetched values, and creates the checkout session. A user who manually edits the JavaScript cart state or intercepts the network request cannot alter what Stripe charges them. This is not a feature — it is a requirement for any real store.

Environment variable discipline. The Supabase service role key, the Stripe secret key, and the Stripe webhook secret are never prefixed with NEXT_PUBLIC_ and never referenced in any client component or client-side code path. They exist only in server-side API routes and the NextAuth configuration. The browser never sees them, the client bundle never contains them. NEXT_PUBLIC_ variables are treated as fully public — because they are.

Supabase Row Level Security. RLS is enabled on every table. The public can read active products and categories. Users can only read their own orders, matched by email from the JWT. All admin operations go through API routes that use the service role client, which bypasses RLS intentionally and explicitly — not because RLS was forgotten.

Admin route protection. A Next.js middleware function runs on every request to /admin/*. If there is no valid session, or if the session user's role is not 'admin', the request is redirected to the login page before any page component renders. The role check happens at the edge, not inside the page.

The categories table is the most important architectural decision in this project, and it is also the simplest.

Every category — Rings, Bracelets, Earrings, Necklaces, Sets — is a row in a database table, not a hardcoded constant in the codebase. The homepage category tiles, the shop page sidebar filters, the admin category selector in the product form — all of them query this table at runtime. Adding a new category through the admin panel requires no code change, no redeployment, no developer involvement. It appears on the live site immediately.

This sounds obvious. It is obvious. But the number of AI-generated sites we audit that have categories hardcoded in a TypeScript array somewhere in the components folder is genuinely alarming. The moment a client wants to add a category, someone has to open the codebase. Database-driven content is not extra complexity — it is the point of having a database.

The same principle applies to the product images. They are stored as a text array in the products table, each entry being a public URL from Supabase Storage. The admin can upload up to eight images per product through a drag-and-drop interface. The URLs are written to the database. The frontend reads them. No hardcoded image paths anywhere.

The admin panel has a specific design brief, and it was written into the prompt explicitly: dark glassmorphism, Poppins font throughout, rounded-3xl on all cards, gold accent color, no generic dashboard template patterns.

This matters because admin panels are where vibe-coded projects most obviously reveal themselves. The customer-facing site gets all the design attention. The admin gets a generic table with blue buttons and system fonts, and every client who logs in immediately feels like they are using a prototype.

Glassmorphism done properly — not the washed-out, unreadable version that defined 2021 — means precise backdrop-filter values, carefully chosen border opacity, and background colors dark enough that the blur effect creates depth rather than mud. The sidebar has a gold accent on the active item. Cards have consistent border-radius and shadow. Form inputs have dark backgrounds with a gold focus ring. Status badges are color-coded pills with enough contrast to be readable at a glance.

The result is an admin panel that a client can show to their team without embarrassment, and that a developer can hand off without apology.

The point of this post is not that AI tools are magic. They are not. The point is that the quality of what comes out is almost entirely determined by the quality of what goes in — not just the prompt text, but the thinking that happens before the prompt is written.

If you open an AI tool and type 'build me an e-commerce site', you will get a frontend. If you spend two hours researching, mapping, specifying, and thinking through every edge case before you write a single word to the AI, you will get a system.

The credits you save by doing your thinking upfront are significant. The coherence of the codebase you get is incomparably better. And the security of the thing you deploy — because you specified the security requirements explicitly rather than hoping the AI would infer them — is the difference between a product and a liability.

If you have a vibe-coded site that needs a security audit, a performance review, or a structural overhaul, that is exactly the work we do at VibeFixer. The first audit is free. You will almost certainly find something worth fixing.