Mealora - Beyond Food.

Inspiration

In India, food is rarely just a meal. It's a wedding feast, a housewarming, a daily tiffin from a neighbour's kitchen, or the cook who arrives every morning. Finding any of these is still done through phone calls, word of mouth and WhatsApp forwards. Prices are vague, availability is unclear, and it's hard to compare options. We wanted one place that covers the whole range of home and event food, from a single lunchbox to a 500-guest wedding. We called it Mealora: More Than Meals. The home page shows an arati aku bhojanam, a traditional banana-leaf meal, because we wanted the product to feel like the food it serves. • Catering: filter caterers by occasion, guest count, location, diet, budget, cuisine and services, then request a quote. • Lunchboxes: choose a delivery place, meal, diet, spice level, frequency and budget. You get matching kitchens, and the plan is priced before you confirm. • Workers (home cooks): book a cook for one-time, daily, weekly or monthly visits. Cooking and household help such as cleaning are listed and priced separately. Customers can create accounts, save caterers and track their requests. Partners can apply to join, and admins review applications and requests.

Front end: a single-page app in plain HTML, CSS and JavaScript with no build step. It uses hash routing, an accessible form system, a scroll-scrubbed video background, and an SVG illustration of the leaf meal that highlights each dish on hover. Back end: a Node.js and Express server with a SQLite database. It uses httpOnly session cookies, bcrypt-hashed passwords, rate limiting and a content security policy. It exposes a REST API for the catalog, accounts, quotes, orders, bookings, partner applications, favorites and an admin area. The server is the source of truth for prices. A lunchbox plan with q boxes per delivery, meal price p, delivery fee f and n deliveries costs: \text{total} = (q \cdot p + f)\cdot n,\qquad n=\begin{cases}1 & \text{one-time}\ d & \text{weekly}\ 4d & \text{monthly}\end{cases} Here d is the number of delivery days per week. A cook visit of h hours for k people at hourly rate r, with a per-person surcharge s above four people, costs: \text{visit} = r\,h + s\,\max(0,\,k-4)\,h + \sum_{t\in\text{tasks}} \text{fee}_t We wrote this once in the browser and again on the server. The server version is the one that counts, so editing a request can't change a price. • Validate on the server: any rule that matters has to be checked there, because the front end can be bypassed. This covers capacity limits, a cook's working days and hours, and who may read a booking. • Match the data model to the real world: keeping cooking and household work separate in the data kept the prices and the interface honest. • Design for the missing backend: because the front end falls back to a local demo when the API is unreachable, we could build and test each half separately. • Accessibility is a feature: labelled fields, live regions for errors, keyboard-friendly dish highlights and reduced-motion support made the app better for everyone. • Migrating a working demo: the app already ran on browser storage, so we patched it to use the API without rewriting it. We added a live-mode switch and kept the old behaviour as a fallback. • Framework version differences: Express 5 changed how route patterns work, which broke our admin routes until we validated the parameters in code instead. • Two pricing implementations: keeping the client and server calculations identical took care. We checked it with hand-computed cases, such as a 6-person weekly cook booking with groceries coming to ₹1,000. • Being honest about the data: the listings are sample data, nothing is paid for online, and providers aren't notified yet. We labelled these clearly instead of implying they were real.