DropCart

The problem

In a limited drop, many shoppers press Reserve in the same second, and a store that checks stock and then updates it will sell units it does not have. DropCart is built so that exactly as many shoppers succeed as there are units in stock, while the interface keeps stock, countdowns and hold timers live and easy to follow.

The approach

A Next.js 16 and React 19 storefront with a separate Express and MongoDB API. Each unit is reserved atomically and held for five minutes while the shopper pays through hosted Stripe Checkout, then released back to the drop if unpaid. Three roles (shopper, admin, superadmin) get their own protected flows, and a Gemini-powered copilot searches the real catalog to suggest products within a budget and fill the cart. The interface is built around one idea, a torn ticket, with a token-based design system, light and dark themes and reduced-motion support.

Key decisions

• Made reservation a single atomic MongoDB update that checks the drop is live and stock remains in the same operation, instead of using locks. A scripted load test fires all requests at once and verifies that exactly as many succeed as there are units.
• Routed all browser API calls through a Next.js rewrite so the session cookie stays first-party, which avoids CORS setup and third-party cookie problems. Hold timers use the remaining time sent by the server, so a wrong device clock never changes the countdown.
• Grounded the AI copilot in real data. Product cards are built from database results rather than model text, product ids are validated on the server, and the user id always comes from the session, never from model arguments.
• Built a design system on CSS variables exposed to Tailwind, with the theme applied before first paint so there is no flash, plus semantic landmarks, a skip link, live regions, labelled forms and reduced-motion support.

The outcome

A scripted load test fires all reservation requests at once and verifies that exactly as many succeed as there are units in stock. Shoppers browse live and upcoming drops, reserve a unit, pay before the timer ends and follow their receipts, while admins manage only their own products and drops and watch live stock and revenue. Stripe runs in test mode, with a built-in mock provider keeping the demo usable, and the API also ships with scripted tests for payments (duplicate webhooks and late payments) and copilot grounding.

What I would build next

• Server-sent events instead of polling for stock and timers, to support very large audiences.
• An image upload pipeline for product photos, replacing image URLs and static files.
• A shared store such as Redis for rate limiting, and a local payment gateway behind the existing provider interface.