Case study · Food & events · Web app
Becca’s Food & Events
An ordering platform for Becca’s Food & Events. Customers browse the menu, order for delivery or pickup, pay with Paystack and follow their order live, while the owner and staff run the menu, orders and delivery from an admin panel.
- Role
- Solo full-stack engineer
- Type
- Food & events · Web app
- Status
- Live and in use
- Stack
- Next.js · MongoDB (Mongoose) · Paystack · JWT · bcrypt · Resend · Cloudinary · Vercel
THE PROBLEM
A catering business needs to take orders online, get paid reliably and keep customers informed, without anyone spending the day answering “where is my food?”.
Several people work in the admin with different responsibilities, and past orders have to stay accurate even when the menu or prices change.
KEY DECISIONS
- 01
Orders keep their own copy of the details
The risk · If an order simply pointed at the menu, editing a dish or a price would silently rewrite old orders and receipts.
- Each order stores its own copy of the item names, prices and delivery fee at the time of purchase.
- Later menu changes never alter past orders.
- 02
Payment is confirmed two ways, through one function
The risk · A customer can close the tab right after paying, or a webhook can arrive late. Either way, an order could sit unpaid or be confirmed twice.
- Checkout creates the order and starts the Paystack payment. Payment is confirmed by both the verify page and the Paystack webhook.
- Both paths share one safe confirmation function, so an order is confirmed correctly whichever arrives first.
- 03
Tracking without a login, and without guessable links
The risk · Forcing customers to sign up just to check on a meal adds friction, but easy-to-guess order URLs would expose other people’s orders.
- Each order gets a readable number (#10001 and up) for conversations, and a separate private random tracking link.
- The tracking page shows a live timeline and refreshes every 30 seconds. Signed-in customers also see their order history, matched by email.
- 04
Admin access that changes instantly
The risk · A staff member who is demoted or removed shouldn’t keep access until their session happens to expire.
- Admin sessions are JWTs in an httpOnly cookie, checked against the database on every request, so deactivation, role changes and “log out everywhere” take effect immediately.
- Three roles (exactly one owner, plus managers and staff) are enforced on the server. Passwords are bcrypt-hashed, with a lockout after repeated failures.
- 05
Passwordless sign-in for customers
The risk · Passwords add friction to a food order, and they’re one more thing to leak or forget.
- Signing in is optional: a 6-digit code is emailed through Resend, works once, expires after 10 minutes and is rate-limited.
- The session is a separate 30-day cookie, and guest checkout still works.
WHAT THE TEAM MANAGES
- Menu and products
- Orders, from New to Delivered
- Delivery areas and fees
- Catering enquiries
- Admin accounts and roles
- New-order alerts every 15 seconds, with sound, a pop-up and a tab badge
OUTCOME
Deployed and working end to end: menu, Paystack checkout, live tracking and an admin panel. Payments run in Paystack’s test mode until the business is ready to go live.
Orders move through New, Processing, Ready, Out for delivery and Delivered (pickup skips delivery), with every change recorded in a status history.
Built solo, from database design to deployment.
Have something that needs to work in the real world?