Bakery Production Software: Why Wholesale Plans Break at 4am

Why bakery production software makes or breaks a multi-site operator

It is 3:40am at a commissary in an industrial park. The production manager has a laptop open to a Google Sheet called PROD_MASTER_v9_FINAL_USE_THIS. On the second monitor is the wholesale email inbox, where 40 standing orders arrived overnight from cafes, grocery accounts, and one distributor who still faxes to an email-to-fax number. She is transcribing quantities into the sheet by hand. Two mixers are idle because the sheet says the sourdough scale-up should have started at 3:15, but nobody told the sheet that the levain was slow last night. By 6am, the delivery van leaves either way.

The tool stack around this is usually some combination of QuickBooks for accounting, Square or Toast for retail, a shared drive of Excel recipe cards, WhatsApp groups per shift, and maybe BakeSmart, Cybake, or Craftybase if someone tried. Those tools are real and some are good at what they do. The problem is that none of them holds the one thing a commissary actually runs on: a single object that knows a wholesale order line, the recipe it maps to, the batch it will be produced in, the allergens in that batch, the mixer and oven time it needs, the lot codes of the flour and nuts that went into it, and the invoice line it becomes. Every tool owns one slice. The scheduler owns the joins, in her head, at 3:40am.

The leak is measurable. Across bakery and commissary projects we have delivered, the recurring numbers are: 6 to 10 hours a week of a production manager's time rebuilding the plan, 2 to 5 percent of wholesale revenue lost to shorts and credits because the plan and the orders drifted apart, and one to two full days of panic per year when a customer or an inspector asks which lot of almond flour went into which delivery. When that production manager quits, the operation loses the only working copy of its scheduling logic. That is the real risk. Not the spreadsheet, the fact that the spreadsheet only works because a specific human is standing next to it.

Problem 1: the production plan is a person, not a system

The plan is not really in the sheet. The sheet has quantities. The plan is the sequencing knowledge: the levain gets built the night before, the croissant dough needs a 12 hour retard so it must be laminated Tuesday for Thursday, the deck oven does bread from 2am to 5am and pastry after, the 60 quart mixer cannot do brioche and rye back to back without a wash. That is a scheduling problem with real constraints, and it lives entirely in one person.

Cybake and BakeSmart do production sheets, and they do them competently for a single-site retail bakery. What they do not model is your specific constraint set: your mixer count, your retarder capacity in racks not units, your two-stage preferment lead times, your commissary-to-store transfer windows. Their scheduling is quantity rollup, not capacity-constrained sequencing. QuickBooks does not pretend to try. So the workaround is the manager, and the manager is a single point of failure who takes vacations.

What a custom build does: model the constraint graph explicitly. Recipes get a bill of materials plus a routing, meaning each step has a resource (mixer 2, retarder A, deck oven), a duration, and a lead offset from the ship time. Then the planner runs backward from the delivery window. If Thursday 6am delivery needs 400 croissants, the system knows lamination must start Tuesday 2pm and that it collides with the danish run already on the sheeter, and it says so on Monday instead of you finding out Thursday at 4am. Constraint solving here is not exotic: a straightforward CP-SAT model over resources and time windows handles a 200 SKU commissary comfortably. The output is a per-station sheet that a new hire can follow, which means the scheduling knowledge now lives in the build and not in one head. This is usually the single feature that pays for the project.

Problem 2: allergens are tracked in a binder, and the risk is uninsurable

The scenario that keeps owners up: a cafe account calls and says a customer had a reaction to a scone that should not have had nuts. You have four hours to figure out whether it was a formulation error, a cross-contact on a shared line, or the customer eating something else. Your evidence is a recipe binder, a supplier spec sheet PDF folder, and a shift lead's memory of which oven ran what.

Off-the-shelf bakery tools handle allergen labeling. What they do not handle is cross-contact by sequence. The nut allergen on a scone is not just about the scone's ingredients, it is about the fact that the almond croissant ran on the same sheeter 20 minutes earlier without a documented wash. No product-level allergen field can represent that. Neither can a spreadsheet, because it has no concept of sequence on a resource.

What a custom build does: allergens attach to ingredient lots, propagate up the bill of materials automatically, and then propagate sideways through the schedule. The planner enforces sequence rules you define: nut-containing runs go last on a shared resource, or they force a wash task with a signed-off checklist before the next run. FDA FALCPA plus the sesame addition means nine major allergens to carry, and you carry them per lot, not per SKU, because your supplier can and will change a formulation on you. AI does one concrete job here: supplier spec sheets and certificates of analysis arrive as PDFs in a hundred layouts, and a document extraction pass reads the allergen statement, the lot code, and the expiry, then flags when a new lot's allergen profile differs from the last one you received. We have seen that catch a "may contain sesame" line that appeared on a flour spec after a mill changed suppliers. Nobody was reading those PDFs. The model reads all of them.

Problem 3: wholesale orders arrive in seven formats and one inbox

Standing orders by email. Changes by text to the sales guy's personal phone. One grocery chain sends an EDI 850. A distributor uses their own portal that you log into. A restaurant group emails a PDF PO. Someone calls. The order intake process is a human reading an inbox and typing into a sheet, and the error rate is exactly what you would expect.

Square, Toast, and Shopify are built for a buyer with a credit card, not a wholesale account with net 30 terms, tiered pricing, a standing weekly order, a delivery window, and a rep who negotiates. Even the tools with a wholesale module treat orders as a fixed list and cannot handle "same as last week but double the ciabatta and skip the rye." That is 60 percent of real wholesale traffic.

What a custom build does: one order object with multiple intake paths feeding it. A customer portal for accounts who will use one, which is maybe half. An email parser for the rest, because you will not get a bakery's cafe accounts to change their habits and you should stop trying. This is the second concrete AI job, not a chatbot but a structured extraction step: an inbound email or PDF becomes a draft order with line items mapped to your SKUs and the customer's own naming conventions learned over time, then routed to a human for one-click confirm. In our builds the confirm rate settles around 85 to 90 percent no-touch after a few weeks of corrections. The other 10 percent get a queue. Standing orders auto-generate against the customer's template with a cutoff time, and every accepted order lands directly in the capacity planner from problem 1, so the plan updates when the order does. That closes the loop the spreadsheet never could.

Problem 4: traceability is a two-day fire drill you fail

FSMA 204, the traceability rule, has a compliance date of July 2028 and covers foods on the Food Traceability List. Whether every SKU you make falls under it depends on your ingredients, and you should get that answered by a food safety consultant, not by a blog. But the operational reality is independent of the rule: your grocery accounts already ask for lot-level trace, and your insurer prices your recall coverage on whether you can produce it.

Nothing in QuickBooks or Square knows what a lot code is. Craftybase does batch tracking and does it decently for small-batch producers, but it does not connect a receiving lot through a preferment through a batch through a delivery to a specific customer on a specific route. That chain is the whole ask, and it breaks at the preferment, because a levain built Monday feeds batches on Tuesday, Wednesday, and Thursday, so one flour lot fans out across three days and 40 customers.

What a custom build does: receiving scans the supplier lot into inventory. Every batch consumes lots and produces a batch lot. Intermediates like levain and poolish are first-class lots that carry their parents forward, which is precisely the part off-the-shelf tools skip. The delivery manifest records which batch lot went to which stop. Then a trace query, forward or backward, runs in under a second: give it a flour lot, get every customer who received anything touched by it. Two days becomes two minutes. We build this as an append-only event log so nobody can quietly edit history, which is also what makes an audit go smoothly.

Problem 5: you do not know what a SKU actually costs, so pricing is a guess

Flour moves. Butter really moves. Your wholesale price list was set 18 months ago from a costing spreadsheet that used the butter price from the quarter before that. Somebody does a gut check once a year. Meanwhile your yields are theoretical: the sheet says a batch makes 96 croissants, the floor knows it makes 88 on a humid day and 92 otherwise, and nobody has ever reconciled that gap.

Costing modules in retail bakery tools compute standard cost from a recipe card. That number is fiction the moment your actual yield diverges or your ingredient price changes mid-month. It also ignores labor at the routing level, so a laminated product and a straight-dough product look similarly profitable when they are not.

What a custom build does: actual cost per batch from the lots actually consumed at the prices actually paid, plus routing labor at station rates, plus a yield variance the system computes because it knows planned output versus what the floor scanned in. Then the margin report is per SKU per customer, including the delivery cost of that customer's route. This is where operators find out that the 6am account across town at 22 percent margin is losing money after the van, and the boring grocery account at 31 percent is carrying the business. Demand forecasting on top of this is worth building only once you have 12 months of clean order history: forecast per SKU per customer per weekday, which handles the fact that Saturday is a different business than Tuesday, and feeds suggested production for non-standing accounts. Before you have that history, a forecast is a random number generator with a nice chart.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape for this category. A focused first release, meaning production planning with real capacity constraints, allergen propagation, and wholesale order intake including the email parser, runs $60,000 to $130,000 and ships in 12 to 16 weeks. That is a real system your 4am scheduler uses on day one, not a prototype. A full platform adding lot traceability, route and delivery management with a driver app, invoicing with QuickBooks or NetSuite sync, a customer portal, and costing and forecasting runs $150,000 to $400,000 phased over 6 to 12 months.

What drives price up specifically in bakeries and commissaries: the number of production sites and whether they transfer to each other, because inter-site transfers double the inventory model. EDI, because every grocery trading partner's 850 and 810 implementation is its own project, and each new partner is real weeks not days. Scale integration, if you want batch weights read off Mettler Toledo or Ishida equipment rather than typed. Label printing, because Zebra or Epson label layouts with per-lot allergen and nutrition panels are fiddly and legally sensitive. Route optimization, if you have more than about six vans. And the biggest one, which is not software: how many of your recipes exist only as a person's habit. If we have to sit with your head baker for three weeks to write down what a batch actually is, that is discovery time and it is not optional.

What keeps price down: starting with one site, one shift, and your top 40 SKUs by revenue. That covers most of the money and all of the learning.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you are a single-location retail bakery under about $3M with a small wholesale tail. Square for Restaurants plus Craftybase plus a good spreadsheet is genuinely enough, costs a few hundred a month, and a custom build would be a vanity project. Same answer if wholesale is under 25 percent of revenue: your problem is the counter, not the plan. Cybake and BakeSmart are also reasonable if you are a fairly conventional multi-site retail bakery whose production is stable and whose wholesale is simple standing orders with no allergen sequencing complexity. If the shoe fits, wear it.

Here is our position on when it is time to build, and we will state it plainly. Build when two or more of these are true. First, wholesale is over half your revenue and you are above roughly $8M. Second, your production plan requires a specific human and you cannot take a two week vacation without risk. Third, you make nut, sesame, or gluten-free products on shared equipment, which means your allergen risk is a sequencing problem no product-level tool can touch. Fourth, you have been asked for lot-level traceability by a customer and you improvised the answer. Fifth, you run more than one production site and transfers between them are managed by text message.

The tipping point is not feature checklists. It is that at a certain scale, the coordination logic between orders, capacity, allergens, and lots becomes the actual business, and you cannot outsource your actual business to a tool built for someone else's constraints. Off-the-shelf software encodes a generic bakery. Above a certain size you are not a generic bakery, you are a specific manufacturing operation, and the gap between those two is filled by people doing manual work at 4am.

How to choose a developer for bakery and commissary software

Ask them to whiteboard your data model before you sign anything. A developer who has done this will draw ingredient lot, recipe with bill of materials and routing, batch, intermediate lot for levain and poolish, and finished lot, and they will know why the intermediate is the hard part. A developer who draws "products" and "orders" has built an ecommerce store and is about to learn food manufacturing on your budget.

Ask specifically how they will handle allergen cross-contact by production sequence, not by product field. If the answer is a checkbox on the SKU, they do not understand the risk and you will be back in a binder within a year.

Ask what they have actually integrated. QuickBooks Online and Desktop are different problems. An EDI 850 from a grocery chain is a different problem from a Shopify webhook. Scale and label printer integration means someone has driven serial and network protocols on a floor with flour in the air. Ask for the specific partner and the specific document type, not "we do integrations."

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else to work on it. Any developer who hedges on this is building a dependency, not a system. At Digital Heroes the code is yours from commit one, and we would tell you to walk away from anyone who says otherwise.