From container-glass production.

I come from container-glass production. That is where I learned where a recipe stops being a list of ingredients: at the furnace. Temperature, redox, cost and what the next shift finds all hang on the same decision. Split that into unrelated screens and you ship the fracture with the software.

So I do not start with the framework. I ask which booking must not vanish quietly after weighing, what one shift must leave the next, and which figure still has to match the hall in the evening. Only then does a data model appear.

In practice that often means: batch ticket, batch book, silo deduction, oxide calculation and daily log belong in one chain. A recipe version that held in the morning must not be silently replaced in the evening just because someone hit save. Changes apply forwards, not into the booked past.

W-Make Batch is the public evidence for that stance. The demo at batch.w-make.com shows the flow, not a client installation. Confidential volumes, recipes and plant data stay where they belong. Batchmaker Studio is the workbench beside it: the same domain core for recipes and glass chemistry, without silos, without shifts, without live bookings.

For a client that means someone who can explain the process before proposing an architecture. For a team it means I take the part where domain, data and operations meet, and leave it in a state another engineer can read.

I work from Germany, remotely and on site. I take cases where the flow matters more than the demo. My focus is industrial processes: production, material, recipe and handover. That is where my time and this site go.