About
From container-glass production to software engineering.
I am Jan Wagner. I know the work at the furnace first-hand and today I build the software for it.
Software engineer for industrial processes · Germany, remote and on site
- 14 years in container-glass production, 8 of them on batch, recipes and shift operations.
- Development and operation of W-Make Batch and W-Make Recipe.
I come from container-glass production. You learn quickly there that a recipe is more than a list of ingredients: it determines temperature, redox and cost, and what the next shift finds at the furnace. Software that splits those things across separate screens creates new problems, however tidy it looks.
That is why I do not start with the framework. First I want to know which posting must not disappear after weighing, what one shift has to leave for the next, and which figure still has to match actual stock in the evening. The data model comes out of those answers.
In glass production this means that batch sheet, batch log, silo deduction, oxide calculation and daily log belong together. A recipe version that applied in the morning must not be overwritten by evening because someone pressed save. Changes apply from the moment they are made and do not rewrite days that have already been posted.
W-Make Batch is the result of working this way. The application covers the day from recipe version to day close. W-Make Recipe is the workbench beside it: the same domain core for recipes and glass chemistry, without silos, shifts or live postings. W-Make Batch runs at batch.w-make.com. Access is available on request.
Clients get someone who can explain their process before proposing an architecture. Development teams get someone who takes on the part where domain, data and operations meet, and leaves it in a state others can keep working on.
I work from Germany, remotely and on site. My focus is on industrial processes around production, material, recipes and shift handover.
- 01
Production first, then the interface
I map the working day of the melter, the batch operator and the shift lead. Which figure is needed at six, which at the end of the shift, which must nobody overwrite any more? That defines what the application has to do.
- 02
Postings are not deleted
A consumption that has changed silo and log stays on record. Corrections are made with a reversal, a cancellation or a reconciliation, so you can see later what happened. A soft delete only hides the mistake and leaves the stock wrong.
- 03
Calculations you can check
Oxide, redox, batch size and cost live in their own modules, separate from the interface and the APIs. If a figure is questioned later, the formula behind it is easy to find.
- 04
AI tools with fixed rules
I develop with AI tools and agents. That speeds up routine work, and the decisions stay with me. The rules are written down in the project, tests cover edge cases too, and client data does not go into a model.
- 05
Operations are part of the product
I plan migrations, backups, a shared shift start and a repeatable day close from the beginning. Bolted on later, these things get bypassed when it matters.
Do you have a process that runs on lists and side calculations today? Send me a few sentences about it. You will get a clear view of whether I can help.
Arrange a call