A polished meal-plan template leaves several buying questions unanswered. Where do its nutrient values come from? What changes when someone swaps a recipe? Can the team still identify the version it reviewed? For a functional medicine team choosing meal-planning software, those questions deserve a live demonstration.
Use this guide to test the authoring tool alongside your clinic’s existing record workflow. Bring a nonpatient recipe, the roles that will use the product, and a clear list of outputs to inspect. The aim is to leave with evidence and named gaps, rather than a list of checked feature boxes.
Key takeaways
- Trace a nutrient value to its food record and calculation basis; a database name alone is an incomplete answer.
- Change one input and inspect the recipe, totals, shopping list and final export separately.
- Name who can edit each version and where the clinic keeps its approved record.
- Record what was shown live, what was described and what remains unverified.
Evidence scope
This is an administrative procurement guide, not nutrition advice, a validated assessment tool or a report of vendor testing. The demonstration steps are recommendations. Your responsible dietetic, clinical and technical staff must set appropriate acceptance criteria. Use invented records in demonstrations; no real member information is needed for the exercises below.
Vendor pages are used only to describe advertised functions. They do not establish calculation accuracy, clinical suitability, security or performance in your clinic’s configuration.
Decide what the meal-planning tool will own
Products can combine different jobs. That Clean Life describes exporting recipes and meal plans as PDFs for use in practice-management software. Nutrium describes meal planning alongside client profiles with medical history and progress notes. These are vendor descriptions, not recommendations or independently verified capabilities.
Before comparing templates, write down whether you want an authoring tool, a connected member experience or a broader record platform. Then ask the vendor to show the boundary in the subscription and setup you would actually buy.
| Job | Decision to record |
|---|---|
| Recipe and meal-plan authoring | Who creates the working output, and which inputs belong in this tool? |
| Approved plan record | Where does the clinic preserve the reviewed version, its date and responsible reviewer? |
| Member-facing changes | Which changes can a member make, and how does the team distinguish them from its approved record? |
| Export and exit | Which files or structured records can the clinic recover, and what information travels with them? |
An exported PDF and an editable plan may serve different purposes. Decide which version staff should consult before asking whether an integration is available. An integration name does not answer who owns the record or how a later change is reconciled.
Trace one nutrient value to its source
USDA FoodData Central’s data-type documentation shows why provenance matters. Its Foundation Foods data use analytical values; Branded Foods draw on manufacturer label information. Its Food and Nutrient Database for Dietary Studies compiles food and portion information for dietary surveys. These data types also have different update cycles. This is one database example, not a requirement that every clinic use USDA data.
Ask the presenter to open one ingredient and identify its source record, version or update date, unit and portion basis. Check whether the selected entry represents a branded or generic food, and the raw or prepared form your test recipe requires. For a custom ingredient, ask who entered its values and how staff can find that basis later.
A missing value needs its own explanation. Ask the vendor to show an entry with an unavailable nutrient and demonstrate how the recipe and plan display it. Record whether the value remains unknown, is estimated or is handled another way. Do not assume a blank or zero has the same meaning across products.
Change the recipe and follow the calculation
Have your dietetic lead choose a simple recipe and document the inputs and expected calculation basis before the demo. Enter it, change the number of servings, then change one ingredient. Compare ingredient quantities, per-serving values and whole-recipe totals. Ask how units, rounding, preparation yield and custom entries are handled.
Keep calculation consistency separate from clinical suitability. A reproducible total can still depend on a food entry or assumption that does not fit the intended use. The responsible professional makes that judgment; a successful software demonstration cannot make it for the clinic.
Follow a substitution through every output
That Clean Life’s feature descriptions include recipe swaps, nutrition data and automatically updated grocery lists. Treat those labels as prompts for a demonstration of your proposed setup.
Ask the presenter to replace one recipe or ingredient while keeping the rest of your test plan unchanged. Follow that change through the ingredient list, quantities, nutrient display, shopping list, instructions and final exported or member-facing view. Where an output does not change, ask why. Where an update needs a manual action, record that dependency.
Include a clearly named restriction and a separate preference in the invented test record. Ask how the tool stores and presents each, and what happens when a suggested replacement conflicts with one. This tests information handling. It does not establish that a filter or replacement is safe or suitable for an individual.
Check who can change each version
Use the actual proposed staff and member roles, rather than accepting an administrator’s view as evidence for everyone. Ask who can create a recipe, change an ingredient, edit a shared plan and export a copy. If approval happens elsewhere, show how staff identify the authoring output associated with that approved record.
Then make a change after exporting the plan. Can staff find the earlier output? Does the shared view show a new version? Which changes, if any, reach the record system automatically? Capture what happens without assuming that a history screen is a complete audit trail.
Keep the recipe-tool test focused. For the wider delivery process, use our separate care-plan handoff worksheet to examine what happens after clinician approval, including member questions and open follow-up.
Map the data and export boundary
List the fields your team intends to enter and every destination that will receive an output. Include free-text notes, uploaded files, member identifiers and information passed through integrations. Ask which staff roles and supplier support roles can access them. Let your privacy and technical leads assess the actual arrangement; a general marketing label is not an answer about your configuration.
Test an export before procurement. Open the resulting file outside the product and check whether it retains the recipe content, quantities, source or version details, dates and any notes the clinic needs. Ask what remains available after cancellation, in which format, for how long and under which contract terms. Record unanswered points for the responsible owner to resolve.
Take one repeatable script into the demo
Use the same inputs and tasks for each shortlisted product. Record the offered plan or tier, configuration, date and presenter. For each substep, distinguish shown live, described, needs configuration or integration, manual and not demonstrated. More than one label can apply to a scenario when different substeps have different evidence.
| Scenario | Ask the presenter to show | Record the unresolved point |
|---|---|---|
| Source trace | Open a food entry and identify source, portion basis and update information. | Missing source details, custom-entry ownership or unknown-value handling. |
| Recipe calculation | Change servings, units and one ingredient; compare the affected totals. | Unexplained assumptions, rounding or steps that need a separate check. |
| Substitution | Swap one item and inspect ingredients, totals, shopping list and final view. | Outputs not shown, manual updates or a requested constraint not represented. |
| Permissions and versions | Repeat an edit with the proposed roles; find the earlier exported version. | Unverified role behavior or uncertainty about the authoritative version. |
| Export and exit | Open an export outside the tool and identify what can be recovered on exit. | Missing content, return format, access window or unresolved contract terms. |
For each row, add these fields to your notes: Substep, Demo status, Evidence seen, Responsible role and Gap / next action. Keep the observation attached to its substep so one successful action cannot hide another that was never shown.
Example: consider a demo in which a serving change is shown live, the replacement ingredient’s source is only described, and the final export is not demonstrated. Record three substeps: serving recalculation — shown live, before/after totals seen, dietetic lead to assess; ingredient source — described, no source record seen, vendor to provide it; final export — not demonstrated, no file opened, technical lead to arrange a recheck. This is a constructed example, not a result from testing a product.
Make the procurement decision from the gaps
After the demo, compare the evidence with the requirements your team set beforehand. For each material gap, name the owner, the evidence still needed and whether the clinic can proceed while it remains open. Keep “not demonstrated” separate from “not available”: the first describes your evidence; the second requires a supported answer about the offered product.
A tool with limited record functions may fit an authoring-only workflow. A broader platform may be appropriate when the clinic deliberately wants it to hold additional information. The decision depends on the jobs you intend to give it, the controls your team needs and the work required to connect or replace existing tools.
Before your next vendor meeting, agree on one test recipe, the proposed roles and the export you need to inspect. To discuss your clinic’s workflow boundaries with HolistiCare, book a demo.
References
- USDA. FoodData Central: Data Type Documentation. Used for the distinct sources and update cycles of food-data types.
- That Clean Life. Nutrition Planning for Health Professionals. Vendor descriptions of export, nutrition data, recipe editing, swaps and grocery lists; not independent validation.
- Nutrium. Nutrition Software for Dietitians. Vendor descriptions of meal planning and client-record functions; compliance and outcome claims are not adopted here.
