Enterprise software — operational context before code

My Rohlik work began in courier operations and dispatch. Daily work exposed gaps in operational visibility and tooling: useful information existed across systems, but was difficult to bring together at the point where decisions were made.

I began building a tool myself while central IT capacity was focused on other priorities. Close contact with the people using it made feedback direct and changes quick. Internal tooling, process design, international rollout and later full-stack work grew from that operational understanding; some roles overlapped.

The Internal Logistics Data Platform started as a C# Windows desktop dispatch tool, using a Visual Studio Forms-style interface. I later rewrote it for the web in PHP, JavaScript, HTML and CSS. Its audience expanded from dispatch to coordinators and management.

The platform combined operational information from multiple systems, capacity overviews, longer-route calculations and private mileage derived from telematics. It also brought together central operational records for courier business partners. These were tools for the relationship with those partners, rather than employee HR records.

The supporting interface below shows a quality-profile view. It illustrates one part of the product and does not demonstrate every capability described here.

I delivered the Courier Operations Portal after a public tender. The product stayed close to operations, where requirements changed quickly and feedback could be incorporated directly.

Couriers could view daily financial information, register for work and operational blocks, review ratings and performance, and access invoicing views and calculations. Management communication, acknowledgement of priority messages and document uploads connected administrative needs with the same working interface.

A multilingual UI supported these workflows. Integrations covered internal services through REST, legacy Google Sheets and an external financial service through REST. Barcode scanning supported returnable packaging, and an editable operational map supported CNG station information.

Operational certificate and QR validation introduced an encoded Base45 token format. A small Python service accepted and decoded the token into structured JSON for the portal workflow. Validity or status could inform eligibility, with an administrative override available.

This kept a temporary external format behind a small integration boundary while the PHP portal continued serving its existing workflows. It avoided rebuilding the portal for that requirement; the public example stops at the technical bridge.

One legacy PHP report produced a CSV bonus calculation. The operational team then processed the export and assigned bonuses manually. Moving the calculation required recovering the actual business rule first, rather than treating the export as just another query.

I reproduced and validated the old output, combined the required operational data and implemented rule evaluation in a Java / Spring service. An integration then assigned the bonuses automatically. Comparing the new output with the existing calculation was the basis for retiring that particular report after verification.

The new flow used route and attendance-like operational data, evaluated the rule and passed the result through an integration for bonus assignment. This example concerns one automated process, not retirement of the entire legacy system.

Work in PHP, Nette and Doctrine meant tracing behavior, data flows and the meaning of existing business rules. Establishing equivalent output before moving a rule made the old implementation useful evidence for the new one.

At Rohlik I used Hibernate / JPA and Flyway, alongside NamedParameterJdbcTemplate where tighter query control or performance requirements made direct SQL useful. ORM remained appropriate where it fit the model; specific queries could use a lower-level approach. This was a choice by use case, not a claim that ORM is generally slow.

REST and RabbitMQ were part of integration work. Google Cloud, OpenShift, ArgoCD and GitHub Actions provided delivery context. These technologies describe the work environment, rather than a claim of ownership of the entire platform.

Logistics process design, optimization and rollout supported international expansion in Czechia, Hungary, Austria, Germany, Italy and Romania. I translated operational requirements into software, reporting and monitoring needs while continuing work on internal tools.

That process scope provided broader domain context for engineering. It does not mean each application was deployed in the same way in all six countries.

At Generali Česká pojišťovna, my Java / Full-Stack Developer role ran from May 2025 to October 2026. Online insurance journeys across three non-life product lines involved broader full-stack work; campaign pages were mostly frontend-focused.

The implementation work used Java / Spring Boot, custom Liferay widgets and portlets, REST and API Gateway integrations, Hibernate / JPA and Liquibase. Kubernetes-based environments and Git/pull-request deployment workflows formed the delivery context. I also implemented, debugged and tested Salesforce Marketing Cloud integrations.

This was implementation and integration work within the existing enterprise environment, without a claim of ownership of the API Gateway, Salesforce or enterprise architecture. The chapter carries forward the context-first approach from logistics into customer-facing insurance workflows.