Diet Market

Built through Walnut

Diet Market runs healthy-meal subscriptions in Qatar. Through Walnut, our own software firm, we built the member app and the configurable Odoo platform behind it, which handles sales, dietitians, the kitchen and dispatch, so a customer can go from "what's my goal?" to a box at the door without a single phone call.

The problem

A diet-meal business is really four businesses at once: sales (plans and subscriptions), nutrition (dietitians and goals), a kitchen that has to know tomorrow's exact ingredients, and dispatch that has to get every box to the right door.

When those live in chats and spreadsheets, customers can't change a meal without messaging someone, the kitchen guesses quantities, and nobody can say who changed a plan, or when. The brief: one system where the customer drives their own plan, and every change flows straight to the kitchen and the driver.

Onboarding that builds the plan

Sign-up is a short wizard, not a form: birth year, height and weight on wheel pickers, daily water intake, allergies and dislikes, activity and a goal (lose weight, build muscle, improve stamina). Then a recommended plan.

Guests can skip all of it and browse packages first. The app only asks for commitment once it has shown value.

The menu is the product

A calendar of boxes, not a list of orders. Days move from select-meal to meal-selected, preparing and delivered, or sit frozen; preparing and delivered days lock automatically. Each meal shows calories, protein, carbs and fat, with removable components. Checkout takes promo codes and VAT-inclusive totals and pays through Sadad, Tabby or card on a hosted checkout. Then the box is tracked from the kitchen to the door.

• Allergies checked on the phone. Every ingredient carries allergy and dislike IDs. Meals with an allergen are greyed out and can't be picked, before anything reaches the server.
• Two API shapes, one menu. The backend moved from one box per day to several. The app normalises both, so old and new plans render the same calendar.
• Translations from the server. English and Arabic load at runtime with a cache and a bundled fallback, and the whole interface flips right-to-left, down to Arabic numerals in the wheel pickers.
• Updates steered from the backend. The backend decides whether an app update is forced or optional, and a service-unavailable screen replaces cryptic errors during maintenance.

The platform behind it

The app is the visible tip. Underneath is a meal-subscription platform on Odoo with one rule: business behaviour is driven by configuration. Plans, meals, macros, pricing, delivery days and preferences are all data, so the same codebase can serve another operator by changing settings rather than program logic.

Plans come in three styles from one engine: calorie-based, fixed package, or make-your-own. One delivery day runs from the customer's versioned meal choices, to operations generating the day, to the kitchen's breakdown by ingredient (net weight, yield, gross weight and variance), to dispatch picking, packing and assigning boxes by driver, city and zone.

• 6 functional areas, from sales to dispatch
• 14 subscription actions, never raw edits
• 45 app screens, plus a 7-step wizard
• around 69 REST endpoints in the member API on Odoo

Also in the app

Dietitian booking with live availability, freeze and unfreeze, renew and change plan, delivery-slot selection, push notifications, partner benefits, and 20 skeleton loaders that hold each layout while data loads.

Screens shown are recreated from the app's source code and assets. Prices, macros and names are representative.