Meal plan kitchens in Dubai, Abu Dhabi, Riyadh and Jeddah tend to run the same way in their first year. Customers find you on Instagram, message you on WhatsApp, pick a plan from a PDF, pay by bank transfer or a payment link, and then the real work starts: someone types every order into a spreadsheet, tracks who paused which days, works out tomorrow's counts for the kitchen, and splits deliveries by area for the drivers.
It works at 30 subscribers. At 150 it starts to break. People pause by voice note, a customer's allergy gets lost in a long chat, the kitchen prepares meals for someone who cancelled, and nobody can say how many active subscribers you have without an afternoon in the spreadsheet.
This article walks through building a proper meal plan website for that kind of business: plans, a customer account where subscribers pause and swap meals, a kitchen view, and delivery lists by area. I'll show it with Mythex, the AI app builder I work on, using the actual prompts, but the structure applies whatever tool you use.
What the website actually has to do
Before building anything, it helps to separate the four jobs, because most off-the-shelf "restaurant website" tools only do the first one.
1. Sell plans. A public site in Arabic and English with your plans (for example weight loss, muscle gain, balanced, keto), what's in each, meals per day, days per week, and price per week or month. Customers choose, enter their address and delivery slot, and start a subscription.
2. Let subscribers manage themselves. This is the part that removes most of the WhatsApp traffic. A logged-in customer should be able to pause specific days (travel, Eid, a weekend away), swap a meal for another one on the menu, update an allergy, change their address, and see their remaining days.
3. Tell the kitchen what to cook. Every evening the kitchen needs one number per dish for tomorrow, adjusted for pauses, swaps and allergies, plus labels with the customer's name and any exclusions.
4. Tell drivers where to go. A delivery list for tomorrow grouped by area (Dubai Marina, JLT, Al Barsha; or Al Malqa, Al Yasmin, Hittin in Riyadh) and by slot, with phone numbers and building notes.
If a tool can't do 2, 3 and 4, you'll still be in the spreadsheet every night, whatever the website looks like.
Step 1: describe the data first
Start with the records, not the pages. In Mythex you describe the app in chat, and it creates the database tables, the pages and the logic together. My first prompt for a kitchen like this:
Build a meal plan subscription website for a healthy meal prep kitchen in Dubai. Tables: plans (name in English and Arabic, description, meals per day, days per week, price per week in AED), dishes (name EN/AR, calories, protein, carbs, fat, allergens), weekly menus (which dishes are offered on which date), customers (name, phone, email, area, building, delivery slot, allergies, notes), subscriptions (customer, plan, start date, end date, status), pauses (subscription, date), and meal choices (subscription, date, dish). Areas are a fixed list I can edit. The site must work fully in Arabic and English with a language switch.
That one message gives you a working app with a real database behind it, not a mock-up. You can open the tables and check the columns before going further.
Two things worth getting right at this stage. First, store pauses as individual dates rather than "paused from X to Y". It makes the kitchen counts and the "remaining days" calculation much simpler. Second, keep allergies as a list of fixed allergens (nuts, dairy, gluten, shellfish, egg, sesame) plus a free-text note. A dropdown list can be checked against dishes automatically; a sentence in a chat can't.
Step 2: the public site and sign-up
Create the public homepage: a hero with our tagline, the plans as cards with price per week and meals per day, a "how it works" section (choose a plan, choose your start date, we deliver daily between 6 and 9 am), this week's menu with calories and macros for each dish, delivery areas, and FAQs. Arabic and English, right-to-left layout in Arabic. A "Start my plan" button opens a sign-up form: name, phone with country code, email, area, building and flat, delivery slot, allergies, and start date (not earlier than two days from today).
The two-day rule matters more than it looks. Most kitchens buy ingredients a day or two ahead, so a subscription that starts tomorrow morning is a problem. Put your real cut-off in the rule.
On payment: the build above records the subscription and its status. Charging a card is a separate step, where you connect a payment provider with your own merchant account (Stripe, or a regional gateway that supports your country). Many kitchens start by keeping their existing payment link and marking subscriptions as paid by hand, then add online payment once the rest works.
Step 3: the subscriber account
This is the page that saves your team the most time.
Add a customer account. Customers sign in with their email. They see their plan, start and end date, and a calendar of their delivery days. They can pause any day up to 8 pm the evening before, and paused days extend the end date. For each upcoming day they can swap any dish for another dish on that day's menu, but the app hides dishes that contain one of their allergens. They can update their address and delivery slot, effective from the day after tomorrow.
The rules in that prompt (8 pm cut-off, paused days extend the plan, swaps hidden by allergen) are the ones you'd otherwise enforce by hand in WhatsApp. Write your own rules; the point is that the app applies them the same way every time.
Test it on a phone. Almost all of your customers will use it from one, and most of them in Arabic.
Step 4: the kitchen and delivery views
Add a staff area that only signed-in staff can open. Kitchen page: pick a date (default tomorrow) and show the count of each dish, after pauses and swaps, plus a list of portions with allergy exclusions. Add a "print labels" view with one label per meal: customer name, dish, calories, allergens to exclude, and delivery date. Delivery page: tomorrow's deliveries grouped by area and then by slot, with customer name, phone, building, flat and notes, and a button to export the list for each driver.
Run it against a real day. Take yesterday's spreadsheet, enter the same customers, pauses and swaps, and compare the counts the app gives with what your kitchen actually cooked. If they don't match, the difference is usually a rule nobody had written down (a customer who always gets an extra portion, an area you don't deliver to on Fridays). Add it to the app now.
Step 5: Ramadan, holidays and the other Gulf specifics
Gulf meal plan businesses have a calendar that generic tools don't know about.
During Ramadan dates I set, replace the morning delivery slot with two options: before iftar (4 to 6 pm) and suhoor (10 pm to midnight). Customers choose once for the whole month and can change it with one day's notice. Let me mark public holidays as "no delivery" days, which automatically extend everyone's plan by one day.
Also check VAT on your prices (5% in the UAE, 15% in Saudi Arabia) and whether your plan prices are shown inclusive of it, which is what customers expect. And keep the Arabic copy written by someone who speaks it natively. The builder lays out right-to-left pages correctly, but your menu descriptions should still read like your brand, not like a translation.
Step 6: publish on your own domain
When it works, publish it. You get a public address straight away, and on a paid plan you can connect your own domain, such as order.yourkitchen.ae or yourkitchen.sa, with the staff area staying behind sign-in.
Honest limits
- Payments and refunds are yours to set up. The app tracks subscriptions; card payments, failed payments and refunds go through a payment provider account you open and connect.
- Delivery routing is basic. Grouping by area and slot is enough for a few drivers. Optimised routes across dozens of drivers is a job for a dedicated delivery platform, which you can feed with the exported list.
- Nutrition numbers are as good as your recipes. The app adds up whatever calories and macros you enter per dish. It doesn't calculate them from ingredients unless you build that too.
- Someone has to own the rules. Cut-off times, pause limits and refund policy are business decisions. The app enforces them consistently, but it can't decide them for you.
For teams
Once there's an operations person, a kitchen lead and a customer service agent, build it in a shared team workspace rather than the founder's personal account, so the app doesn't depend on one login. On Mythex's Business plan (from $50/month), the workspace has Admin, Editor and Viewer roles, per-member credit limits and usage by person, and members-only apps that only signed-in colleagues can open, which suits the kitchen and delivery pages. Sign-in through your company's Google Workspace or another identity provider is available once your domain is verified. Current prices are on the pricing page.
If you run a meal plan kitchen and your setup has a rule I didn't cover (corporate plans billed to a company, family plans with different meals per person, gym partnerships), describe it in the comments and I'll suggest how I'd model it. And if you want to start from a first version for a meal prep business, this page shows what Mythex builds from a single description.
Top comments (0)