Choosing the Right Stack: Lessons From the Skald Migration

Every engineer has lived this moment.

You’re building fast, shipping features, gaining traction, and everything feels smooth — until one day, the system you crafted with love becomes the system that keeps you up at night. Suddenly, what once felt like a perfect choice now shows cracks, and you start questioning the foundation itself.

That’s exactly what happened to the team at Skald.
And it’s a story worth telling.

But before we get there, let me say something I repeat every time someone asks me:

“What stack should we use?”

My answer never changes:

“It depends.”

Because the truth is simple: no stack is perfect.
Every technology has a story — not of perfection, but of trade-offs.

The Seduction of Choosing a Stack

When we begin a project, choosing a stack feels almost magical. It’s like choosing a sword before heading into battle. There’s excitement, anticipation, and a little bit of ego involved.

Python?
Elegant, fast to write, a huge ecosystem.

Node.js?
Blazingly good at async tasks, excellent for I/O-heavy systems.

Go?
A concurrency beast with the simplicity of a hammer.

We choose based on speed, on comfort, sometimes on hype. And it works — until the day your system grows beyond the assumptions you made.

Engineering, after all, is not about writing code.
It’s about making bets on the future.

Skald: A Story of Growing Pains

When Skald began their journey, Python was the obvious choice. They wanted to ship fast, iterate quickly, build the idea, validate it, go to market. Python was perfect for that.

But as their platform evolved, something changed.

Suddenly they weren’t building a small prototype — they were scaling a real-time, high-I/O system. Concurrency became a core requirement. Traffic patterns shifted. Bottlenecks started appearing in places they never expected.

The team did what many teams do:
they tried to stretch their stack.

More optimizations.
More patches.
More architectural gymnastics.

But the truth was hard to ignore:

They were pushing Python into a battlefield where Node.js had a natural advantage.

Eventually, they faced a decision none of us like:
rewrite or die slowly.

So they did the painful thing — they migrated to Node.js.

Not because Python failed.
Not because Node.js is “better.”

But because their system’s story had changed, and Python was no longer the right character for that chapter.

Their migration was costly, uncomfortable, and humbling — but also transformative. And if you want to dive into the full journey, I strongly recommend reading their own account here:
https://blog.yakkomajuri.com/blog/python-to-node

It’s a story any engineer will recognize: the moment when reality forces you to rethink your assumptions.

Why My Answer Will Always Be “It Depends”

People often come to me hoping for a clear, absolute recommendation.

“Use this stack.”
“Use that framework.”
“Follow this architecture.”

But the truth is, good engineering has no silver bullets.

Choosing a stack is choosing a set of trade-offs.
Understanding a stack is understanding its limits.
Mastering a stack is being honest about where it breaks.

And the best engineers aren’t the ones who say “I use X for everything.”
They’re the ones who say:

“I know when X is right — and when it’s wrong.”

What We Can Learn From Skald

Skald’s story teaches us something timeless:

• Know your stack’s strengths.
• Know its weaknesses.
• Don’t force it to be something it isn’t.
• And when your project grows — reassess.

Stacks don’t fail.
We fail when we choose blindly.

This is why I’ll always answer:

“It depends.”

Because choosing a stack isn’t about trends or favorites.
It’s about building systems that survive their own success — without rewriting the entire foundation halfway through the journey.