5 Years in Frontend: From Junior to Team Lead

I'm opening a blog on my portfolio. I'll be writing here about frontend architecture, Vue and Nuxt, NestJS, performance, code review, mentoring and the engineering decisions I run into at work. But before moving on to the technical topics, I'd like to say a little about myself.

My route into IT was not the typical one. I graduated from the Krasnodar Higher Military Aviation School with a degree in flight operation and use of aviation systems — a discipline where the cost of a mistake is high and processes are laid out as precisely as possible. That's where I picked up the habit of seeing a task through to the end, even when it turns out to be harder than it looked at the start.

I came into development through GeekBrains — first as a student, later as a mentor helping beginners find their way around their first SPAs. I realised very quickly that teaching others is one of the best ways to organise your own knowledge. That principle has stayed with me: the deeper you explain a topic, the better you understand it yourself.

How the stack came together

Like a lot of people, I started with HTML, CSS, SASS and JavaScript. My first commercial projects were built with React and Redux at Sarawan, where over time I started coordinating a small frontend team.

After that I spent almost four years at Idaproject, and that's where my core stack really took shape. Most of the projects were large internal systems, customer portals and complex interfaces, where performance, maintainability and the long-term life of the product all mattered.

The result is a toolkit that looks like this:

• Vue / Nuxt.js — for product development, complex interfaces and scalable SPAs;
• TypeScript — a mandatory part of any medium or large project;
• Node.js / NestJS + Prisma — when the job covers not just the frontend but the server side too;
• Pinia, Zod, Chart.js, Mapbox, Leaflet, Docker, PostgreSQL and MongoDB — the tools I reach for regularly on real projects.

Over these years I've worked on CRM systems, corporate portals, analytics dashboards, mapping services, marketplaces and internal products. It was that variety of projects that taught me to get up to speed in an unfamiliar domain quickly, and to look for solutions that will still work not just today but several years from now.

Right now I'm a Senior Frontend Developer at Kelnik Studios. My focus has shifted towards performance optimisation, refactoring core modules and growing existing projects. Less and less of my time goes into writing new features for their own sake, and more of it goes into keeping the system fast, understandable and comfortable to maintain.

Leading isn't management for its own sake

At Idaproject I grew into the Team Lead Frontend Developer role. Alongside development I was responsible for code review, took part in technical interviews, helped make architectural decisions, set up development processes and worked with the backend, design and analytics teams.

Over time I came to understand that the goal of code review isn't to find the maximum number of issues. It's to help the team write code that will be easier to read, maintain and build on six months or a year from now. A good review isn't an error check — it's an exchange of experience and a chance to make the project better.

For me leadership isn't about handing out tasks or controlling the process. It starts with creating an environment where developers understand the reasons behind technical decisions, aren't afraid to ask questions and gradually grow as engineers. It has always mattered to me that after a discussion a person walks away not just with a corrected pull request, but with an understanding of why that particular solution turned out to be the better one.

What I've taken away from these years

Over these years I've learned that a developer's value isn't measured by the amount of code written. It matters far more to understand the business problem, to spot potential technical debt in time, and to propose a solution that will still be clear and maintainable years later.

Good code isn't the most complex or the most clever. It's code that another developer can understand without trouble six months later, and that the team won't be afraid to change as the product evolves. That's the approach I try to bring to every project — from the first discussions through release and ongoing support.

What's next

This is only the beginning.

In the posts that follow I want to move from the story to the practice: breaking down the architecture of Nuxt applications, sharing experience with NestJS and Prisma, writing about performance optimisation, how to run code review, technical interviews, and the engineering decisions that keep large projects in working order.

I'll try to write not only about what to do, but why it should be done that way — with examples from real development work, the things that worked well, and the mistakes I've already had to fix once.

If you're interested in frontend, application architecture and an engineering approach to development — welcome to the blog.