GuideHow a price change flows through your recipes
Change a vendor price once and it flows to every recipe built on that ingredient, directly or through a sub-recipe, recomputed within about a minute.
How does a price change flow through my recipes?
Change a price once, and it flows to every recipe built on that ingredient, directly or through a sub-recipe, the next time each one is opened, within about a minute. Nothing to re-run, nothing to re-key.
That is the whole idea, and it is the reason a cost in Misenlogic does not go stale the way a spreadsheet does. Most costing tools are right for a day, wrong for a month: they are correct on the day you type the prices in, then a vendor raises the price of butter and every recipe that touches butter is quietly wrong until someone re-does the math by hand. Misenlogic closes that gap. You update one vendor price, and the cost of every recipe that depends on that ingredient is computed fresh from the new number the next time it is viewed.
The rest of this page explains what "depends on" means, how fast the new cost appears, why you are never hunting for what a price change touched, and what happens to your margins once the cost moves.
What actually connects one recipe to another?
A shared ingredient. When two recipes use the same ingredient, that ingredient connects them: a change to its price is a change to both. Sub-recipes extend that same connection one level deeper. If your levain is a sub-recipe, and your sourdough loaf is built on the levain, then the flour price sitting inside the levain reaches the loaf through the levain. Change the flour once, and the levain re-costs, and the loaf that is built on the levain re-costs with it.
This is what "directly or through a sub-recipe" means. Misenlogic walks the full ingredient tree for every recipe and follows your sub-recipes as deep as they nest, a sauce inside a dressing inside an entree, all the way down. So the reach of a price change is not just the recipes that list the ingredient by name. It is every recipe built on it, at any depth, including the ones that only touch it through a sub-recipe two or three levels down.
You never draw that map yourself. The record already holds it. Each ingredient is tied to the recipes built on it, so the connections a price change follows are the ones your recipes already describe.
When does the new cost show up, and how fast?
The next time each recipe is opened, and within about a minute of the change.
Misenlogic does not store a cost as a fixed number that someone has to remember to refresh. It computes the cost from your current prices at the moment you view the recipe, so what you see is fresh at view time. When a price changes, the recipes that depend on it are marked to recompute, and that recompute lands within about a minute. Open one of those recipes and you are looking at today's cost, not last quarter's.
This is the difference that matters: competitors store a number; we compute it fresh. A stored number is only as current as the last person who re-keyed it. A number computed from your current prices is current by construction. There is nothing to run, nothing to re-enter, and no batch to remember at month end.
A note on wording, because it is easy to overstate. This is not an instant, streaming, or background push that repaints every open screen the moment you save. It is a fresh computation the next time each recipe is read, arriving within about a minute. On a large change that touches a great many recipes, the recompute works through them over a few minutes; each one is correct the next time it is opened.
Why am I never hunting for what a price change touched?
Because the record already knows. You are not the index.
When a vendor raises the price of one item that is used across dozens of recipes, the question that eats an afternoon in a spreadsheet is "which recipes did that just change?" You open file after file trying to remember where that ingredient shows up, and you miss the two sub-recipes that use it three layers down. Misenlogic removes that hunt entirely. The ingredient is already tied to every recipe built on it, so when its price moves, every one of those recipes reprices on its own. You do not go looking for the blast radius. It is already accounted for.
Worked through a single ingredient, it looks like this.
| Step | What you do | What Misenlogic does |
|---|---|---|
| 1 | Update the vendor price on one ingredient (say, bread flour) | Marks every recipe built on that ingredient to recompute, directly or through a sub-recipe |
| 2 | Nothing | Recomputes each affected recipe's cost from your current prices, within about a minute |
| 3 | Open a recipe | Shows today's plate cost and today's margin, computed fresh at view time |
One change on the left. The whole affected menu current on the right, without a re-run or a re-key.
What happens to my margins when a cost changes?
The margin on each recipe reflects today's number. Because the cost stays current, the margin you see on a recipe is measured against the target you set, using the cost as it stands right now, not a figure from the last time anyone re-costed it by hand.
That is worth being precise about. The margin is visible: open the recipe and it reflects today's prices against your target. Misenlogic does not, today, watch your margins and alert you when a recipe slips under target, and it does not produce a list of recipes that have dropped below their target margin. Margin alerting is on the roadmap, not a live feature. What is live is that the number you look at is honest: a recipe cannot hide under target behind a stale cost, because the cost it is measured against is the current one.
There is one more honesty signal worth knowing here. If an ingredient has no price yet, Misenlogic does not guess and it does not quietly plug in a zero. It marks the plate cost incomplete and tells you how many ingredients are still missing a cost, so a margin never reads better than it really is. A price change flowing through your recipes only ever moves real numbers; the gaps stay labeled as gaps.
Does it matter how deep my sub-recipes go?
No. Depth is the point, not a limit.
The reach of a price change does not stop at the first recipe that lists the ingredient. It follows every sub-recipe the ingredient sits inside, and every recipe built on those sub-recipes, as deep as they nest. A compound that goes into a sauce that goes into a dressing that goes into an entree still carries the price change all the way up. That is why you can keep your recipes structured the way your kitchen actually builds them, in layers, without worrying that a price change will reach the top-level items but miss the components underneath.
What a price change does not require of you
It is easier to trust the loop once you know what it never asks you to do. When a price changes, you do not re-open and re-save each affected recipe. You do not run a re-cost job. You do not re-key the new number into a second place. And you are not importing an invoice or a photo to make this happen: this page is about what occurs when a price on an ingredient changes, however that price got updated. You change the price once. The recipes that depend on it follow.
Where this fits
The maintained loop is the same engine behind the rest of Misenlogic. The cost it keeps current is the one your margins are measured against, the one that feeds your per-location food cost, and the same ingredient record that carries your Nutrition Facts and allergen data. And when you come aboard, your recipes, sub-recipes, and vendor items are moved over for you, reconciled line by line, so the loop starts on numbers you can trust. See the Misenlogic overview for how the whole record fits together.
Contact us for pricing
Misenlogic keeps every recipe's cost current, so a single price change reaches every recipe built on that ingredient without you hunting for it. Tell us about your operation, and we will scope it with you.