Most meal planning tools give you AI calorie estimates. AI Meal Planner gives you real ones: users enter body stats and food preferences, the app generates a 3-day plan, and every calorie and macro number comes from a live USDA FoodData Central lookup — not a model guess. The plan uses at most 12 shared ingredients across all nine meals, so the shopping list stays short.
The backend is built in Momen: two AI agents, one async Actionflow, and a USDA API integration that runs as a deterministic backend step rather than an AI tool call — cutting total generation time from potential minutes to under 90 seconds. The frontend is a React + Vite app built with Claude Code using the Momen no-code plugin.
Try the live app · Open in Momen editor / Clone project
What the App Does
A user signs up with email and password (email verification required), then fills out a 7-field form: gender, age, height, weight, activity level, goal, and a set of food preference and restriction tags. Tags cover diet styles (High protein, Low carb, Mediterranean, Keto, Vegetarian), restrictions (No dairy, Gluten-free, Low sodium), and allergies (Nut, Shellfish, Egg, Soy). All inputs are fixed choices — no free-text fields.
Submitting the form triggers an async generation flow in the background. The frontend subscribes over WebSocket and shows a loading state until generation completes, then opens the results automatically.
The results page shows three days of meals. Each meal has a name, a short description, an ingredient list with gram amounts, and its real calorie and macro totals. A shopping list at the bottom consolidates every ingredient across the plan into a single receipt-style view with total grams needed. Users can generate a new plan at any time, and every plan is saved to their history.
How the Backend Is Built
The Momen backend covers everything server-side: the data model, the two AI agents, the Actionflow that sequences the full generation pipeline, and the USDA API integration. All of it is configured in the Momen editor — no server code, no deployment step. The backend was set up by describing the full requirements in natural language using the Momen no-code plugin:
Here's my project {project url}. Build only the backend for a web app called "AI Meal Planner" — an app that creates a personalized 3-day meal plan for people who cook their own food at home in the US. This is backend only: set up the data model, the account system, and the logic described below. Do not build any frontend pages or UI — a separate frontend will be built independently and will call into this backend.
Account
Users sign up and log in with email and password. Once logged in, they can save meal plans to their history, look up any past plan, or delete one.
Input data
The backend receives this data for a single request:
- Gender — fixed choices: Male, Female
- Age (number)
- Height in cm (number)
- Weight in kg (number)
- Activity level — fixed choices only: "Rarely active", "Somewhat active", "Very active"
- Goal — fixed choices only: "Lose weight", "Build muscle", "Maintain weight"
- Preferences and restrictions — a list of tags picked from this fixed set (no free text / custom tags):
| Category | Options |
|---|---|
| Taste / diet style | High protein, Low carb, Mediterranean style, Keto, Vegetarian |
| Restrictions | No dairy, Gluten-free, Low sodium |
| Allergies | Nut allergy, Shellfish allergy, Egg allergy, Soy allergy |
Treat "Restrictions" and "Allergies" tags as ingredients to completely avoid, and "Taste / diet style" tags as style preferences to lean into.
What the backend should do with this data
1. Calculate how many calories this person should eat per day, based on their body stats, activity level, and goal, using the standard BMR → TDEE → goal-adjustment method. Also calculate a target range for protein, fat, and carbs in grams per day.
2. Save these targets to the user's profile. If the user already has a saved profile, update it; otherwise create one.
3. Create a full 3-day meal plan, 3 meals a day (breakfast, lunch, dinner) — 9 meals total. Meals must be American/Western home-cooking style. Use at most 12 distinct ingredients across the entire 3-day plan — pick a small core set of proteins, vegetables, grains, and staples, and build all 9 meals by recombining and reseasoning only those ingredients. Each meal needs a name, a short description, and a list of ingredients drawn only from that set, each with an amount in grams. None of the meals may contain anything from the user's selected restriction or allergy tags. Do not estimate or output any calorie or macro numbers at this step — only ingredient names, grams, meal names, and descriptions.
4. Add up the ingredients across all 9 meals into a shopping list: one entry per distinct ingredient with its total grams needed for the 3 days. This list must contain at most 12 items.
5. For each distinct ingredient in the shopping list, look up its real nutrition per 100g using the USDA FoodData Central food search endpoint below. Look up each distinct ingredient exactly once, and reuse that result for every meal that uses it — do not call the API again for an ingredient already looked up in this run. This lookup must run as a fixed backend step, not something a model decides to do during generation.
6. For every meal, add up the real nutrition contributed by each of its ingredients (scale each ingredient's per-100g values by grams ÷ 100), and store the meal's total calories, protein, fat, and carbs.
What the backend should store and expose
- The user's daily calorie target and macro breakdown
- The full 3-day plan, organized by day and by meal, with each meal's name, description, ingredients with grams, and its real calorie/protein/fat/carb totals
- The shopping list: ingredient name + total grams needed for the 3 days
- All of this saved under the user's history, retrievable later, with the ability to trigger a fresh regeneration of a new 3-day plan
Nutrition API to use
USDA FoodData Central — the official US government food nutrition database, free with no paywall.
Docs: https://fdc.nal.usda.gov/api-guide
API key: {YOUR_USDA_API_KEY}
Use one endpoint only — do not call any other USDA endpoint:
`GET https://api.nal.usda.gov/fdc/v1/foods/search?api_key={YOUR_USDA_API_KEY}&query={ingredient name}&pageSize=1&dataType=Foundation,SR Legacy`
Take the first food in the returned `foods` list. Its `foodNutrients` list already contains the nutrition data — read the per-100g values directly from it, matching entries by name: "Energy" with unit "KCAL" is calories, "Protein" is protein, "Total lipid (fat)" is fat, "Carbohydrate, by difference" is carbs. Do not call a second endpoint to get nutrition detail.
Data Model
The data model is a hierarchy with the user's profile at the top and individual ingredients at the bottom:
- account — Momen's built-in authentication table. Handles email/password signup and login, including verification codes.
- user_profile — One profile per account, storing body stats (gender, age, height, weight, activity level, goal, preference tags) alongside the calculated daily targets (calories, protein, fat, carbs in grams). Updated on each generation.
- meal_plan — One record per generation run, linked to the account. Stores plan status.
- day_plan — Three records per meal plan, one per day (day_number 1–3).
- meal — Nine records per meal plan (breakfast, lunch, dinner across three days). Stores meal name, description, type, and its real calorie and macro totals.
- meal_ingredient — One record per ingredient per meal, storing ingredient name and gram amount.
- shopping_list_item — One record per distinct ingredient, storing the total grams needed across the full 3-day plan.
The Two AI Agents
Two AI Agents handle the reasoning parts of generation. Each does one job.
calorie_macro_calculator — Takes gender, age, height, weight, activity level, and goal. Uses the Mifflin-St Jeor formula to calculate BMR, applies an activity multiplier to get TDEE, then adjusts for goal (−20% to lose weight, +12% to build muscle, unchanged to maintain). Calculates protein, fat, and carb targets in grams from those calorie numbers. Returns four values: daily_calories, protein_g, fat_g, carb_g. This agent does no tool calls — it's a single inference step with a deterministic formula baked into the prompt.
meal_plan_generator — Takes the calorie and macro targets from the first agent plus the user's preference and restriction tags. Returns a full 3-day plan: nine meals with names, descriptions, and per-ingredient gram amounts, plus a shopping list of distinct ingredients and their total grams across the plan. Crucially, this agent outputs no nutrition numbers — it only plans meals and quantities. Real nutrition data comes from the USDA API in the next step, not from model estimates. The agent is constrained to use at most 12 distinct ingredients across the entire plan, keeping the shopping list short and practical.
Backend Logic: generate_meal_plan
One Actionflow, generate_meal_plan, sequences the entire pipeline. It runs asynchronously — the frontend subscribes to its result over WebSocket rather than waiting for a synchronous response.
The node sequence:
- Input — receives all 7 form fields (gender, age, height_cm, weight_kg, activity_level, goal, preference_tags)
- Get current user id — resolves the authenticated account
- Calculate calorie and macro targets — calls calorie_macro_calculator
- Query existing profile — checks whether a user_profile record exists for this account
- Branch: profile exists or not — inserts a new profile or updates the existing one with the latest stats and calculated targets
- Generate 3-day meal plan — calls meal_plan_generator with the calorie targets and preference tags
- Create meal plan record — inserts the parent meal_plan record
- For each shopping list ingredient — iterates over the up-to-12 distinct ingredients in the plan:Calls the USDA FoodData Central search API and caches the resultInserts a shopping_list_item record with ingredient name and total grams
- For each day → for each meal → for each ingredient — nested loops that:Insert day_plan, meal, and meal_ingredient recordsCompute each ingredient's nutrition contribution (grams ÷ 100 × per-100g values from the cache)Accumulate the result into the meal's calorie and macro totals
- Output — signals completion to the WebSocket subscription
The USDA lookup runs once per distinct ingredient and caches the result. Every meal that uses that ingredient reads from the cache rather than making another API call. This is the key performance decision — see the next section.
External API: USDA FoodData Central
The USDA FoodData Central API provides the real nutrition data. One endpoint is used: GET /v1/foods/search, queried with the ingredient name, pageSize=1, and dataType=Foundation,SR Legacy to target raw and unprocessed food data rather than branded products.
The API key is stored in the Momen backend and never exposed to the frontend. The search call happens inside a Custom Code node in the Actionflow loop — not inside the AI agent.
This placement matters. The alternative would be to give the meal_plan_generator agent a tool that calls USDA during inference. In practice, each AI tool call triggers a full model inference round — measured at roughly 35–40 seconds per call. With up to 12 ingredients, that would make nutrition lookup alone take 6–10 minutes per generation. By running the USDA search as a deterministic backend step with caching, each real HTTP request takes 1–2 seconds, and all 12 ingredients can be resolved in 15–20 seconds total. The full generation pipeline — two AI inference rounds plus all database writes and API calls — completes in about 60–90 seconds.
Building the Frontend with Claude Code
With the Momen backend in place, the Momen no-code plugin was used to pass the project's full context — data model, GraphQL API schema, Actionflow IDs — to Claude Code. The frontend was generated from natural language:
Build the frontend for this app with React and Vite, calling into the backend already built.
Use warm tones with soft pastel tones as the primary color palette. Keep the interface simple and clean, avoiding a typical SaaS-style look. Add food-related visual elements throughout so the interface feels engaging and relevant to the subject.
Don't make the homepage just a login screen. Give it a clear value proposition with supporting copy explaining what the app does, along with food-related visual elements, so it feels warm and inviting rather than a bare sign-in form.
Claude Code generated the full component structure: the homepage with value proposition, the 7-field form, the WebSocket-powered loading state, the results page with day tabs and meal cards, the receipt-style shopping list, and the history page. The Momen GraphQL endpoint, mutations, and subscription were wired in automatically from the plugin context.
The design uses Fraunces (serif display), Karla (body), and IBM Plex Mono (nutrition numbers). Each meal card has a calorie badge in the corner. The shopping list renders as a receipt with ingredient names, dot leaders, and gram totals.
Two Ways to Build Something Like This
This project used a Momen backend connected to Claude Code via the plugin. If you're starting from scratch, there are two paths:
Momen AI Copilot — describe your app in natural language directly inside the Momen editor. The in-product Copilot configures your data model, Actionflows, and UI without switching tools. See Meet Your Nocode AI Copilot — Build Apps by Chatting in Momen for how this works.
Momen plugin + Claude Code / Codex / Cursor — build the Momen backend in the editor, then install the Momen no-code plugin in your AI coding agent. The plugin passes your project's full context to the agent so you can describe the frontend in natural language and have it wired to the right endpoints automatically. See the complete setup guide for Momen + Claude Code to get started.
How Long Does This Take
Setting up this Momen backend from scratch — data model, two AI agents, one Actionflow with 29 nodes, USDA API configuration, and permissions — takes about 1–2 hours with the plugin handling configuration from natural language prompts. Building the frontend with Claude Code, once the backend context is loaded, takes around 30–45 minutes for a working version.
The minimum plan for this project is Basic at $39/month. At the scale the calculator assumes — 500 registered home cooks growing gradually over time — all usage falls within Basic's included allowances: the database stays around 20 MB (against a 200 MB limit), no photos means no object storage, no outbound data transfer, and AI Points for plan generation fit within the included 1 million per month. No add-ons are needed. You can plug in your own usage assumptions in Momen's pricing calculator.
The USDA FoodData Central API is free with no monthly fee. Frontend hosting on Vercel is free for most early-stage projects.
Try It and Clone the Project
New users get access on signup. Generate a plan with your own stats to see the full pipeline — form, loading state, real nutrition data per meal, and the consolidated shopping list.
Top comments (0)