A dietitian's meal plan used to take hours. Now it takes minutes.

Compumeal is a clinic platform that helps dietitians build personalised meal plans for patients. We rebuilt it from scratch in 12 weeks, with AI in three specific places, and got the per-plan AI cost under two cents. The product has been live with real users since March 2026. A small clinic generating 50 plans a month pays around $14 in AI costs. A large organisation generating 1,000 pays around $370. The economics work at every scale, which is the only reason the product can exist at the price a small clinic can afford.

The problem dietitians actually have

Building a meal plan for a patient isn't quick. The dietitian is balancing nutrient targets, allergens, medical conditions, cultural preferences, and patient feedback, all at once, all by hand. Most clinicians were doing it in spreadsheets, rebuilding the same structure for every patient, every session. The math is real. The cognitive load is high. The time it takes per plan is the single biggest constraint on how many patients a dietitian can serve.

The software that existed mostly didn't work for clinicians. It split into two camps. Generic meal-plan generators produced plans nobody could actually use. They optimised for nutrient targets and ignored that humans eat food, not nutrients. The output looked like a chemistry assignment, not a meal. Patients rejected it. Dietitians refused to send it.

The other camp went the opposite direction. Lock everything down. The dietitian gets a tightly-controlled UI with limited flexibility, the AI is hidden behind opaque rules, and any deviation from the system's idea of a meal plan is a fight. Clinicians rejected that one too, because it didn't respect their judgment.

There was no middle ground between "too simple" and "too rigid." That was the gap we set out to fill.

What we built

Compumeal is a clinic platform with AI in three specific places, only where it makes a measurable difference.

The meal plan generator starts with a linear-programming solver that hits the patient's exact nutrient targets mathematically. That part isn't AI. It's classical optimisation, and it works deterministically. The solver produces a plan that satisfies the constraints. The output is mathematically correct.

The problem is that mathematically correct plans aren't always realistic. The solver might produce a Tuesday lunch of plain quinoa with steamed broccoli and a teaspoon of olive oil. Hits the targets. Nobody is going to eat that.

So after the solver produces a plan, a fast and cheap AI model scores it for realism. Does this actually look like food a person would eat? Does the variety across the week look reasonable? Are the portions plausible? The score is a single number with brief reasoning attached.

Only when the score falls below a threshold does a more powerful model step in to make targeted swaps. Replace the plain quinoa lunch with something with the same macros but more appealing. The expensive model isn't running every plan. It's running the ones that need rescuing.

The second AI surface is the in-editor assistant. It sits next to the meal plan in the dietitian's workspace and lets them make changes in plain language. "Swap the chicken for something plant-based." "Reduce sodium in Thursday's dinner." "Make this less repetitive across the week." Every suggestion comes back as an approval card. The dietitian stays in control. The AI does the heavy lifting of finding suitable swaps, scaling portions, and recalculating the nutrient totals.

The third AI layer handles bulk food classification. When a dietitian imports a new food database or adds custom foods, an AI model automatically tags each item with meal type and dietary compatibility, so the database stays usable without manual upkeep. This sounds boring. It's the difference between a tool that grows with the clinic and a tool that requires a part-time data administrator.

The cost economics had to work

This was the constraint that shaped everything.

If the AI cost too much per plan, the product couldn't be sold at a price a small clinic could afford. Compumeal's target market includes single-practitioner clinics generating 30 to 50 plans a month. At those volumes, an AI cost of even 30 cents per plan would price the product out of the market entirely. We needed to be at single-digit cents, ideally under two.

The answer was a tiered architecture, and the choice of which model to use where mattered more than the choice of which model to use at all.

A cheap classifier decides how complex each request is. Most plans are straightforward and never need the expensive model at all. A cheap evaluator scores the solver's output, and most outputs pass on the first attempt. The expensive model only runs when the cheap one says the plan isn't good enough yet, which is roughly 12 percent of generations in production.

That conditional approach brings the AI cost per meal plan to under 2 cents on average. Compared to 30 to 50 cents if we'd just called the most capable model every time, the architecture is more than ten times more efficient without sacrificing quality. The expensive model still handles the hard cases. It just doesn't get called for the easy ones.

Built once, rebuilt better

Compumeal was originally built in 2024 by a different team. The first version worked, but the architecture didn't have a clear strategy for AI cost, and the engineering had accumulated enough technical debt that adding features was slowing down.

The client made the decision to rebuild in early 2026. New stack, new AI architecture, better cost structure. The rebuild took 12 weeks. We worked in tight cycles with the clinical advisory team, shipping enough of the product each week that they could test against real patient scenarios.

Rebuilds usually fail. The classic failure mode is "the second version inherits the assumptions of the first." We worked hard to avoid that. The original team had assumed AI was a commodity input, priced at whatever the latest model cost. The rebuild treated AI cost as a first-class design constraint, like response time or data integrity. That single change of assumption produced most of the architectural difference between the two versions.

What we got wrong

Two things worth flagging.

We underestimated how much clinical input the linear-programming solver would need. The math is straightforward. The constraints are the hard part. Capturing the way a dietitian actually weighs allergens against medical conditions against patient preferences took longer than the implementation. The fix was to bring a clinical adviser into the build process as a part-time team member, not a once-a-week reviewer.

We also underestimated how often the patient-facing output would need refining. The dietitian-facing tool worked from week three. The patient-facing meal plan, which is what the dietitian sends to the patient, took until week eight to feel right. Different audience, different language register, different expectations. We hadn't planned for that being a distinct design challenge.

Where it stands

The product has been live with real signup traffic since March 2026. The cost economics are holding up at production volumes. The clinical advisory team has signed off on the meal plan quality. The dietitian-facing assistant is being used in every active clinic.

We're tracking three things for the post-launch review: time-to-plan (how long does a dietitian take from patient intake to finished plan), AI cost per plan at varying clinic sizes, and patient adherence (do patients actually follow plans built with the tool versus plans built without it). The first two have stabilised. The third is going to take longer to measure properly, because adherence shows up over weeks and months, not days.

For anyone building a production AI product where the cost economics matter: pick your cheap and expensive paths first, then build the rest of the architecture around the decision. Letting cost be an afterthought is how products end up either too expensive to sell or too low-quality to keep customers.