N NoBullshit.wiki 中文

Bakery owner-operator - the per-SKU recipe cost card calculator: ingredients, labor, energy, and both loss rates rolled into what one loaf costs, with the price range coming out on its own (have a coding agent build it)

Works with:Claude / GPT-4 classCategories:BakeryLevel:Advanced Updated

Build me a single-file HTML per-SKU recipe cost card calculator
for a bakery owner-operator - opens straight in the browser, no
network, nothing to install, data stays local. The user is a
bakery owner, not an accountant.

Enter by batch, get results per unit:
1. Batch definition: product name, units per batch
2. Ingredient list: one row per ingredient - name / amount /
   unit (grams, milliliters, pieces) / purchase price (per kg,
   per liter, per piece, decimals welcome); the tool converts
   it all into per-batch ingredient cost
3. Packaging: same row shape (bread bags, boxes, stickers)
4. Labor: minutes per batch x hourly rate - my own rate gets
   entered like anyone else's, the owner's time is not free -
   spread over the batch
5. Energy: the electricity or gas for one bake, one estimated
   figure per oven run

Two loss rates (required - missing either one blocks the entire
calculation, the UI flags it red and stops; no skipping):
- Bake-loss rate: dough-to-loaf shrinkage and failed bakes
  thrown out, [%]
- Unsold writeoff rate: end-of-day unsold writeoffs and
  staff-purchase discounts, [%]
Entered and displayed as two separate fields, never merged into
one "total loss rate" - their causes and their fixes are
completely different.

Arithmetic and output:
- Unit direct cost = (ingredients + packaging) ÷ yield x (1 +
  bake loss) x (1 + writeoff) + labor share + energy share -
  every intermediate value displayed and expandable; click any
  figure to see where it came from; no black box that prints
  one total
- Price range: two target margin tiers, [tier one] and
  [tier two], each producing a suggested retail price, rounded
  to the nearest 0.5
- Sensitivity flag: mark the largest item in the cost
  composition and show what a 10% rise in that one item does to
  unit cost - the owner should at least know which ingredient
  has the shop by the throat

Other requirements:
- One-click copy of the card as plain text (paste into the
  recipe binder, send to a partner) and one-click print, A5
  layout, to sit beside the recipe
- A new product starts from a copy of an existing card, edited
  from there
- localStorage saves every card, with export to a plain-text
  backup
- Everything operable in one scrolling screen, usable on a
  phone

Constraints (for the coding agent):
- No user accounts, no cloud sync, no networking of any kind -
  data stays in the browser
- No built-in "industry reference costs" or "typical ingredient
  prices" - every unit price is entered by the user; the tool
  ships no fabricated benchmarks
- The formulas do not get buried in minified code - alongside
  the expandable intermediate values, every formula carries a
  readable comment in the code

Why it is written this way

Making the two loss rates required, with a red flag that blocks the calculation, is this tool's most important decision. They are the most skipped items in bakery costing, and they are exactly what separates bread from pastry: a scone shrinks little on the way out of the oven, a country loaf shrinks a lot; long-shelf-life categories run near-zero unsold writeoffs, fresh soft bread runs daily leftovers. Merging them into one "total loss rate" looks convenient but stirs together two losses with different causes and different fixes - bake loss gets fixed through technique and recipe, writeoff through bake volume and how the day's batches are scheduled. Merged into one number, both problems lose their handle.

Entering the owner's own hourly rate in the labor line is the honesty test of owner-operator pricing. Most owner-operators' cost cards do not contain the owner, so the computed "cost" runs low and pricing decisions sit on that illusion for years - the books never show a loss while the person gets steadily more tired, because the profit silently contains an unbooked wage. Energy gets its own line instead of being smeared into ingredient prices for the same reason: an hour of oven electricity costs the same no matter what is baking, and one estimated figure per oven run sits closer to the truth than any precise allocation.

Fully expandable arithmetic, with the formulas kept out of a black box, addresses trust. Cost numbers decide prices, and prices decide whether this shop lives well - a number that shows a conclusion without its process is one an owner will not use and will not dare to change. The sensitivity flag - largest cost item, plus what a 10% rise in it does to unit cost - is early-warning intuition for pricing: which one holds the margin, flour or butter, and the timing of the next price move starts from that number.

The constraint against built-in "industry reference prices" matches the whole site's principle: a fabricated benchmark is more harmful than none - users anchor on a number of unknown origin, and the tool's credibility goes down with it. Every unit price is entered by the user; the tool guarantees only that the arithmetic is right.

Variables

Variable What it means
Two target margin tiers The low and high pricing reference lines - volume movers answer to the low tier, signature pieces to the high; know which tier each SKU reads before quoting
Hourly rate basis How the owner's own rate is set - a common floor is what it would cost to hire someone to do the same work
Loss-rate starting values Where the two rates start - from your own scrap and writeoff records; with no records yet, fill them high rather than low

costingpricingtool