As a CAD developer and DMS implementer, I spent many years in a technical world of data, structures, bills of materials, and development-related processes. Moving toward ERP was therefore not a leap into the unknown, but a logical progression – an effort to understand company-wide processes in a broader context. How individual departments operate, how they depend on one another, and where unnecessary friction arises.

In this context, I began to focus more intensively on Odoo Enterprise. I was drawn to its modularity, openness, community, and the wide range of available learning resources. Documentation, tutorials, and open learning programs allowed me to explore the platform in depth, at my own pace, without being locked into a rigid ecosystem.

This was followed by a deep dive into the platform’s core configuration. Gradually, I became familiar with Bash, Python, and the overall system architecture. Naturally, one of the first areas that caught my attention was integration. The REST API works reliably and makes sense from a CAD integration perspective – connecting to external systems is realistic and technically clean. Along the way, I consumed tutorials, experimented, tested, and pushed my own boundaries forward day by day.

Meanwhile, I was already working as an ERP administrator in a Microsoft Dynamics environment, while also acting as an IT administrator. This gave me direct exposure to real business processes across the company – procurement, production planning and subcontracting, technological workflows, bills of materials, development project management, activity reporting, sales forecasting, KPI tracking, reporting, HR agendas, and approval workflows. Each of these areas became an opportunity to reflect on how processes could be made more efficient, simpler, and more transparent. The goal was never to replace an ERP system at all costs, but rather to build a vision of how things could evolve.

At a certain point, a practical opportunity arose – the legacy website had reached the end of its life and needed to be replaced quickly. Time was a critical factor.

If a company has access to robust infrastructure, fast storage, virtualization, and reliable security, an on-premise solution is often the natural choice. In our case, this option was not available. This led to questions about hosting, operating system selection, source code management, and operational responsibility. Alongside these considerations, a third path emerged – Odoo.sh.

A performance-scalable platform with built-in backups, production, testing, and development environments, GitHub integration, an administrative console, and system logs – all in one place and provided directly by the vendor. The decision was pragmatic. Instead of managing servers, I could focus on the system itself and on processes. At that moment, cost comparisons were not the primary concern.

Alongside this, an idea began to take shape – a smaller ecosystem, something like a club focused on ERP and CAD, custom products, add-ons, and collaboration between technical and marketing roles. I discussed this concept with the management of a technical high school, who would welcome such cooperation. At that time, however, other professional decisions took priority, and this vision remains open for the future. In the meantime, I continue to move Odoo forward on a smaller scale through micro-web projects such as chirosmedical.sk, fashionvictorystyle.com, or marravilla.com – where I configure the system, set direction, explain the concepts, and allow the project to operate independently.

This path is still ongoing for me. It is not defined by a single project or a single company. Rather, it represents a long-term way of thinking—one where discussion, sharing experiences, and learning from one another truly matter.