At the beginning, I was still asking the wrong questions.
The first instinct was familiar: map the law, wire a few automations, move some files around and let the reporting part happen at the end.
For a while it looked reasonable. Packaging data came in. Activities could be stored. Exports could be generated. From the outside it looked like progress.
Then the harder questions started to surface.
Could I explain where a reported quantity came from? Was the source data valid? What changed since the last report? Which version was actually submitted? Could the same result be reproduced six months later?
Could I explain why the report says what it says?
That was the point where the project changed.
Imports stopped being files that entered the system. They became data that had to be normalized, validated and sometimes rejected.
Products needed a consistent packaging model. Materials needed known codes and weights. Activity records had to connect operational quantities back to those products. Reporting periods needed to mean something beyond two dates in a database.
Slowly, what looked like an automation project became a data model and validation project first, with reporting as the outcome instead of the starting point.
Valid is not always correct.
One production issue made that lesson stick with me. The XML could be technically valid, and still carry the wrong reporting meaning.
That kind of mistake is dangerous because it gives a false sense of safety. The file passes. The export succeeds. Everything looks calm, until you realize the semantics are off.
Passing validation does not automatically mean you built the right thing.
:I use that lesson far beyond this project now.
I became unexpectedly fond of the boring parts.
The audit trail is one of them. It originally felt like something the product simply needed to have. Over time it became one of my favourite parts of the system.
Reports can be locked. Their data can be preserved. Changes leave a history. Corrections do not quietly rewrite what happened before.
It gives the product a kind of memory. I like that.
There is a temptation in software to celebrate everything that successfully passes through the system. Verpack Meldung taught me to appreciate the things that should not pass through it.
Complexity belongs under the hood.
Packaging compliance already comes with enough terminology, deadlines and edge cases. I did not want the interface to constantly remind the user how complicated the underlying process was.
So a surprising amount of the work became subtraction. Fewer decisions where a safe default could exist. Clearer states. Validation before something becomes a reporting problem. A dashboard that tells you what needs attention instead of showing everything the database knows.
Those were usually the moments worth stopping at.
Where it landed
Today, Verpack Meldung is a working SaaS product built around products, packaging materials, activity data and reporting.
It handles the path from operational data to monthly, quarterly and annual reporting, generates LUCID-compatible XML, preserves reporting history and keeps an audit trail around the important actions.
There are still things I want to improve. There probably always will be.
But it crossed an important line for me somewhere along the way. It stopped feeling like an idea surrounded by software.
It became a system. And I understand what makes it work.
Verpack Meldung is live, so there is no need to take the case study at face value. The product itself shows how the data model, reporting flow and interface came together in production.
Visit Verpack Meldung ↗
