Why I Chose Express Again After Seriously Considering Fastify

Sometimes the best engineering decision isn’t choosing the newest technology. It’s understanding which problem you’re actually trying to solve.

Every Project Started with the Same Question

When I started planning the backend architecture for my latest project, I found myself asking a question that almost every Node.js developer eventually encounters.

Should I continue using Express, or is it finally time to move to Fastify?

It wasn’t a new question.

The same thought had already crossed my mind while building an e-commerce platform, designing a multi-tenant SaaS application, and developing a personal finance backend. Although each project solved a completely different business problem, I somehow ended up asking myself the same question every single time.

The more I researched, the more difficult the decision became.

Everywhere I looked, developers were talking about Fastify. Blog posts highlighted its performance, YouTube videos compared it with Express, benchmark charts showed impressive numbers, and many experienced developers described it as a modern alternative for building Node.js applications.

After seeing the same recommendation repeatedly, I started wondering if I was making the wrong decision by continuing with Express.

Not because I disliked Express.

Not because I had already decided against Fastify.

Simply because I wanted to understand why so many developers were making that recommendation.

So instead of switching immediately, I spent time reading documentation, watching conference talks, comparing community discussions, and trying to understand the reasoning behind those recommendations rather than blindly following them.

Looking back now, I’m glad I did.

Not because I changed frameworks.

But because that research changed something much more valuable — the way I evaluate technology decisions.

This article isn’t another Express versus Fastify comparison.

There are already plenty of excellent articles that compare performance, features, benchmarks, and ecosystem differences.

Instead, I want to share something much more personal.

I want to share how working on real projects gradually changed the questions I ask before choosing any technology.

Because, in my experience, the framework itself has rarely been the hardest part of building software.

The Hardest Problems Were Never About the Framework

While rebuilding the backend for an e-commerce platform, I spent far more time thinking about business rules than framework performance.

The application had to support multiple product variants, regional models, storage capacities, colors, inventory management, authentication, and order processing. The real challenge wasn’t serving another thousand requests per second. It was designing a system that could handle all of those relationships without allowing users to reach invalid or inconsistent states.

For example, if a particular storage option wasn’t available for a selected color, the application needed to guide users toward valid combinations instead of leaving them with a broken purchasing experience.

That wasn’t an Express problem.

It was an architecture problem.

Later, while working on a multi-tenant SaaS platform, the challenges became completely different.

Multiple businesses would share the same application, but every piece of data had to remain isolated. A mistake in tenant identification could expose another company’s information, making data isolation one of the most important responsibilities of the backend.

Again, the difficult part wasn’t the framework.

It was designing the architecture carefully enough that those mistakes could never happen.

The same pattern appeared once more while developing a personal finance application.

This time, the focus wasn’t on tenant isolation or product variants. It was making sure financial transactions remained accurate, relational data stayed consistent, and the API behaved predictably whenever users created, updated, or retrieved sensitive financial information.

Three completely different projects.

Three completely different domains.

Yet the hardest engineering problems had one thing in common.

None of them were solved simply by choosing a different framework.

That realization stayed with me.

The Question That Changed My Thinking

While researching Fastify, I noticed something about my own decision-making.

Almost every comparison on the internet started by asking,

“Which framework is faster?”

Without realizing it, I had started asking the same question.

But after reflecting on the projects I had already built, I realized I was trying to answer the wrong problem.

The better question wasn’t,

“Which framework has better benchmarks?”

It was,

“What is actually slowing this project down?”

Once I looked at my projects through that lens, the answer became surprisingly clear.

The biggest challenges had never been request throughput.

They had been business rules, architecture, security, maintainability, and designing systems that could continue growing without becoming difficult to understand.

At that moment, my perspective shifted.

Instead of comparing frameworks first, I started identifying the real engineering problems first.

Only then did I ask whether changing frameworks would actually help solve those problems.

That simple change in thinking has influenced almost every technical decision I’ve made since.

And honestly, I think it’s a much more valuable lesson than simply learning which framework is faster.

Because frameworks will continue to evolve.

New libraries will appear every year.

Performance benchmarks will change.

But learning how to evaluate technology based on real project requirements is a skill that stays valuable regardless of which framework becomes popular next.

My Research Started with the Wrong Question

After spending a few days reading articles and watching framework comparisons, I noticed something interesting.

Almost every discussion eventually focused on performance.

• Which framework handles more requests?
• Which one has lower overhead?
• Which one performs better in benchmarks?

At first, I was following exactly the same path.

If Fastify consistently performs better, shouldn’t that automatically make it the better choice?

For a while, I genuinely thought the answer was yes.

But then I stopped looking at benchmark charts and started looking at my own projects instead.

I opened my notes from previous projects, reviewed some of the architectural decisions I had made, and asked myself a much simpler question.

When did Express actually become the problem?

Surprisingly, I couldn’t find a single example.

That doesn’t mean Express is perfect.

It simply meant that, in my own projects, the framework had never been the bottleneck.

The difficult parts were somewhere else.

That realization completely changed the direction of my research.

Instead of comparing frameworks feature by feature, I started comparing them against the actual problems I had experienced while building software.

Looking Back at My Projects Changed Everything

The first project I reflected on was the e-commerce platform.

When I think about that project today, I don’t remember struggling because of Express.

I remember spending hours designing how products, variants, inventory, discounts, authentication, and orders should work together without creating inconsistent states.

One small architectural mistake could easily affect several parts of the application.

If a customer selected a storage option that wasn’t available for a particular color, the system needed to respond intelligently instead of simply throwing an error.

Similarly, pricing, stock availability, and product variants all depended on one another.

Designing those relationships correctly required much more attention than choosing the framework itself.

Express wasn’t slowing me down.

Understanding the business rules was.

The same thing happened while designing the multi-tenant SaaS platform.

The challenge wasn’t creating API endpoints.

Creating routes is usually the easiest part.

The difficult responsibility was ensuring every request remained within the correct tenant boundary from the moment it entered the system until the response was returned.

Authentication, authorization, database queries, file storage, and business logic all had to respect that same boundary.

A single mistake could compromise data isolation between businesses.

That’s the kind of problem I spent days thinking about.

Not request throughput.

Not framework benchmarks.

Architecture.

Then came the personal finance application.

Again, I found myself focusing on completely different problems.

How should financial data be modelled?

How can transactions remain consistent?

How should relationships between accounts, categories, and transaction histories be designed?

How should the API behave when multiple operations depend on the same data?

None of those questions disappeared simply because another framework was available.

The more I reflected on these projects, the more obvious something became.

The framework had never been solving my hardest problems.

What Actually Interested Me About Fastify

Although I eventually continued with Express, researching Fastify was far from a waste of time.

In fact, it helped me appreciate several ideas that I believe are genuinely valuable.

One thing that immediately caught my attention was Fastify’s emphasis on schema-based validation.

Rather than treating validation as something developers add later, Fastify encourages thinking about request and response contracts from the beginning.

I liked that philosophy.

Another aspect that interested me was its plugin architecture.

From the discussions and documentation I read, it became clear that Fastify encourages developers to organise applications with clearer boundaries and better separation of responsibilities.

As someone who enjoys thinking about software architecture, that approach immediately made sense to me.

Of course, performance is another area where Fastify receives a lot of attention.

Seeing those benchmark results naturally made me curious.

Any developer would want to understand why a framework performs differently and what design decisions contribute to that performance.

However, while reading more, I kept reminding myself of one important thing.

Everything I understood about Fastify came from research, documentation, and community discussions.

Not from production experience.

I think that’s an important distinction.

The software industry sometimes creates pressure to speak confidently about technologies we haven’t personally used.

I don’t want to do that.

I’d rather say,

“This is what I learned through research.”

than pretend I have experience that I don’t.

Ironically, I think researching Fastify taught me something much bigger than Fastify itself.

It reminded me that understanding a technology and having production experience with it are two very different things.

Both are valuable.

But they shouldn’t be presented as the same thing.

I Realised I Was Optimising the Wrong Thing

One evening, while comparing notes from my projects with everything I had been reading, I wrote down two questions.

What is technically impressive?

What actually helps me build better software today?

At first, those questions looked almost identical.

The more I thought about them, the more different they became.

A technology can be technically impressive while still not solving the problem you’re facing.

Likewise, a familiar technology can sometimes be the right engineering choice simply because it allows you to focus your attention on the parts of the project that actually matter.

That doesn’t mean we should avoid learning new tools.

Far from it.

It simply means we should learn them for the right reasons.

Not because everyone else is talking about them.

Not because benchmark charts make us feel like we’re falling behind.

But because they genuinely solve problems that our current approach cannot solve effectively.

That became my biggest takeaway from this entire experience.

I didn’t choose Express because I believed it was universally better.

I chose it because, for the projects I was building at that moment, it allowed me to spend more time solving business problems than learning a new framework under active development.

Looking back, I don’t think that was choosing the easier path.

I think it was choosing the more appropriate path.

I Stopped Asking, “Which Framework Should I Learn Next?”

Somewhere during this research, I realised that I had quietly changed the way I approach new technologies.

A year ago, my first question would probably have been,

“Should I learn this framework?”

Now, the question is different.

“What problem will this framework solve that I’m currently unable to solve effectively?”

That may sound like a small difference.

For me, it completely changed how I evaluate technology.

It also saved me from learning new tools simply because they were popular.

I don’t think there’s anything wrong with following industry trends.

In fact, staying updated is an important part of being a software engineer.

But I also believe every new technology comes with a cost.

There’s the obvious cost of learning new syntax and APIs.

Then there’s a much bigger cost that isn’t discussed as often.

Every new technology changes the way you think, the way you debug problems, the libraries you depend on, the documentation you read, and sometimes even the architecture of your applications.

That isn’t a reason to avoid learning.

It’s simply something worth recognising before making the switch.

The Checklist I Now Use Before Adopting New Technology

After working on different types of projects, I realised I naturally started asking myself the same questions whenever I considered introducing a new framework or library.

I don’t treat this as a strict formula.

It’s simply the way I now think about technical decisions.

1. What problem am I actually trying to solve?

This is always the first question.

Not,

“What’s the newest framework?”

Not,

“What is everyone recommending?”

But,

“What is causing friction in my current project?”

If I can’t clearly describe the problem, then changing technologies probably isn’t the solution.

2. Is this a real bottleneck or an imagined one?

When I reflected on my previous projects, I realised I had been reading about problems that my applications weren’t actually experiencing.

I was comparing request throughput before I had applications that genuinely required that level of optimisation.

Meanwhile, the real work was happening elsewhere.

• Designing business logic.
• Improving architecture.
• Thinking about maintainability.

Those areas deserved far more attention than benchmark numbers.

3. Will this reduce complexity or introduce more?

Every framework promises advantages.

The important question is whether those advantages outweigh the learning curve for the project you’re building today.

If adopting a new framework allows me to simplify an application, improve maintainability, or solve recurring problems more effectively, then it’s probably worth serious consideration.

If it mainly introduces unfamiliar concepts while leaving my actual challenges unchanged, I would rather postpone the switch until it brings clearer value.

4. Am I choosing this because it’s genuinely better for my project, or because I’m afraid of being left behind?

This was probably the most uncomfortable question I asked myself.

The software industry moves incredibly fast.

Every few months there’s another framework, another runtime, another database, another architecture pattern that everyone seems to be talking about.

It’s easy to feel like you’re constantly missing something.

I realised that part of my interest in Fastify came from that feeling.

Not because Express had failed me.

But because I wondered whether staying with Express meant I wasn’t progressing.

Looking back, I don’t think those are the same thing.

Learning continuously is important.

Feeling pressured to abandon tools that are still serving your project well is something different.

One Conversation Changed My Perspective

While thinking about all of this, I remembered something I’ve heard experienced engineers say repeatedly.

Technology decisions are rarely permanent.

That idea seems obvious now.

But I don’t think I appreciated it when I started building backend applications.

I used to feel like choosing a framework was a once-and-for-all decision.

As though selecting Express somehow prevented me from learning Fastify later.

In reality, software development doesn’t work that way.

• Every project teaches something different.
• Every architecture reveals new trade-offs.
• Every technology becomes another tool you can choose when the situation makes sense.

That mindset removed a surprising amount of pressure.

I no longer feel the need to chase every new framework immediately.

Instead, I want to understand why experienced engineers choose certain technologies for certain situations.

I think that’s a much healthier way to grow.

My Decision Wasn’t About Staying Comfortable

One assumption I often see in technology discussions is that choosing a familiar tool automatically means avoiding growth.

I don’t think that’s always true.

Sometimes staying with a familiar framework allows you to spend your energy solving problems that are far more important than learning new syntax.

During the projects I’ve worked on, I spent considerably more time thinking about data modelling, authentication, authorisation, API design, business rules, and system architecture than I ever spent writing route handlers.

Those experiences taught me something valuable.

Frameworks are important.

But they rarely define the quality of the software we build.

The quality usually comes from the decisions we make around the framework.

• How we model data.
• How we separate responsibilities.
• How we design APIs.
• How we think about security.
• How we prepare applications to evolve over time.

Those lessons remain valuable regardless of whether the project uses Express, Fastify, or another framework entirely.

That’s one of the biggest reasons I don’t regret the decision I made.

Because the time I didn’t spend switching frameworks was invested in becoming a better software engineer in other areas.

And I believe those skills will continue to matter no matter what framework I build with next.

Where I Go From Here

Does this mean I’ll keep using Express forever?

Definitely not.

In fact, researching Fastify has made me even more interested in learning it properly.

The difference is that my motivation has changed.

Earlier, I wanted to learn Fastify because everyone seemed to be talking about it.

Now, I want to learn it because I genuinely want to understand the design decisions behind it, experience its development workflow, and discover where it can solve problems more effectively than the tools I’m already familiar with.

To me, that’s a much stronger reason to learn any technology.

I don’t believe software engineers should become attached to frameworks.

Technology changes too quickly for that.

The frameworks we use today may not be the ones we’re building with five years from now.

What stays valuable is our ability to understand problems, evaluate trade-offs, and choose solutions that fit the situation rather than simply following trends.

That’s the kind of engineer I’m trying to become.

What This Experience Taught Me

Looking back, I don’t think the biggest lesson from this journey was about Express or Fastify.

It was about something much more fundamental.

I realised that good engineering decisions don’t begin with technologies.

They begin with questions.

Not,

“Which framework is the fastest?”

But,

“What problem am I trying to solve?”

Not,

“What is everyone using?”

But,

“What makes the most sense for this project?”

Not,

“What should I learn next?”

But,

“Why should I learn it?”

Those questions have quietly changed the way I approach software development.

They’ve influenced how I think about backend architecture, databases, libraries, cloud services, and even frontend frameworks.

The more projects I work on, the more I realise that learning a new technology is only one part of becoming a better engineer.

Learning how to evaluate technology is an entirely different skill.

And I believe it’s the one that lasts much longer.

Why I Decided to Write This Article

There are already countless articles comparing Express and Fastify.

Most of them are written by developers with years of production experience using both frameworks.

This article was never meant to compete with those.

Instead, I wanted to share something that I think many developers experience but don’t often write about.

• The uncertainty.
• The research.
• The second-guessing.

The feeling that maybe you’re falling behind because everyone else seems to be moving to something newer.

I’ve felt that too.

If you’re a student, a junior developer, or someone building your first serious backend projects, you’ve probably experienced it as well.

And if you have, I hope this article reminds you of something important.

You don’t need to adopt every new technology immediately to keep growing.

Growth isn’t measured by how many frameworks you’ve installed.

It’s measured by how well you understand the decisions behind the ones you choose.

My Next Step

This isn’t the end of my journey with Fastify.

It’s probably the beginning.

One of my goals over the coming months is to build a real project using Fastify from the ground up.

Not because I want to replace Express.

Not because I want to prove one framework is better than another.

But because the best way to understand any technology is to build something meaningful with it.

When that happens, I’ll probably come back and write another article.

Maybe I’ll discover that Fastify fits certain types of projects remarkably well.

Maybe I’ll realise some of my assumptions were wrong.

Or maybe I’ll find that both frameworks have their own strengths depending on the situation.

Whatever the outcome, I’d rather let real experience shape my opinion than form one too early.

Final Thoughts

One of the things I enjoy most about software engineering is that there’s always something new to learn.

• A new framework.
• A new architecture.
• A new design pattern.
• A new way of solving an old problem.

At first, I thought becoming a better developer meant learning as many technologies as possible.

Today, I see it a little differently.

I think becoming a better engineer is about learning why technologies exist, when they should be used, and what trade-offs come with every decision we make.

Express happened to be the framework I chose for these projects.

Fastify happened to be the framework that challenged my thinking.

But neither of them is the real subject of this article.

The real subject is something I hope I’ll keep improving throughout my career.

Learning to make better engineering decisions.

If you’ve read this far, thank you for taking the time to follow my thought process.

I’d genuinely love to hear how you evaluate new technologies.

Have you ever stayed with a familiar tool after seriously considering something new?

Or has switching frameworks taught you a lesson that changed the way you build software?

I’d enjoy hearing your experience, because conversations like these are one of the best ways we all continue learning.