Fullstack: someone who is expert in nothing?

You have probably already heard this sentence:

“A fullstack developer is someone who is expert in nothing.”

A few years ago, I thought the same.

At that time, I was working mainly as a backend developer and I was spending a lot of time improving my technical skills. In this context, the idea that someone could master both frontend and backend sounded unrealistic.

For me, hiring a fullstack developer meant hiring a kind of “Swiss army knife”: someone able to do a bit of everything, but without real expertise.

But over time, my point of view changed.

What is a fullstack developer?

A fullstack developer is someone who can understand and work across the whole technical stack: frontend, backend, CI, and sometimes even infrastructure.

Contrary to what many people think, it does not mean being an expert in every domain. It means being versatile enough to understand how the different parts of a system work together.

Another term often used for this type of profile is a T-shaped developer.

A T-shaped developer has deep expertise in one domain, combined with a good understanding of the other parts of the system.

Over time, this is the type of developer I became.

Why I expanded my scope

At the beginning of my career, I worked mostly on the backend.

When I joined a software company, I started to realize that delivering a feature was not only about writing code.

You also need to think about deployment, scalability, monitoring, and how the system will evolve over time.

Step by step, I started to explore topics such as Docker, stateless architectures, continuous integration, and hosting.

Later, as a Tech Lead, my responsibilities became more transversal: mentoring developers, reviewing code, and improving the overall quality of the system.

To better support the team, I also began to learn more about frontend development: frontend architecture, testing strategies, and user experience.

I also started to spend more time discussing with product teams and users, and analyzing product metrics.

Understanding the problem before writing code became an essential part of my work.

When specialization creates silos

In some highly specialized teams, people gradually focus on a specific part of the system: frontend, backend, infrastructure, CI, and so on.

At the beginning of a project, this usually works well. The system is still simple, teams are small, and most people still understand the product as a whole.

But as the software grows, complexity increases.

And when everyone works mainly in their own area, the global understanding of the system slowly disappears.

Developers become dependent on each other to finish a feature: someone needs to modify the frontend, someone else the backend, and another person the infrastructure.

Work starts to happen more in sequence than in collaboration.

Each person waits for someone else to finish their part and, in the meantime, nothing reaches production.

Little by little, teams start delivering more slowly and deadlines become longer.

Not because developers are less efficient, but because the collective ability of the team to evolve the system decreases.

The value of a global vision

Being a fullstack developer does not mean being expert everywhere.

It means being able to understand the system as a whole.

This global vision helps create connections between different parts of the product, but also between people in the team.

A fullstack developer can collaborate more easily with frontend, backend, or infrastructure engineers. They understand the constraints of each part of the system and can help reduce some frictions.

In a team, this type of profile often helps break silos and improve collaboration.

From fullstack developer to product engineer

But technical skills are not enough.

To build useful software, you also need to understand the business and the users.

Building a technically perfect solution that solves the wrong problem does not bring much value.

For several years now, I have tried to go beyond the technical side by working more closely with product teams and users.

Practices like Event Storming help bring technical and business people together to better understand the problems we want to solve.

Today, we sometimes use the term Product Engineer.

A Product Engineer does more than write code. They try to understand the business needs, measure the impact of the features delivered, and make sure technical decisions stay aligned with the product strategy.

This is the approach I try to apply in my daily work.

Conclusion

Being expert in a single technical discipline is valuable.

But in complex systems, the ability to understand the system as a whole becomes just as important.

Fullstack developers are not a miracle solution.

But they often bring something extremely valuable: a global vision of the system and the ability to move across different layers of a product.

Over time, technical and organizational complexity accumulates.
And when a team loses this global vision, delivering software becomes progressively harder.

This is often when teams start to slow down.

It’s something I often observe in the teams I work with.