A solver for the maths
A linear-programming solver builds a plan that meets the patient’s nutrient targets exactly. That part is classical optimisation, not AI, and it is deterministic.
Services
Industries
Hephon is an AI agency in Dubai (Hephon L.L.C-FZ) that builds AI products where the cost per use decides whether the product can exist. We rebuilt Compumeal, a clinic platform that helps dietitians build personalised meal plans, in 12 weeks, with AI in three places and an AI cost under two cents per plan.
A solver builds a plan that hits the patient’s nutrient targets exactly. A cheap AI model then scores whether it looks like food a person would eat, and a stronger model only steps in to swap meals when the score is too low. The dietitian reviews and approves every change.
Building a meal plan is slow. The dietitian balances nutrient targets, allergens, medical conditions, cultural preferences and patient feedback at the same time, by hand. Most were doing it in spreadsheets and rebuilding the same structure for every patient, every session. The time each plan takes is the main limit on how many patients one dietitian can serve.
The software on the market split into two camps. Generic generators hit the nutrient numbers and ignored that people eat food, not nutrients; patients rejected the output and dietitians refused to send it. Locked-down tools went the other way, hiding the AI behind opaque rules and fighting the dietitian on every change. There was nothing between too simple and too rigid.
Compumeal had been built in 2024 by a different team. It worked, but it had no strategy for AI cost and enough technical debt that new features were slowing down. In early 2026 the client decided to rebuild it.
AI in three specific places, only where it makes a measurable difference.
A linear-programming solver builds a plan that meets the patient’s nutrient targets exactly. That part is classical optimisation, not AI, and it is deterministic.
A correct plan can still be plain quinoa with steamed broccoli for lunch. A fast, cheap model scores each plan for whether it looks like real food, with reasonable variety and plausible portions, and gives a short reason.
Only when the score falls below a threshold does a more capable model make targeted swaps with the same macros. In production that is roughly 12 percent of generations.
The dietitian types changes in plain language, such as “reduce sodium in Thursday’s dinner”. The assistant finds suitable swaps, scales portions and recalculates the totals.
When a clinic imports a food database or adds custom foods, a model tags each item with meal type and dietary compatibility, so the database stays usable without a part-time administrator.
The dietitian stays in charge of every plan that reaches a patient.
Each change the assistant proposes arrives as an approval card. Nothing changes in the plan until the dietitian accepts it.
Nutrient targets are met by deterministic optimisation, not by a model’s judgement, so a realism swap cannot quietly break the numbers.
The clinical advisory team signed off on meal plan quality, and a clinical adviser joined the build as a part-time team member rather than a weekly reviewer.
Week 3
The dietitian-facing tool worked.
Week 8
The patient-facing plan, a different audience with a different register, felt right.
Week 12
Rebuild complete.
March 2026
Live with real signup traffic.
We worked in tight weekly cycles with the clinical advisory team, shipping enough each week for them to test against real patient scenarios.
On running cost, the case study numbers are the useful ones: a small clinic generating 50 plans a month pays around $14 in AI costs, and an organisation generating 1,000 pays around $370. Calling the most capable model every time would have cost 30 to 50 cents per plan. For the build itself, we scope a fixed price after a short discovery.
No. Compumeal is a clinic platform originally built in 2024 by a different team. Its owners decided to rebuild it in early 2026, and we did the rebuild in 12 weeks.
No. A solver meets the nutrient targets, AI suggests realistic swaps, and the dietitian approves every change through approval cards before a plan goes to a patient.
A cheap classifier judges how complex each request is, a cheap evaluator scores the solver’s output, and the expensive model only runs when the plan is not good enough yet, about 12 percent of the time.
It would cost 30 to 50 cents per plan, which prices the product out of reach for single-practitioner clinics making 30 to 50 plans a month.
We underestimated how much clinical input the solver’s constraints needed, and how long the patient-facing plan would take to feel right: the dietitian tool worked from week three, the patient plan from week eight.
Time to plan, AI cost per plan at different clinic sizes, and patient adherence. The first two have stabilised. Adherence shows up over weeks and months, so it takes longer to measure properly.
Yes, and it is the main lesson from this rebuild. Pick the cheap path and the expensive path first, decide which requests ever need the expensive one, then build the rest around that decision. Treating AI cost as a design constraint, like response time or data integrity, produced most of the difference between the old platform and the new one.
Tell us what you run today. We will say plainly whether this fits, what we would change for your setup, and what a fixed-price first build looks like.