FuelPlan AI: OpenAI
Meal Planning App

A healthy-meal kitchen in the Gulf region cooks fitness meals for subscribers, and every subscriber wants a plan matched to their own body and goal. Done by hand, each plan takes a nutritionist’s time, and the kitchen cannot write one for everyone who signs up. A generic AI could draft a meal plan in seconds, but a real kitchen cannot cook a plan full of ingredients it does not stock. The plan has to use what is in the fridge, hit the right calories and macros, and arrive in a form the kitchen can prepare without a chef redesigning it.

FuelPlan AI is the web app we built to do exactly that. A customer enters their body data, standard formulas work out their nutrition targets, and OpenAI then designs breakfast, lunch, dinner and snacks using only the ingredients and sauces from the kitchen’s own catalogue. Every meal comes back as structured data with quantities and totals, is checked against the targets and the catalogue, and can be regenerated if the customer wants a different set.

Put simply, your data sets your targets, the AI chef builds your meals from what the kitchen actually stocks, and the kitchen cooks them with no redesign. The maths comes from formulas, not the model, so the numbers hold up, and nothing off the catalogue ever reaches a plate.

The Starting Point: Personal Plans the Kitchen Can Actually Cook

The goal was an app where a customer enters their details and receives a balanced program the kitchen can cook straight away. For that to work for a real business, generic AI output was never going to be enough, which set a clear list of requirements.

• Scale past manual planning. Every customer needs a plan matched to their body and goal, which a nutritionist cannot write one at a time for a growing subscriber base.
• Use only what the kitchen has. Meals must be built from the kitchen’s own ingredients and sauces, with nothing the kitchen does not stock.
• Make the numbers add up. Calories and macros must hit the customer’s targets, not just look healthy on the page.
• Keep meals cookable. Combinations have to make sense on a plate, with the right sauce on the right protein in realistic portions.
• Arrive ready for the kitchen. Output must be structured so the kitchen can prepare it without reworking the plan by hand.
• Plug in later. The planner had to run as a standalone app, ready to connect to the client’s mobile app once that was finished.

The Build: Maths First, Then the AI Chef

Getting a language model to design real meals that stay inside a fixed ingredient list and still hit exact nutrition targets is the kind of problem that defines good OpenAI app development, because the difficulty is not calling the model but keeping it honest. A plan is built in an ordered flow:

1. The customer enters age, gender, height, weight, activity level and goal, and the nutrition engine calculates their BMI and daily energy needs.
2. Those needs are split into calorie, protein, carbohydrate and fat targets for the goal: higher protein and carbohydrates to gain, moderate protein and lower carbohydrates to lose, a balanced split to maintain.
3. A prompt builder sends those targets to OpenAI together with the kitchen catalogue and the meal rules.
4. OpenAI returns a full day of meals, each with its name, ingredients and quantities, and total calories, protein, carbohydrates and fat.
5. A validator checks every ingredient against the catalogue and every total against the targets, rejecting anything off the list.
6. If the customer is not happy, they can regenerate up to twice for a completely new combination rather than a small edit.

Behind the customer screen, an admin panel manages the catalogue and the generated programs, and an import module reads the kitchen’s list from CSV, JSON or Excel with nutrition values for each item. Building the app, the nutrition engine, the catalogue import and the admin panel as one bespoke Laravel system is custom software development in the proper sense, shaped around one kitchen’s menu rather than a template. Because the planner runs on its own, it is ready to connect to the client’s mobile app when that is done.

Technical Architecture

The app is built with Laravel and calls the OpenAI API, with structured JSON as the contract between the model and the kitchen. The hard part is not calling the model. It is making the model stay inside the kitchen’s list and produce numbers that add up.

• Nutrition engine. Standard formulas calculate BMI, daily energy needs and goal-based macro splits, so the targets are consistent and explainable rather than guessed by the model.
• Kitchen catalogue. Ingredients and sauces with their nutrition values, imported from CSV, JSON or Excel so the kitchen keeps its own list current.
• AI chef. A prompt builder combines the targets, the catalogue and the meal rules, and OpenAI returns meals as structured JSON.
• Validator. Every ingredient is checked against the catalogue and every total against the targets, and anything off the list is rejected.
• Admin panel. Screens for managing the catalogue and reviewing generated programs, with the planner running as a standalone app.

The part worth engineering with care is the boundary between the model’s creativity and the kitchen’s reality. Language models like to suggest ingredients they know, so the prompt lists only catalogue items and the validator throws out any meal that strays, while the totals stay tied to the catalogue’s own nutrition values rather than to numbers the model invents.

Challenges Solved

The main challenge was keeping the AI inside the kitchen. A model will happily reach for ingredients it has seen elsewhere, which would produce plans the kitchen cannot cook. The fix was two-sided: the prompt gives the model only the catalogue and its nutrition values, and a validator rejects any meal that contains something outside the list, so off-list ingredients never reach a customer.

Two more problems shaped the delivery. The first demo ran on sample ingredients rather than the kitchen’s own catalogue, which produced unrealistic results, so every plan was moved onto the client’s real catalogue and the meal rules were tightened after her review. Model-generated totals can also drift, so calories and macros are tied to the catalogue’s nutrition values and checked against the targets, which keeps what the customer sees matching what the kitchen cooks. Both milestones were paid, and the client commissioned a second phase covering monthly programs, portion safety limits and meal costing.

The Result

The app gives the kitchen personal meal programs at scale: a customer enters their data, sees their targets, and receives a full day of meals built only from stock, ready to cook without a chef redesigning it. The working app and its admin panel were delivered with a recorded walkthrough within the agreed timeline across May and June 2025, both milestones were paid, and the client extended the work into a paid second phase, which is the clearest sign the core did its job.

It works because the maths comes first and the AI second, grounded in a closed ingredient list and checked output. If you want AI that produces results a real operation can use rather than plausible-looking text, you can hire AI and ML engineers who have built this kind of grounded, validated pipeline, or tell us how your menu and targets work and our team will map them to an app. It suits any health, nutrition and wellness business turning personal data into a plan.

Frequently Asked Questions

What is FuelPlan AI?

It is a Laravel web app with an OpenAI-powered AI chef, built for a healthy-meal kitchen. A customer enters their body data, the app calculates their nutrition targets with standard formulas, and OpenAI designs a full day of meals using only the kitchen’s own ingredients, returned as structured data the kitchen can cook from.

How do you stop the AI suggesting ingredients the kitchen does not stock?

The prompt gives the model only the kitchen’s catalogue and the nutrition values for each item, and a validator checks every ingredient in the returned meals against that catalogue. Any meal containing something off the list is rejected, so a customer never receives a plan the kitchen cannot actually prepare.

Are the calories and macros reliable?

Yes, because the numbers come from standard nutrition formulas rather than the model. The engine calculates BMI, daily energy needs and goal-based macro splits, and the totals in each meal are tied to the catalogue’s own nutrition values and checked against the customer’s targets before the program is shown.

Can a customer ask for different meals?

Yes. If a customer is not happy with a program, they can regenerate up to twice, and each regeneration asks the model for a completely new combination rather than small edits. The new set is checked against the catalogue and the targets in the same way before it is shown.

Can this connect to our existing app or grow further?

The planner was built as a standalone app so it can be connected to a mobile app once that is ready. It is also designed to extend: the client commissioned a second phase for monthly programs, portion safety limits and meal costing, all building on the same nutrition engine and catalogue.