Choosing the Right Tech Stack: A Developer's Decision-Making Guide

Introduction

Hello there, dear reader!

So, you’re at that spot, you’re beginning a new project and now, you have to choose which technology to go for. Do you go for the old and more reliable ones? Or you try out the new hot product on the market to see if it holds up to expectation?

Well, it’s part of the engineering process to discover how to handle these situations, and, different engineers are going to have different takes on this — you’re probably even familiar with a bunch of opinions from different creators on which tech choices to use.

The truth is that you have to discover what works best for you (and more specifically for the project), and, for me, there’s a 3-step process for you to choose things in a more assertive way:

1. Evaluate the project requirements
2. Evaluate the learning curve & tech characteristics
3. Evaluate costs

In this article, we’re going to go through examples of all scenarios, and, in the end, you’ll probably be able to choose by yourself and discover your own process in the middle of all that.

Evaluating the project requirements

While in my degree studies, I had a great professor who once said:

The problem chooses the tooling, not you.

Are you creating a simple portfolio for yourself? A dog-pig identifier algorithm? A huge SaaS that will have to handle a ton of requests at the same time?

All those cases impact heavily on the tooling you’ll choose. You can build a simple portfolio out of anything you want, even check out a bunch of cool stuff and random libraries, just for fun. That might not be necessarily compatible with the huge SaaS scenario though — so, here’s the first step catch.

Before thinking too hard about what are the awesome stuff being released (being that new frameworks or just new releases of old frameworks), try to think in terms of exclusion by requirement: Is there any particular project requirement that might exclude a technology choice? If so, why? And please, try not to fall for imaginary problems made by fans of certain technologies — You’ll probably hear it all: X doesn’t scale, Y is better than Z, A is ugly (and to be fair, we all have our favorites). Your job here is to step aside, get your rational goggles on, and think rationally about your decision.

Here are a few examples of solid tech choices that might suit some case for you:

Front-end

I love front-end and one of the things that excites me the most is the amount of things being released into it. You might think that’s a burden and a problem, but, my take here is that whenever people create a new solution to a different problem, they push the bar further — making everyone along the way have to run to catch up. Here are a few front-end technologies worth exploring:

• SvelteKit: Offers a compiler-based approach for building fast, efficient web apps
• Qwik: Focuses on near-instant load times through resumability
• React (and other meta-frameworks like Next.js): Known for its component-based architecture and virtual DOM
• Angular: Offers a complete solution with two-way data binding
• Vue (and other meta-frameworks like Nuxt): Praised for its simplicity and gentle learning curve
• htmx: Allows for dynamic content without heavy JavaScript frameworks
• jQuery: Still relevant for quick DOM manipulations and AJAX calls (and for checking out some legacy systems)

Back-end/Full-stack

On the back-end, there is a ton of great stuff being made, every iteration being more performant and even more focused on developer experience. Let’s check out a few projects worth checking out:

• Ruby on Rails: Emphasizes convention over configuration
• Laravel: PHP for Artisans
• Spring Boot (Java): Provides a robust ecosystem for enterprise applications
• Node.js: Allows JavaScript on the server-side
• Deno (v2): A secure runtime for JavaScript and TypeScript
• Encore: An open-source backend development platform that simplifies the entire backend development process, from API design to deployment.
• Hono: A small, simple, and ultrafast web framework for Deno, Bun, and Node.js

The important thing here is that: these projects exist for you to try out new things and fall in love. New solutions to old problems appear all the time, so, what you’re trying to catch is what they offer you — if you’re convinced some tech gives you enormous value, which generally comes in the format of performance and DX, you might consider learning it a little more deeper to solve the problem at hand.

Evaluate the learning curve & tech characteristics

POV: You, learning a new tech for the first 11000 times.

The learning curve is a really important point to measure as well. How well do you or others on your team know certain technology? Are they familiar or have they just heard of it?

Short-term productivity

You have to take that into account because it will directly impact your productivity, and, by a consequence, your deadlines. If you have a really tight deadline, it might not be the perfect time to test an entirely new tool you’re not sure will solve your problem, so, ask yourself: Is the learning curve of this tool a big impact on our dates? Do we already have knowledge in close spectrums?

Questions like these might make you exclude a few other technologies based on time itself — you might have to pick up new stuff later, on a smaller project, and that’s okay. Remember that learning usually has a slow start and mastery takes time to get, but, it might pay off in scale and easiness of maintenance.

Community Support

Another important consideration when evaluating the learning curve is the availability of resources and community support for the technology you're considering. Established technologies often have extensive documentation, tutorials, and a large community of developers to turn to for help. Newer technologies, while potentially offering exciting features, may have more limited resources, which can impact the learning process and troubleshooting — it might be amazing at first until you have to code a full calendar by yourself.

Thinking long-term

Lastly, consider also the long-term implications of your technology choice. My take on this is that you have to really be aware of stuff that has not released a stable version — things can change a lot and the last thing you want is having to write an entire project again just because all APIs changed.

Considering the costs

Another important aspect of the decision-making process is considering the costs. There is a lot of tooling out there that, although they might seem awesome, the infrastructure to host them easily might make you lose your mind.

Try not to think here only in terms of monetary value too. If with one technology choice you might spend hours/days working on setting up the infra and with other is just commands, well, your (or your engineer’s) time is valuable and, every second you spend working on things that is not the product, is time flying by.

---

For me, this is an awesome aspect of Encore, the sponsor of this article:

One of its standout features for me is the simplified infrastructure setup. Want to deploy things super quickly using their platform and paying something for it? The option is there. Want to self-host your docker images on your cheap 5$ VPS? There are docs on that too.

Easiness of deployment and separation of costs/concerns with clients are really important features (Encore sets up AWS/GCP infrastructure in your own — or your client's — account, for example), and, unfortunately, not every tech choice out there works on that, so, stay aware.

A good rule of thumb on this is before coding and starting the project with a tech choice, give a quick overview of the deployment section (if it looks hard as hell, that might be a red flag).

⚡ Check out Encore ⚡

---

So yes, spare a thought on deployment and infrastructure costs and they might spare you a few pennies/dollars every month or so ;)

Conclusion

Hey! You got to the end!

Well, I hope that you now find choosing the right tech stack a more exciting journey, and not an impossible task! Remember — it's all about finding what works best for you and your project. By evaluating your project requirements, considering the learning curve, and weighing the costs, you're well on your way to making an informed decision (which is the whole point here).

Don't be afraid to explore new technologies, there’s a BUNCH of cool stuff being released every day for you to check out, but also don't underestimate the power of established tools listening to those same tech gurus that are not shipping software. If it delivers a good solution, matches you or your team's skills, and doesn’t cost you more than you can pay, you’re probably on the right path.

So, roll up your sleeves, dive into the documentation, and start experimenting! Who knows?

You might just find your new favorite tool or framework along the way.