Architecture came first. Three separate apps sharing one backend, one database. The most important schema decision early on was storing a full snapshot of each food item inside the order document not just a reference ID. That way if a menu price changes later, every historical order still reflects exactly what was charged at the time.

The backend was built around six clear concerns: user auth, food item management, cart operations, order creation, payment processing and order status updates. Splitting routes by concern from the start kept the codebase clean as it grew.

The Stripe flow required the most thought. The payment session is created entirely on the backend with the correct line items and amounts. The customer is redirected to Stripe's hosted checkout, and the order is only written to MongoDB after Stripe confirms a successful payment on the return redirect. Failed or abandoned payments leave nothing behind in the database.

The customer storefront was built around a single cart Context that any component can read from or write to. The main challenge here was keeping cart state intact across the Stripe redirect - the cart only clears on a confirmed successful payment, not on navigation or a back-button press mid-checkout.

The admin panel came last - a separate React app with its own auth, menu management with image uploads via Multer, and an orders view where status can be updated through the fulfilment stages in a single dropdown. Status changes reflect immediately in the customer's order history.

All three services are deployed independently on Render with environment variables handling every credential. Nothing sensitive is in the repository.