Redgum Book a conversation
Commercialising expertise

Case Study: Eat By Design Macronutrient

Short form

Once the Eat By Design platform was working, practitioners had a new problem: their clients could see what they were eating but not what it meant nutritionally. Adding macro and micronutrient calculations to every recipe, every day, and every weekly plan turned meal planning from a logistics exercise into a clinical one — and removed the manual maths that had been making that level of rigour impractical.

The challenge

Nutritional practitioners work to targets. A client managing Type 2 diabetes, cardiovascular risk, or a weight condition has specific macro and micronutrient requirements that a well-designed weekly plan should meet — particular ratios of protein, carbohydrate, and fat, specific levels of sodium, fibre, iron, or calcium depending on the presentation.

Before the macronutrient extension, doing this properly required practitioners to calculate the nutritional profile of each recipe manually, aggregate those figures across each day’s meals, and then sum the week. For a single client with a straightforward profile, this was slow. For a practitioner managing a full client load, each with different conditions and targets, it was impractical without compromise — and compromise usually meant either spending hours on calculations or leaving the nutritional rigour implicit rather than demonstrated.

The patient education problem was parallel. Telling a client their plan is nutritionally appropriate is less useful than showing them exactly what their meals contain and how each one contributes to their targets. The calculation had to be visible to the patient, not just completed behind the scenes.

What we built

The macronutrient extension added a nutritional database to the Eat By Design recipe library and wired it into every level of the plan. Each recipe carried its full macro and micronutrient profile — protein, carbohydrate, fat, fibre, sodium, and a set of micronutrients relevant to common dietary conditions. When a practitioner assembled a weekly plan using the drag-and-drop interface, the system calculated the nutritional totals automatically: per meal, per day, per week.

Practitioners could see at a glance whether the plan they were building met a client’s targets or needed adjustment. If a day came in low on protein or high on sodium, that was visible before the plan was sent, not after the client had been eating it for a week.

On the patient side, the recipe view was extended to show the nutritional breakdown of each meal alongside the instructions. Patients could see what they were eating, not just what to cook — the carbohydrate count in tonight’s dinner, the protein in tomorrow’s breakfast, and how each meal was contributing to the week’s overall picture. The educational value of the plan increased significantly because the data was visible at the point the food was being prepared.

The extension was designed to sit transparently inside the existing workflow. Practitioners who had been building plans already found that the nutritional totals simply appeared alongside the planning they were already doing — no additional steps, no separate tool, no manual calculation required.

The outcome

The manual calculation work that had been an implicit tax on every plan — hours of arithmetic that practitioners either absorbed into their working day or quietly dropped in favour of approximate guidance — was removed. Plans that met specific macro and micronutrient targets became as straightforward to produce as plans that simply listed appropriate meals.

For patients, the nutritional transparency changed the nature of the engagement. Understanding why each meal was on the plan, and seeing how the week was designed to meet their specific requirements, produced a more active relationship with the guidance. Eating to a plan is easier when the reasoning behind it is visible.

The macronutrient extension was not a new product — it was an addition that made the existing platform more clinically useful at no additional cost to the practitioner’s time. That is the right kind of capability expansion: solving a real constraint without creating a new one.

Related