Why Batch and Studio are two products

W-Make Batch and Batchmaker Studio share the core for recipe, raw material and glass chemistry. They do not share the cut. Batch carries silos, shifts, bookings and the day close. Studio carries versions, validation and the print-ready batch ticket. The split is not a marketing line. It follows from two different days.

The day in the hall begins with a clock, a stock position and batches that are no longer drafts after weighing. The day at the desk begins with a recipe version that may still change, an oxide calculation you want to inspect, and a ticket that is not yet booked. Forced into one product, hall rules apply to drafts or draft rules apply to stock. Both are wrong.

An example: in Studio a recipe version is allowed to fail. Validation is a step someone can see. In Batch, once batches are running on that version, it must not be silently replaced by a new one. Cost hangs on the version that was weighed, not on the one currently open in the screen. Mix the products and that silent replacement lands in the hall.

The other way round: pack Studio with silos and shifts and you force recipe work into an operations mode nobody needs at the desk. You open a shift in order to print a ticket. You maintain stock that is not stock there. The tool gets heavy, and the domain core disappears behind screens that belong to the hall.

Technically the boundary means: its own server, its own file, its own interface. The core for oxide, redox and batch size can be related. The booking must not. A ticket from Studio is a draft and a print-ready sheet. It is booked in Batch only when the scale and the silo join in.

For technical decision-makers: product boundaries are architecture. Ask which day is supposed to take place in the application before you merge modules because the core looks similar. Similar calculation is not a reason for the same operating model.