Choosing a Wise Tech Stack

As a software engineer, I've selected tech stacks many times. It's not as easy a choice as many might think. It's not just about trading off between tools, it's also about managing your emotions and aligning the decision with the product's growth.

Emotions Are Understandable, But Should Be Acknowledged

It's completely normal to have emotions when choosing a tech stack. After all, it's the tool you'll be working with every single day. Choosing technologies you don't enjoy can lead to dissatisfaction and burnout, and this factor shouldn't be ignored.

When you're responsible for choosing the stack for your team, the first step is to acknowledge that many of your preferences stem from feelings (denying it and reframing it as pure "personal preference" won't help 😅). Once you accept this, it becomes much easier to make wiser decisions, because you're no longer pretending the root cause of your choices is entirely rational.

Define "Growth" at Every Stage

In the end, your choices must support the one thing that truly matters: growth. However, growth means different things at different stages of a product.

In the early stages, growth often means fast delivery and quick iteration, sometimes at the expense of ruthless testing or immediate scalability. Later on, when the product has many users, growth requires a system that can reliably handle scale and high traffic.

As the person responsible for the tech stack, you should clearly define what "growth" means for your project right now, and be ready to reevaluate it as the product evolves.

Team Size and Technical Background

If you're ambitious and tempted by sophisticated architectures or full automation, pause and evaluate honestly:

• •Do you (or your team) have the expertise to implement and maintain it without burning excessive time and energy?
• •Is the product truly worth that level of effort right now?

A classic example is teams rushing into microservices for an MVP. Even with talented engineers, this approach often adds unnecessary complexity. Microservices require a specific team structure (squads owning individual services) to deliver real value. Most early-stage or side projects simply don't need it.

Your team's experience level is equally critical. Choosing a framework with a steep learning curve won't just slow development, it can damage morale as everyone struggles to learn and ship at the same time.

Complexity Spectrum

Different products have complexity in different places. A design tool like Figma is heavily UI-driven, while a payments platform like Stripe is backend-heavy. Spotting your own "hot spots" helps you:

• •Build a stack that supports growth where it actually matters.
• •Hire the right talent when the time comes.

One example is the choice I made with Elearner (a side project I've mentioned before). Since it is more UI-focused with simple backend requirements, maintaining a separate frontend and backend felt unnecessarily cumbersome. Why split them when I could build everything in one cohesive full-stack app? Next.js makes this natural and efficient with its App Router and Server Components.

Final Thoughts: Treat Your Tech Stack as the Foundation

Your tech stack is the foundation of your product, just like the concrete base of a house. Every future feature, improvement, and scaling effort rests on it.

It's perfectly fine (and often smart) to choose tools you're comfortable with or even genuinely enjoy working with. But never ignore delivery speed and long-term product needs. If your stack slows you down or creates friction as users grow, you're not just having fun with familiar tools, you're actively limiting your product's potential.