2026-03
My Process for Choosing a Tech Stack
A quick breakdown of how I choose my tech stack depending on the project, constraints, and what I want to optimize for.
Valentin Afonso
Fullstack developer
Choosing a tech stack is something I’ve refined over time. I don’t believe there’s a perfect stack—only the one that best fits the context of the project. This is basically a note to myself on how I make decisions depending on:
- the type of project
- the complexity
- the time constraints
- and my own experience
This will probably evolve over time as new tools and frameworks emerge.
MVPs, POCs, Fast Apps
When I want to move fast and avoid overthinking things, I usually go with a full-stack framework. My go-to choices:
Why:
- everything is already wired together
- fast to bootstrap
- fewer decisions to make
- good balance between flexibility and productivity
The goal here is simple: ship fast without friction.
Landing Pages & Static Websites
For simple landing pages or static sites, I almost always go with Astro. Why I like it:
- extremely lightweight
- very fast by default
- no unnecessary JavaScript shipped to the client
- no heavy abstractions or “magic”
It also allows me to integrate React components easily when needed and to keep things simple while staying flexible. So it’s perfect for marketing pages, blogs or content-driven websites.
(I’ll probably write a dedicated article on why I love Astro.)
CMS (Content Management)
When I need a CMS, my choice depends on the context:
Personal projects (free & simple)
Professional projects
Why:
- better flexibility
- more robust APIs
- more scalable content structures
E-commerce
For e-commerce projects, I personally use PrestaShop.
- open-source
- based on Symfony
- covers ~99% of e-commerce needs out of the box
The main reason I choose it is simple:
it’s the tool I know best and the one I can rely on.
Sometimes, familiarity and reliability > trendiness.
Databases
I usually choose based on the structure and scale of the data:
Simple / unstructured data
Scalable / structured / serious projects
My rule of thumb:
- flexibility → MongoDB
- structure & reliability → PostgreSQL
Backend
Fast & lightweight APIs
More complex backends
Again, it depends on:
- complexity
- scalability needs
- how much control I want
Libraries I Like to Use
These are libraries I often include in my stack:
They help me move faster, keep things structured and avoid reinventing the wheel.
Final Thoughts
My stack is not fixed. It evolves with my experience, the projects I work on and the ecosystem itself. What matters most to me:
- choosing tools that fit the problem
- staying productive
- and keeping things maintainable
I don’t try to use the “best” tools. I try to use the right ones for the job.