Case study
How We Helped Autix Tame Technical Debt and Find a Path Out of the Monolith
Autix’s mission is to build a robust Dealer Management System (DMS) for car dealerships. The system covers practically everything — invoicing, warehouse operations, orders, spare parts catalog, and client data. From the start, however, they knew they had a problem: the application stood on a fragile technological foundation and wouldn’t hold up long-term without changes.
Problem
Challenges
01
- Technical debt. An application built on Nette with packages that were no longer maintained.
- Missing DevOps. No dockerization, no CI/CD, minimal testing.
- Lack of processes. The team worked mostly ad-hoc, without clearly defined procedures or rhythm. A methodology was needed to stabilize and clarify the development process.
- Business pressure. While addressing the issues, the client also wanted to rapidly develop new features to meet car manufacturers’ certification requirements.
Solution
Turning Point
Once it became clear that without technical restructuring the project would hit its limits, Autix decided to bring in external partners. The goal was to regain control of the project — both technically and process-wise.
02
Our Role
- Technical realignment. We prepared a Docker image for local development, set up CI/CD in GitLab, and introduced testing. Developers could finally work in a predictable environment.
- Process transformation. We introduced Scrum: sprints, stand-ups, grooming, retrospectives. The team began to operate systematically, and for the first time the business had a clear overview of what would be delivered and when.
- Architecture. We showed a way out of the monolith. We built the first small microservice in Symfony — an order form with full test coverage. It ran without issues and proved that the microservice path was realistic.
Result
The Result
03
- More stable environment = fewer firefights. Thanks to dockerization and CI/CD, incidents reported by clients decreased. The team could finally focus on new features instead of constant emergency fixes.
- Better communication = no more “we didn’t make it.” Scrum created clear expectations. The business finally knew what they would get every 14 days, and the number of “we didn’t make it” situations dropped dramatically.
- The first microservice = peace of mind for everyone. Isolated services meant that when something failed, the entire system didn’t go down. Less panic, fewer incidents, more room for growth.
- Team atmosphere. The air cleared. Suddenly everyone was pulling in the same direction with a clear vision and goal. The team evolved from ad-hoc reactive work into coordinated collaboration.
Opportunity
Lessons Learned
04
- Technical debt won’t wait. The sooner you tackle it, the sooner the business can rely on stable development.
- Monolith vs. microservices. When something fails in a monolith, everything fails. Microservices enable stability and faster innovation.
- Processes bring calm. A transparent Scrum rhythm meant the business finally knew where things stood.
- Technology choices must be made wisely. Nette showed its limits in this case — a lesson that the sustainability of the stack is crucial.
