Leopardol E-commerce Platform

The problem

A Gen Z clothing brand wanted a custom storefront that could express their visual identity and scale with the catalog as they grew. Shopify was the obvious starting point, but the templates constrained the look they wanted, and the platform fees and tier limits would bite as catalog and traffic scaled. They came to Crescentia One LLP for a custom build that gave them full control of the storefront design, the admin tooling, and the underlying infrastructure cost curve.

Architecture

The storefront is Next.js on Vercel, talking to an Express backend that runs on an AWS EC2 instance. The admin dashboard is a separate Next.js app on Vercel, sharing the same backend. Postgres lives on Neon (serverless, branchable for staging). Prisma sits between Express and the database. Authentication is Better Auth with email plus Google OAuth. Razorpay handles checkout, with the verify step gated on HMAC SHA-256 signature validation against the raw request body buffer. Delhivery handles shipping. Product images live in Cloudflare R2 and are served directly from R2's CDN, which avoids egress charges entirely.

The order lifecycle moves through PENDING, PROCESSING, SHIPPED, DELIVERED, with CANCELLED reachable from any state. Carts persist server-side, so a logged-in user has the same cart on any device. The admin dashboard exposes order management, product CRUD, coupon rules, support inbox, and a daily visitor analytics view fed by a node-cron job.

What I owned

Architecture and infrastructure decisions across the whole stack. The Express backend in full (controllers, routes, payment integration, Razorpay webhook verification, support and email flows via Resend, rate limiting, the cron scheduler). End-to-end deployment, including the AWS EC2 setup, R2 bucket configuration, and the Vercel deploys for both Next.js apps. Client engagement and engineering leadership across the build. The Postgres schema and Prisma layer, the Better Auth setup, and the storefront frontend were built by a teammate.

Hardest technical decision

The product schema. The catalog needed variants by size and colour, inventory tracked per SKU, pricing that could differ per variant, and image associations that sometimes belong to a variant and sometimes to the whole product. Cart items had to reference variants, not products, but order line items needed enough denormalised product data to survive future product edits without rewriting history. Getting this right upfront mattered because every controller (cart, checkout, admin, analytics) reads from it. I went with a Product / ProductVariant split with a separate Image table that can attach to either, and order line items snapshot the variant's price and key product fields at the time of order. The other contender was an EAV-style attribute model, which I rejected because it would have made every catalog query painful for no real flexibility win at this catalog size.

The other recurring decision was on the client side. Continuous follow-ups, scope conversations, and translating "we want it to feel premium" into specific design and behaviour calls. Less glamorous than the schema work, but it shaped what got built more than any single technical choice.

What I'd do differently

Treat the order lifecycle as an explicit, idempotent state machine. Right now the PENDING to PROCESSING to SHIPPED to DELIVERED transitions are spread across controllers and depend on the Razorpay webhook firing exactly once. In practice webhook retries happen, and a clean state machine with idempotency keys would have prevented the edge cases I patched reactively (duplicate cart clears, double order updates on retry). I would also pull transactional emails (Resend) off the request path into a background job. A Resend hiccup currently has a small chance of slowing or failing order placement, which it should never be able to do.