Tuukka is admirably capable of handling many things at once even in hectic situations, and of solving problems independently and proactively. On top of that, the quality and range of his work as a developer make him a real pillar of support for our team, someone we can always rely on.
— Product owner
Starting point
I worked on a public transport ticketing portal, built for people who needed to buy tickets and manage travel card value on the web instead of in an app. It was the kind of service people rely on for ordinary, practical tasks, which made the work feel grounded from the start.
My role
Our team owned the customer-facing application and a lightweight backend around it. For a long stretch, I was the primary developer on the project, which meant I was involved in both the day-to-day implementation work and the smaller design decisions that shape how an application holds together over time.
What I worked on
The work was not just about building individual features. I spent a lot of time keeping the application moving in a steady, usable direction while it handled real customer needs. That included flows for ticket purchases, loading value onto travel cards, and supporting both of those flows when buying for yourself or for someone else.
Technically, the application was a production Next.js app deployed as a Docker image on Azure. In practice, the job was broader than the stack. I had to think about what to build next, how to keep the code understandable, and how to make decisions that would still feel sensible later when the project had grown. Accessibility was also a constant part of the work, not something added at the end, which shaped both implementation details and the level of care the product needed.
What made it tricky
The ticketing portal was only one part of a much larger overhaul involving multiple companies and consultancies. That kind of setup can make silos feel normal very quickly, with too many handoffs and too many competing priorities. A big part of making the work succeed was keeping people focused on the same outcome and working across company lines instead of disappearing into their own corners.
The result
The result was a production application that supported real customer use on the web and kept growing over time instead of being treated as a short launch project. From my side, one of the most important parts was helping to shape the product into something anyone could use.
Accessibility became one of the clearest signs of that effort. The product was audited and improved to a point where it ended up as a finalist in an industry accessibility competition, which felt meaningful for a public-facing service like this. It also went through security review cleanly, which mattered just as much in a ticketing portal handling payment and transaction integrations.
What I took from it
I like projects where the work is visible, useful, and tied to everyday situations. This one reminded me that some of the most valuable engineering work is not flashy at all. It is careful product work, steady delivery, and making sure the software stays understandable for the people building it.