Your stack matters more than you think

If your tech stack only reflects what you can afford to do today, you’re cutting yourself off from new opportunities tomorrow.

While half of the world is on fire patching PHP, I spent the same time upgrading and extending my homelab setup.

As I’ve shared earlier, I built a tiny AI node on a budget earlier this year. After a bunch of experiments, I found what I liked and left it there. Working. Mostly idle.

At the same time, I noticed that I was using my OpenClaw agents more and more for coding. And coding requires a lot of builds and test executions. These are CPU-heavy operations, and my tiny EliteDesk node was struggling to chew through them. Meanwhile, my AI node had a perfectly capable CPU sitting idle most of the time. So why not use it?

I decided to extend my infrastructure, giving the agents access to additional computing resources without moving everything to a new machine. And that’s where my earlier technology choices paid off. I wasn’t limited to what the infrastructure was originally built to do. I had options.

But let’s get back to the technology stack.

The base, like the basement

A basement is a great and important place. It’s dark there. Nobody sees what’s inside until invited. Or until someone is determined to get there for their own reasons. And the basement is part of the foundation your house sits on top of. So its quality matters.

After spending years with PHP, I started questioning myself: do I really want to keep solving problems with a tool that I don’t think fits most of the cases I’m willing to solve?

That’s how I ended up switching to Go.

I imagined it as a step from PHP towards Rust, an emerging C-killer back then.

What I faced was a disaster. I literally wasn’t able to do very simple things because I was missing the concepts of Go. Not the syntax. The way of thinking about problems and solutions. It was humiliating.

But I didn’t give up.

And today, I believe goroutines are one of the best tools available for modern web development. Not because PHP can’t achieve similar results. But because in PHP, you often need additional tools, libraries, or architectural workarounds. Each team approaches these problems differently.

Some teams are afraid of making a wrong step. Others simply don’t know what they’re missing.

And that’s the problem.

Your technology stack doesn’t just determine what you can build. It shapes how you think about what is possible.

When a concept isn’t naturally available in your environment, you’re less likely to consider it as a solution.

And if you never consider it, how can you evaluate whether it’s the right one?

When common is too common

While standards are great, and I often advocate sticking to them, building different things the same way is not always a good idea.

We should learn this from nature.

There’s a reason why a whale is completely different from a sparrow. Not because one is meant to be better. They evolved to live in completely different conditions and environments.

And the human species is amazing because we can adapt. Probably like no other.

While we may struggle with physical conditions, mentally we have an enormous variety of options and adaptations.

But cutting to the chase.

Software needs to adapt, too. You can build almost anything with PHP and Laravel. You can build almost anything with C, Delphi, or Python.

But should you?

There is no single right answer. It’s always a combination of parameters. And qualified workforce is an important one for any manager. However, when price and availability become the only criteria, there is no real choice.

You start building your future around the limitations of your present. And the moment your giant falls, you’ll be falling with it. This doesn’t mean popular technologies are bad. Quite the opposite. They often have excellent ecosystems, established practices, and plenty of engineers who know how to work with them.

But popularity is not a technical requirement.

And the fact that something can solve a problem doesn’t mean it’s the most suitable way to solve it.

The question is not whether your stack can do something. The question is what it will cost you to build, maintain, and change it.

Let’s get a new stack

But before we do that, let’s think: what are we actually trying to achieve?

Let’s consider a few examples.

A landing page

We need a landing page with a few interactive scripts, maybe a form?

Make it static.

Use the same PHP or JavaScript to produce static output that can be hosted and served as HTML and JavaScript.

A simple web server. Bare minimum to get online.

Why introduce a database, an application runtime, and a complicated deployment process when you don’t need them?

A blog

Want to add a blog to your website?

Easy.

Find a blog engine that suits you. It doesn’t have to be WordPress.

You can integrate a static website into almost any engine or keep them separately, seamlessly linking them.

And here we come to an important distinction.

Diversification doesn’t mean using as many technologies as possible.

Running five different frameworks, three databases, and a bunch of services for a simple website is not diversification. It’s a maintenance nightmare.

Diversification means avoiding unnecessary dependencies and preserving your ability to make different choices.

Your blog doesn’t necessarily need to share the same runtime, database, or deployment process as your landing page.

But if keeping them together makes more sense, do that.

The goal is not technological diversity for its own sake.

The goal is to avoid turning every future decision into a consequence of one decision you made years ago.

E-commerce

Need e-commerce?

This is an area where PHP shines.

But be cautious about the engine choice.

You should consider performance, security, and architecture before opening a list of built-in features.

Everything is extendable these days.

But poor architecture and security can cost much more than a few additional modules.

And sometimes, choosing an established platform is exactly the right decision.

You don’t need to reinvent the shopping cart, payment processing, or order management just because you can.

The important part is understanding what you’re adopting, what dependencies you’re introducing, and how difficult it will be to change things later.

A good technology choice solves today’s problem without unnecessarily limiting tomorrow’s options.

The price of popularity

And remember: when you adopt something popular, you get its ecosystem, community, and support.

But you also become a potential target.

Adopting a popular technology means putting yourself in a group. A group that, at some point, becomes very promising to attack.

Because of old websites, insecure endpoints, simple passwords, and hardcoded credentials.

In 2014, I discovered that every website I put online was picked up by bots and scanned for…

/wp-admin

That stands for WordPress admin.

It’s not bad by itself.

It’s like wearing an expensive watch and carrying the latest top-model phone in a not-so-friendly neighbourhood.

You may be lucky. You may be smart or strong enough to protect yourself.

But the risks are there.

Of course, being less popular doesn’t automatically make a technology more secure. A custom application with poor security practices can be far more vulnerable than a well-maintained WordPress installation.

And a popular ecosystem may actually help you by providing faster fixes, security tools, and experienced engineers.

The real danger is not popularity itself.

It’s adopting something without understanding what you’re taking responsibility for.

Sometimes we get away with stupid mistakes because nobody is looking for them.

But once these mistakes become targeted, there’s no place for luck.

And the larger your dependency on a particular ecosystem, the more important it becomes to understand its risks.

What does AI change?

This article has been missing anything about AI so far.

So here’s the final take.

With AI, it’s easier than ever to learn new things, explore unfamiliar technologies, and build custom software.

The cost of trying something new has dropped dramatically.

But this works for both sides.

Attackers can explore vulnerabilities faster. Developers can generate software they barely understand. And an old, abandoned project might become a gateway to your current riches.

AI makes implementation cheaper. It doesn’t automatically make maintenance, security, or architectural decisions easier. And it certainly doesn’t replace understanding the concepts behind the technologies you’re using.

Remember my struggle with Go?

Today, an AI agent could probably have written the code I struggled with in minutes. But would I have learned anything? Would I have discovered new ways of approaching problems? Would I have developed the ability to recognize when those concepts could solve problems elsewhere? That’s the difference between getting code and gaining capabilities. And it brings me back to my homelab.

I didn’t need to replace my struggling EliteDesk with a more powerful machine. I already had computing resources available elsewhere. What I needed was the knowledge to connect them and the infrastructure flexible enough to make that possible. A technology choice I made for one purpose gave me options I hadn’t planned for.

Your stack is not just a collection of technologies. It’s a collection of possibilities and limitations.

Choose it accordingly.