Backend rescue work in systems that were already moving.

These projects are smaller than STS and UCCP, but they show a useful pattern: entering systems that already have momentum, finding the parts that block progress or create risk, and fixing them without turning every problem into a rewrite proposal.

• Ported an archive-service backend from an obsolete internal template to a newer CQRS/MediatR-based template while other feature work continued.
• Preserved API contracts where possible so frontend migration did not become a separate rewrite.
• Stabilized problematic authentication and role handling after a separate implementation proved unreliable.
• Updated an older Latvija.lv service to a newer government framework and fixed vulnerabilities found during the work.
• Replaced a shared static-variable leak with keyed, time-limited cache behavior to stop one user from seeing another user’s data.

The first project at Baltic Software Factory was a separate Latvian National Archive service site. I worked on the backend together with another developer while frontend developers, analyst, manager, and a mostly occupied senior developer supported the project.

The backend started from an older internal template with several developer-experience and structure problems. After raising those issues, I was assigned to port the project to the newer company template. That meant moving the existing backend and ongoing feature work into a CQRS/MediatR-based shape while trying to keep API contracts stable for the frontend.

Later I also worked on authentication and role handling after a separate implementation turned out to be unreliable. That work was not highly visible, but it mattered: access control bugs can quietly undermine the rest of a public-service system.

The next solo project was an older service running under the Latvija.lv government portal framework. The task was to update it to a newer framework version, fix known and discovered vulnerabilities, apply some UX fixes, and get it launched.

During the work I found a data leak. The service mixed MVC and API parts without a proper contract between them. Person-specific data was passed through a static variable; with the right timing, a user could see another user's data.

A full rewrite was outside the scope. The practical fix was to replace the hidden shared variable behavior with explicit keyed cache handling, lifetime policy, and eviction. The goal was not architectural perfection; it was stopping the leak and leaving a clearer mechanism for the next developer.

These projects prove a different kind of usefulness from greenfield ownership. I can join an existing delivery stream, identify where structure, auth, framework drift, or security behavior is creating risk, and make scoped improvements that move the system forward.