Choosing your tech stack: what our projects taught us
The question almost always arrives in the same form: “React or Vue?”, “WordPress or custom?”. It is rarely the right question. A tech stack is judged on what it costs and what it makes possible over the whole life of the project, not on the framework’s reputation the day the contract is signed.
Here are the criteria we use, then three client cases where a stack that looked right on paper turned out to be the wrong choice.
Which criteria should you use to choose a tech stack?
The guides on the subject overlap, and they cover the essentials. Four criteria really matter.
The nature of the project. A marketing site, a business application and a data processing API do not share the same constraints. The first depends entirely on its search ranking, the second on the reliability of its data, the third on its ability to handle load.
Who will write the code, and who will read it afterwards. The best framework is useless if nobody around the project knows it well. This applies to the contractor too: a technology they know inside out produces fewer bugs than a fashionable one they have never used.
The ecosystem. An active community, up-to-date documentation, maintained libraries. A component you have to write yourself because the ecosystem does not have it is a component you will maintain alone for years.
Expected load. An architecture sized for a hundred users becomes a bottleneck at ten thousand. But the opposite is far more common: an architecture sized for traffic that will never come, and that is expensive to run from the first month.
The criterion the guides forget: who maintains the project in three years?
A digital project spends a few months in development and several years in operation. That is where the choice of stack is paid for, or pays for itself.
The useful questions are not about frameworks but about what comes next. Who applies the security updates? What happens if the contractor is no longer available? Can another developer take over the code without rewriting everything? Where are the backups, and has anyone ever tried to restore one?
With a widely used stack, deployed from a Git repository and documented, these questions are already answered. With an exotic stack, or a site edited directly in production with no version history, every answer has a cost.
On the shop that changed hands, described below, there was no Git repository and no documentation, and deployments were done by hand on the server. Just getting a grip on it (recovering the credentials, understanding how the site was deployed and what the modules did) took three days of work before the first fix.
Three cases where the right choice on paper was the wrong one
An online shop invisible on Google
A subscription e-commerce site had been built as an SPA (single-page application; React, Vue or Angular, the problem is the same). The code was clean, the meta tags were correct. The pages were nonetheless poorly indexed: Google receives an empty page and has to run the JavaScript to see the content, which it does inconsistently.
The stack was right for an application. It was wrong for a site whose sales depend on Google search. The lesson we drew from it: if search ranking matters at all, we render pages on the server (Nuxt, Astro) and keep SPAs for internal tools.
After the fact, the fix is not a tweak: the way pages are generated has to be rewritten, which amounts to redoing a large part of the site. That is why this choice has to be made before the first line of code.
A device that ticked every box, on a network being switched off
A company operating unstaffed facilities wanted to give occasional visitors remote access to them. It had already bought a GSM controller whose datasheet covered everything: relays, power supply, SIM card, waterproof enclosure.
Two problems, independent of each other. The radio module was 2G only, while French operators are switching off 2G in mainland France between late September and late December 2026, according to the schedule published by Arcep, the French telecoms regulator. The device’s remaining life was a matter of months. And the device relied on a whitelist of caller numbers, with no API and no event log, which made temporary access (one hour, one person) impossible.
It was replaced by a 4G router with relays that can be driven through an API. A component can match every line of the specification and still be the wrong choice, because the network or ecosystem it relies on is at the end of its life.
A shop taken over, fifty-six plugins included
An online shop changed hands, WooCommerce site included. In the code: fifty-six plugins installed, including two for SEO, two for backups, one for remote site management installed by the previous contractor, and several custom modules whose author nobody knew.
The temptation was to rebuild everything. That was not the right decision: the shop worked, orders were coming in, payments were wired up. The problem was not WordPress, it was accumulation with nobody making the calls. The work consists of documenting, removing duplicates, taking back control of the credentials, and only then deciding what deserves to be rewritten.
The licences for these plugins came to nearly €1,500 a year, some of it on duplicates. The clean-up is done plugin by plugin, checking each time what the plugin actually does on the site.
When you should not change stack
The previous case illustrates a more general rule: on an existing project, replacing the stack is almost always more expensive and riskier than improving it.
A B2B distributor asked us to develop an API for its product catalogue. Its site ran on an end-of-life version of PHP, on an operating system that was also at the end of its life. The obvious move would have been to make the job conditional on a stack upgrade. We did the opposite: we delivered the API while staying compatible with the existing setup, and treated the upgrade as a separate matter, with its own budget and its own timeline.
The client got what it needed within days. Modernisation is still on the table, but as a decision the client makes, not as a precondition.
What we choose at Avalonis, and why
For a new project, our default stack has been stable for several years: TypeScript everywhere, Astro or Nuxt for anything that needs to rank, Vue for application interfaces, Node.js on the server, PostgreSQL for data. For flows between tools, n8n rather than custom code, whenever possible.
These are not the newest technologies. They are the ones whose limits we know, that other developers can take over, and that deploy from a Git repository onto servers we administer, with verified off-site backups.
That default has changed at least once. On one project, database migrations were SQL files run by hand. Two production incidents, on columns the model declared required but that older rows left empty, moved us to a versioned migration tool, which we now use without exception.
We do not impose this stack. If your team knows PHP, or your business runs on Shopify, the right stack is the one that fits what you already have. We explain this in more detail on our method page.
Three questions to ask about a proposed stack
Before you sign a quote, whichever agency it comes from, three questions are enough to tell whether the choice was thought through.
- Why this stack for this project? The answer should talk about your project, not about the framework.
- Who can take over the code if your contractor disappears? The expected answer: a Git repository you have access to, and documentation another developer can read.
- What happens in month six? Updates, backups, fixes: who does them, and on what terms.
If you are considering automating processes rather than building software, the same reasoning applies, with different tools: we covered it in why automate your business processes.
Frequently asked questions
What is a tech stack?
All the technologies that make a project run: language, framework, database, hosting and deployment tools. The word is literal: these layers are stacked on top of each other.
Which stack should you choose for an MVP?
The one your developer knows best, provided it is widely used. An MVP exists to test an idea quickly, not to prepare for hypothetical load. The one point not to neglect from the start: server-side rendering if the product has to be found on Google.
Should you choose the newest technology?
Rarely. A recent technology has fewer libraries, fewer available developers and documentation that keeps changing. It is justified when it solves a specific problem that established technologies do not.
Should you rebuild an existing site on a new stack?
Almost never as a first move. Documenting, cleaning up and securing what exists costs less and produces a result sooner. The decision to rewrite comes afterwards, based on what the clean-up revealed.
To have a stack proposal reviewed before you sign it, tell us about your project.