VedaGlow

Server-rendered React 19 application built with Vite and TanStack Start. Routes render on the server for first paint, then hydrate for interaction.

• ·React 19 with TanStack Start — server rendering plus typed client routing
• ·Tailwind CSS v4 with a Radix UI component layer
• ·Zustand for cart state, TanStack Query for server-state caching
• ·Zod schemas shared between client forms and server functions
• ·WebP imagery with route-level code splitting via Vite
• ·Schema.org product structured data for search result eligibility

Supabase PostgreSQL, evolved across 11 migrations. The schema covers orders, line items, coupons, redemptions, profiles, addresses, product overrides, storefront settings and roles.

• ·10 tables: orders, order_items, coupons, coupon_usage, profiles, shipping_addresses, product_overrides, store_settings, popup_settings, user_roles
• ·Five domain enums: order_status, payment_status, payment_method, discount_type, app_role
• ·Human-readable order numbers generated in the database (VG-YYMMDD-XXXXXX)
• ·Monetary columns typed NUMERIC(10,2) — never floating point
• ·Migration history kept in the repository, so schema changes are reviewable

Authorization is enforced twice: in server-function middleware, and again at the database through Row-Level Security. The database is the final authority on who can read a row.

• ·27 Row-Level Security policies, with RLS enabled on all 10 tables
• ·Role model via a user_roles table and an app_role enum (admin, user)
• ·A shared admin assertion guards every privileged server function
• ·Customers can only ever read their own orders, addresses and redemptions
• ·Supabase Auth owns credentials — no password material is handled by application code

A focused single-kit catalog. Product records are keyed by SKU and carry admin-editable overrides, so pricing and copy change from the admin panel rather than from a deploy.

• ·SKU-keyed product records with name, description, price, MRP and image
• ·Stock level stored per SKU and editable from the admin panel
• ·Visibility and enabled flags — a product can be hidden without deletion
• ·Storefront copy, pricing and promotional popups managed through settings tables
• ·Public read access granted explicitly; writes restricted to the service role

Cart state lives in a Zustand store with the persist middleware, so it survives refreshes and tab closures. Totals and coupon eligibility are recomputed server-side before an order is created.

• ·Zustand store with persist middleware writing to localStorage
• ·Add, update quantity and remove, with totals recalculated on every mutation
• ·Coupon code applied against the cart and validated on the server
• ·Line items and pricing re-validated server-side at order creation
• ·Separate drawer store so cart UI state never pollutes cart data

A multi-step checkout collecting customer details and a shipping address, then presenting payment options. Address entry is accelerated by PIN-code lookup.

• ·Multi-step flow: cart review → customer and address → payment → confirmation
• ·PIN-code lookup auto-fills city and state from an Indian postal API
• ·Zod validation at each step before the customer can advance
• ·Two payment paths offered: pay in full online, or pay a partial advance with the balance on delivery
• ·Order created server-side with the authoritative total — the client never sets the amount

Razorpay integration covering order creation, checkout, verification and failure handling. A payment is only trusted once its signature has been verified on the server.

• ·Razorpay order created server-side; the client receives only an order id, key and amount
• ·Razorpay Checkout opened in-page for cards, UPI and netbanking
• ·Payment id, order id and signature posted back and verified server-side before the order is marked paid
• ·razorpay_order_id, razorpay_payment_id, razorpay_signature and payment_timestamp persisted on the order
• ·Payment failures surfaced to the customer without losing their cart or address
• ·Cash on delivery and split advance payment handled as first-class methods alongside online payment

Orders move through a six-state lifecycle, with payment status tracked separately so a delivered order and a refunded payment can coexist.

• ·Order states: pending → confirmed → processing → shipped → delivered, plus cancelled
• ·Payment status tracked independently: pending, paid, failed, refunded
• ·Guest and account orders share one model — user_id is nullable by design
• ·Full shipping address snapshotted onto the order as JSON at purchase time
• ·Admin order views and status transitions behind authenticated server functions
• ·Internal notes field for operational context on an order

A discount engine supporting percentage and flat-amount coupons, with expiry, activation and a global usage cap. Every redemption is recorded.

• ·Two discount types via a discount_type enum: percentage and flat
• ·Global usage cap enforced by comparing used_count against max_uses
• ·Expiry timestamp checked at validation time
• ·Active flag lets a coupon be switched off without deletion
• ·coupon_usage ledger records coupon, order and discount amount per redemption
• ·Discount value constrained positive at the database level

Customers receive order updates over WhatsApp rather than email — the channel Indian D2C customers actually read.

• ·Six message templates: confirmed, packed, shipped, out for delivery, delivered, cancelled
• ·Indian phone numbers normalised to wa.me format, accepting +91, 91, 0 and bare 10-digit input
• ·Messages composed from live order data so the customer sees their own order number

A role-guarded admin surface for running the store day to day — orders, products, coupons and storefront content, all without a developer.

• ·Admin-only server functions for orders, products, coupons and settings
• ·Product overrides: price, MRP, stock, visibility and imagery
• ·Coupon creation, deactivation and usage visibility
• ·Storefront settings and promotional popup configuration
• ·Every admin mutation passes a shared admin assertion before touching data