Step in detail
A step built through practice
A cross-functional role in ERP
At 1UP Distribution, I work on subjects ranging from business rules to interfaces used every day. Odoo modules require me to understand company processes, formalize exceptions with the people concerned, and turn those rules into maintainable Python models, XML views, and tests.
Connecting product, ERP, and infrastructure
This experience brings together several case studies: the migration from Odoo 16 to 19, internal business modules, the Symfony B2B site, and the Next.js corporate redesign. I also take responsibility for databases, CI/CD, and VPS servers. This scope forces me to reason in dependencies: a data, API, or interface change must remain compatible with users' work.
What this step is teaching me
Autonomy does not mean making decisions silently. It means moving forward, documenting choices, making risks visible, and seeking an arbitration before an assumption becomes an incident. The migration and business modules strengthened this method as much as they strengthened my technical practice.
Turning complexity into a work plan
The migration makes this change of scale especially visible: the ERP involved 20 direct internal users, 16 custom modules, third-party extensions, and numerous Studio customizations. It required three successive major-version migrations, checks on data and attachments, and stabilization after cutover. This experience taught me to break a broad responsibility into inventory, priorities, controlled trials, functional checks, and traceable decisions instead of confusing speed of execution with risk control.
Designing for the people who use the system
The related case studies are not isolated workstreams: business modules automate rules that may be known only by the teams, the B2B portal depends on ERP data, and the corporate site must make the offer understandable without degrading mobile access or published content. This continuity requires me to hold together the stated need, security and data constraints, daily use, and the ability to evolve the solution. The quality of a delivery is therefore measured as much by its behavior in real work as by its technical implementation.