A product shaped by operations.
My sport-school domain experience began during early CMT Soft contract work on Point Manager and evolved into SkiManager: a long-running product designed around what schools actually do at reception desks, on slopes and during seasonal traffic peaks.
Each tenant can configure school-specific roles, pricing and workflows while sharing one maintainable product foundation.
Reservation to settlement.
The core workflow connects reservation, pricing, payment and settlement. Around it sit lesson calendars, reception and POS operations, instructor availability, salary calculation, payouts, customer messaging and reporting.
- Roles cover administrators, reception, instructors and end customers.
- Dotpay, TPay, Stripe, OpenPayU and Przelewy24 support different market and customer needs.
- SMSAPI, Google APIs and PDF generation connect bookings to day-to-day school operations.
Modernization without a reset.
A clean rewrite was not compatible with schools relying on the platform through live seasonal operations. It would have delayed necessary infrastructure work while asking proven reservation, pricing, payment and settlement rules to be rediscovered all at once. I chose to modernize in place: introducing Docker, PHP upgrades, migrations, cron, backups, database tuning and load-aware architecture in controlled stages around concentrated winter demand. The trade-off is a longer path where older and newer surfaces coexist, in exchange for preserving proven domain rules and keeping each modernization step bounded by production reality.
Because I understand the product from domain rules through infrastructure, I can direct AI-assisted engineering across an older codebase safely: mapping dependencies, building verification gates and integrating selected AI workflows without pretending the legacy surface does not exist.