Why ibakepro will not change your prices or your allergen labels for you

There are two things ibakepro could do automatically and deliberately does not.

When a supplier price changes, it will not move what you charge. When an ingredient's allergens change, it will not change the allergen label on a product you have already published. Both would be straightforward to build. In both cases the work of computing the new answer is already done, sitting there, one click from being applied.

Neither is applied for you, and this post is the argument for why not, including the part of the argument that costs you something.

What actually happens when a supplier price moves

You open an ingredient and change its price. From that moment, without you doing anything else:

Every recipe that uses that ingredient is found, and so is every product built from those recipes, whether the ingredient sits in the product directly or a layer down inside a component. If flour sits in your sponge and the sponge sits in a tiered cake, the tiered cake is in the set. The new cost is written to each affected product: raw materials, labour, overhead, the total. Those numbers are updated everywhere they are read, including the per-unit costs and the figures your product list shows you.

Your sell price is not touched. It stays exactly where you put it.

Instead, the products whose numbers have drifted are flagged for price review, and each flag carries a suggested price: the price that would restore the target margin you set. If you have a target margin, a product is flagged when its frozen price has drifted from that target by enough to matter, so a fraction of a cent does not nag you. If you have not set one, it is flagged whenever the cost moves.

You review the flagged products when you choose to. On each one you can apply the suggested price, apply a different price you type yourself or dismiss the flag and keep the price exactly as it is. Applying is the only thing that changes a price, and only then is the new price pushed out to your storefront and everywhere else it appears.

There is one deliberate silence in there. If a cost cannot be computed at all, nothing is flagged and nothing is suggested. A tool that responded to a broken lookup by suggesting you sell a wedding cake for nothing would be worse than one that says nothing at all. The same applies in reverse for products you costed by hand rather than building from recipes: those are flagged so you know something upstream moved, and not one of your entered numbers is overwritten.

What actually happens when an ingredient's allergens change

You change the allergens on a pantry item. Again, immediately and without you asking:

Every recipe using that item has its own allergen set recomputed, quietly, in place. Every product downstream of those recipes is found and a new suggested allergen set is worked out for it, at the right level for each allergen, with the stricter level always winning when the same allergen arrives from two directions.

Then it stops.

The published label on the product does not change. Not the contains list, not the may contain list, not the processed in list, not the dietary flags and not the copies carried on each variant. What changes is a review flag, which records what the label says now, what it would say and the exact difference: which allergens were added, and which were removed.

Applying the change is the only thing that publishes an upstream allergen change onto a product, and the only thing that pushes the new label out to your storefront and search. A person editing a product can still set its allergens by hand. What cannot happen is the label moving without either. You can also dismiss the flag, which keeps your existing label and clears the alert.

Why the line sits there

An allergen declaration is a legal document. A price is a promise to a customer.

If a tool changes either one while you are not looking, it has not saved you work. It has taken a decision away from you and left you holding the consequences of it. When someone with a nut allergy reads the label on your website, the entity making that statement is your business, not your software vendor. When a customer sees a price go up between asking and ordering, the person explaining it is you.

That is the whole of the argument. The short version is on our origin story: both of these could be automatic, and neither is, because having a machine change a legal claim or a customer promise while you are not looking is not a feature.

The removals are the sharper half of the allergen case. An addition that published itself would be over-declaring, which is annoying and safe. A removal that published itself is a product that said "contains nuts" this morning and does not this afternoon, because a supplier's ingredient data changed upstream. That is a change no software should be allowed to make on its own, and the review flag is explicit about which allergens the new set would remove, because that is the line a human most needs to read before agreeing to it.

The price case is less dramatic and more common. Costs drift constantly. Ingredient prices move on almost every delivery. If the system chased each one into your sell prices, your storefront would reprice itself several times a month against numbers you never saw, quotes would go stale mid-conversation and the psychological price points you chose on purpose would be replaced by whatever restores a margin percentage. Deciding what to charge is one of the few genuinely strategic things a small bakery does. It is not a rounding operation. Repricing when ingredient costs move goes through why a cost rise is almost never the same size as the price change it justifies.

The honest cost of this

This is not free, and pretending otherwise would be the same dishonesty in the other direction.

It means there is a queue. Change one commonly used ingredient and you may flag a lot of products at once. Somebody has to work through them, and that somebody is you or a member of your staff.

It means an allergen flag is sticky, on purpose. Once raised it stays raised until it is applied or dismissed, even if a later recompute happens to agree with your published label, because an earlier unrelated change may have raised it and quietly clearing it would hide that.

And it means that if you ignore the queue, your prices go stale and your allergen labels go stale. The system will keep telling you. It will not act. That is the trade, stated plainly: you get the guarantee that nothing published changed without a person, and you take on the obligation to be that person.

If you would rather not carry that, the review queue is the cost to weigh before you commit. What to look for in bakery software covers how to make that call.

Where we do automate, and why that is not a contradiction

This is not a philosophy of doing nothing automatically. Plenty happens without you.

Costs cascade on their own, from the ingredient through the recipes that use it to the products built from them. Recipe allergen sets are recomputed on their own when an ingredient's allergens change. Allergen declarations roll up from a pantry item through components to products and onto order lines as things are built. A price you have applied is pushed out to your storefront and everywhere else it appears, so nobody is left looking at a number different from the one that will be charged.

The line is not "automatic versus manual". It is narrower than that, and it is consistent:

Computing is automatic. Publishing a claim a customer will rely on is not.

Everything a machine can work out reliably, it works out, immediately and everywhere it applies. The single act of putting a legal declaration or a price in front of a customer is reserved for a person, because that act is the one carrying the liability, and liability does not transfer to the software that made the change.

The mechanics of both sit on their own pages if you want the detail: allergen management and recipe costing.