Logging production runs: turning materials into sellable stock
The moment you pour a batch of 12 candles, two things become true at once. You have 12 more candles to sell, and you have less wax, less fragrance oil, fewer wicks, and fewer jars than you did an hour ago. Most inventory setups capture the first fact and quietly lose the second, and that gap is where material counts go to die.
The fix is an old manufacturing idea scaled down to a workbench: the production run. This guide covers what a run is, why it forces a double update, why the record of past runs matters as much as the counts, and what doing it manually versus with an app actually looks like.
What a production run is
A production run is a recorded event: on this date, we made this many units of this product. If the product has a recipe, a bill of materials listing what one unit consumes, then the run tells you everything else. Twelve candles at 170 grams of wax each consumed 2,040 grams of wax, 204 grams of fragrance, 12 wicks, and 12 jars.
Large manufacturers call the surrounding paperwork a work order or an assembly build. A maker needs none of that ceremony, but the core of it, a dated record of quantity produced and materials consumed, is exactly as valuable at 12 units as it is at 12,000.
The double update problem
Every run should move two ledgers in the same moment:
- Materials go down. Each ingredient decreases by its recipe quantity times the number of units made.
- Finished goods go up. The product's inventory in Shopify increases by the number of units made, so they are sellable.
Miss either half and a specific failure follows. Update only Shopify and your material counts read high: the system says you have wax for three more batches when you have wax for one, the reorder happens late, and you find out mid-pour. Update only the materials and Shopify undersells stock that is sitting finished on your shelf, or you bump the Shopify number from memory days later and it drifts from reality.
The two updates belong together as one action. The whole design question of production tracking is how to make that one action cheap enough that it happens every single time, including at 9 pm after a market day.
Doing it manually
The common manual routine pairs a spreadsheet with the Shopify admin. After each batch you open the materials sheet, multiply the recipe by units made, convert units where needed, subtract each ingredient line, then open Shopify and raise the product's inventory by hand.
It works when it happens. The failure modes are human and predictable:
- Skipped updates. A busy weekend, three batches, a wholesale order to pack, and the sheet is now two batches behind with no indication of which two.
- Arithmetic and conversion slips. Six subtractions per batch, one of them involving grams and pounds, done in a hurry.
- No history. A bare quantity cell holds no memory. When the shelf count disagrees with the sheet, there is nothing to reconstruct from, so people shrug and overwrite the number, which resets the drift instead of explaining it.
You can strengthen the manual version considerably: keep a batch log tab where each row is a run (date, product, quantity), and let formulas compute current material levels from purchases minus the sum of logged consumption. Now the log is the source of truth and the counts are derived, which is genuinely better. The cost is that every update is still typed by a person, and Shopify still gets edited separately by hand.
Why the audit trail is the valuable part
It is tempting to see the run log as bureaucracy and the current counts as the point. In practice it is the reverse: counts are just the latest consequence, and the trail is what makes them trustworthy.
- Reconciliation. When a physical count says 1,600 grams of wax and the system says 2,100, the run history shows what should have been consumed since the last good count. That difference is a finding you can act on, an unlogged batch, an overpour habit, a spill, rather than a mystery.
- Waste becomes visible. Recorded consumption is theoretical usage. Comparing it against real shelf counts over time shows how much material disappears beyond the recipes, which is a real cost that belongs in your pricing. The math side of that is covered in calculating COGS for handmade products.
- Costs at the moment of production. Material prices change. A dated run can capture what that batch cost to make at the prices of that day, which is what bookkeeping and honest margin tracking want.
- Batch questions. For soap and small-batch food makers especially, "which run did this unit come from" comes up, whether it is a customer question, a labeling issue, or a supplier problem with one lot of an ingredient. A dated run log is the difference between an answer and a guess.
Doing it with an app
An app earns its keep here by collapsing the whole routine into one step. What to look for:
- Logging a run takes seconds: pick the product, enter the quantity, done.
- Materials decrement by recipe automatically, with unit conversions handled.
- The finished product's Shopify inventory increments in the same action.
- Every run is stored with its date and quantities, and adjustments are possible when a batch partially fails or a run was mislogged.
Disclosure: this is the center of Madestock, which we are building. You define a recipe per finished product, and logging a run decrements the materials and increments the finished goods in Shopify together, leaving an audit trail of every run. Materials live as records inside the app instead of as fake products in your catalog, and low stock alerts fire in material units so the reorder happens before the batch, and never during it. It is in development, with a free tier covering 10 materials and 3 recipes and a flat $29 a month Maker plan above that.
Habits that matter more than the tool
Whatever system you use, three habits keep it honest. Log the run when it happens, because a run logged tomorrow is a coin flip. Record the failures too, since a cracked batch consumed materials even though it produced nothing sellable, and skipping it corrupts the counts. And do a periodic physical count of your top three materials, because the trail is only trustworthy if reality occasionally confirms it. Get those right and the double update problem stops being a problem, and your material counts start meaning something again.