Building Yuvapri Health: A React and Laravel Storefront for a Supplements Brand

Yuvapri Health is an organic herbal supplements brand based in Ahmedabad, Gujarat. With the client's approval, we're sharing this as a public case study of the storefront and backend Kevion has been building and iterating on since 2025. It's a useful example of a full-stack build for a small ecommerce team: fast on the frontend, strict about money on the backend, and designed to keep shipping features without a rewrite.

The brief: a store the client's team can actually run

Yuvapri didn't have an existing storefront. The requirements were straightforward to state and harder to get right: a fast, mobile-first shopping experience; a product catalog (with size and flavor variants) that the client's own team could edit without asking a developer for every change; checkout that worked for both guests and registered customers; and a backend that priced and processed orders safely, because supplements are a regulated, trust-sensitive category where a pricing bug or a fabricated review is a real legal exposure, not just a bad look.

Architecture: SPA frontend, API backend, nothing shared blindly

We split the system into a React/Vite single-page storefront and a separate Laravel API. The SPA is built with TypeScript, Tailwind CSS, and shadcn/ui (Radix primitives underneath), with routes lazily code-split so the landing page stays light. State is deliberately simple — two React Contexts, not a global store: a cart context that persists to `localStorage` (a cart line's identity is product + size + flavor, so variants of the same product are separate lines), and an auth context wrapping the Laravel session.

Authentication uses Laravel Sanctum's SPA cookie flow rather than a token the frontend has to manage — Google OAuth, email/password, and email-OTP all resolve to the same `users` row, and the session is validated server-side on load. The product catalog itself lives in a Laravel `products` table managed through Filament, served over a REST API. The SPA fetches from that API first and falls back to a static, build-time-generated catalog if the API is ever unreachable — cheap insurance for a small store where downtime directly costs sales.

Payments: the browser proposes, the server disposes

The single rule that shaped the checkout implementation: the Laravel `OrderController` owns money, and the client is never trusted with a price. The flow is two steps. First, `POST /orders` takes product and variant identifiers from the cart, recomputes the full order total from the current catalog snapshot on the server, and creates both a Razorpay order and a pending order row — guests are allowed, with a nullable `user_id`. Second, after payment, `POST /orders/{id}/verify` checks the Razorpay HMAC-SHA256 signature (`order_id|payment_id`) server-side as a fast path, but the Razorpay webhook — not the client's post-payment callback — is what actually flips an order to "paid."

• Order totals are always recomputed server-side from the live catalog, never accepted from the frontend.
• Razorpay secrets exist only in the Laravel environment and are never exposed to the SPA.
• The webhook, not the browser redirect, is the authoritative payment-confirmed signal.
• Guest orders are fully supported — checkout and order tracking never require an account.

Guest-first checkout, account-friendly on top

A common mistake in ecommerce builds is forcing registration before checkout, which quietly kills conversion for first-time buyers. Yuvapri's checkout and `/orders` pages are intentionally public routes — guests can buy and later look up an order by order number without ever creating an account. Registered customers get more: a wishlist, saved addresses, order history with a "Buy again" shortcut, and — as the platform matured — wellness reminders and an early points/streak system tied to daily ritual logging, all read from the same `/me` endpoint that backs auth.

Shipping features on a live store, not a big-bang launch

Rather than one large launch, the storefront has grown through incremental, shipped-to-production features: a low-friction cart cross-sell slot, a predictive restock bar with ritual-aware product suggestions, a "Save for later" option in the cart drawer, and checkout PIN-code autofill for city/state so customers fill out less of the address form by hand. Each of these went through the same review path — typecheck, tests, and a check against the project's compliance rules before merge, since a supplements storefront can't ship copy that implies unverified health claims or fabricated ratings.

What this build pattern is good for

This is the shape we reach for whenever a client needs an ecommerce storefront that a non-technical team can actually operate day to day: a fast SPA frontend, an API that owns every dollar amount, an admin panel for the catalog, and a deployment pipeline that gates every change on real checks instead of trusting a manual review. It's the same discipline we bring to Magento migrations and performance work — see our Magento 1 to 2 migration case study for the platform-migration side of that same principle — just applied to a from-scratch React and Laravel build.