← Back to blog

How we choose the stack for a new project (without chasing trends)

Daniel García·

Every time a new project kicks off at the agency, someone suggests trying the trendy tool of the moment. This year there’s been a new framework every couple of months, and honestly, I don’t even bother learning all the names anymore.

The question that actually matters isn’t “what do the big companies use,” it’s “who’s going to maintain this two years from now, and with what budget.” That rules out pretty quickly a lot of options that sound great in a talk but require a dedicated team just to keep them up to date.

For a small client with a product catalog and low traffic, I set up a static site with Astro and that’s it. For a CRM with real business logic, Symfony on the backend and a Vue front end, because that’s what we know well and what we can debug at two in the morning without reading through documentation. And yes, I’ve been asked more than once why we don’t use whatever framework is trending, and the short answer is that I don’t have a single client for whom that would solve a problem they don’t already have solved.

This isn’t always true, mind you: there are projects where it’s genuinely worth venturing into new territory, especially if the client has their own technical team that will inherit the code and prefers something more modern. There the calculation changes, because someone with time to spare absorbs the learning cost.

What I never do is choose the stack in the first meeting. First I ask how much traffic they expect, who’s going to touch the code after delivery, and whether there are mandatory integrations (a payment gateway, a specific ERP, whatever it is). With those three answers, half of the “interesting” options I had jotted down already get ruled out.

In the end, the list of technologies we use at the agency is deliberately boring: Astro for static sites, Vue and Nuxt for applications with more logic, Symfony on the backend. Nothing that hasn’t been in production for years somewhere serious. And when something new proves it solves a real problem we have, it makes the list, but only after we’ve tried it on an internal project, not on the first paying client.

The next trend I’m going to ignore for six months before taking it seriously? There’s already a candidate, but I’d rather not give anyone ideas.

stackarchitecturetechnical-decisions