Choosing a stack

A stack is the list of tools behind a site. For a back end, that's mainly a language, a framework and a database. Any mainstream stack can build almost any project, so the choice is rarely about what's possible. It's about people, time and money.

Five questions should decide it. Who will maintain it, and can you hire someone for it if they leave? How long must it live, knowing that each version of each tool has an end date for its updates? What should come ready-made, such as accounts, an admin screen or content editing? What's the way out, if you ever need to change provider or agency? And what will it cost over the years, which is mostly people's time?

Raw speed is the one reason people give most often, and the one that rarely decides. A stack is chosen in a few weeks, and lived with for years.

Who will maintain your back end depends on who you can hire, and the French market has its own shape.

On Free-Work, a French job board for IT freelancers and employees, Java was the skill recruiters searched for most in October 2026. On the day we looked, about 1,100 open listings mentioned Java and about 300 Spring Boot, against about 90 for PHP and about 60 for Symfony. That's one board on one day, but it matches APEC's 2026 study of job ads for developers at executive level, which lists Spring, Java's main framework, among the skills most asked for.

PHP tells a different story. W3Techs found it on about seven in ten of the websites whose server language it could detect, in October 2026. And in Stack Overflow's 2025 survey, by our count from its public answers, 12% of the roughly 1,400 respondents in France had used Symfony in the past year, against 4% worldwide. Symfony was created in Paris, and France is one of the five largest groups of PHP developers in JetBrains' 2025 survey. PHP and Java are both slightly more common in France than worldwide, while C# is less common: 20% of French respondents against 28%.

So for hiring a team, Java is the safe choice in France. For websites, PHP is everywhere, and Symfony especially so in France. Check your own city, though: hiring in Lyon isn't hiring in San Francisco.

The lesson Languages and frameworks showed two kinds of framework. Choosing between them starts from what your project needs ready-made.

A project with accounts, roles and an admin screen for the staff gains weeks from an all-in-one framework such as Laravel, Symfony, Django or Ruby on Rails. An API with one job, called by an app or by partners, needs little more than routes, and a minimal framework such as Express or FastAPI is enough.

Some projects don't need a framework at all. A site of pages that a team edits, such as news, events and a few forms, may be better served by a CMS like WordPress, with well-known plugins. And for logins, payments or sending emails, a ready-made service is often wiser than building them, because it's made by people whose whole job is that one thing.

Each piece written by hand is code someone must maintain for years.

Most back-end languages and frameworks cost nothing: Laravel, Symfony, Django, Ruby on Rails, Spring, Express and even Microsoft's .NET are free and open source. Some databases have paid licences, such as Oracle or Microsoft SQL Server, but free ones such as PostgreSQL and MySQL are the most used.

Servers cost a few euros to a few hundred euros a month for most sites. People cost far more. A day of an agency's or an experienced freelancer's work often costs €400 to €800 in France, as the lesson What kind of site explains, and a back end needs that work every year: updates, fixes and new features.

That's why a rare stack is expensive even when it's free. Fewer people know it, so they charge more, and replacing one of them takes longer. You end up depending on a few people. Compare stacks on the years of work they'll need, not on the price of a licence or a server.

Some pieces of a stack can travel, and some can't.

An open-source framework and a standard database, such as PostgreSQL or MySQL, can move to another host, and another agency or developer can take them over. Other pieces belong to one provider: Firebase's database, a no-code back end, an agency's own in-house framework, or a cloud provider's own services, made to run only on its servers. Leaving means rebuilding those parts.

That isn't always a mistake. A provider's tool that saves months of work can be worth depending on, if you choose it knowingly and know what leaving would cost. The lesson Who controls it covers the accounts, the contracts and the exports. For the stack itself, ask before you sign, while you still have a choice.

"This language is faster" is the reason people give most often, and it's rarely the real one. Benchmarks time languages on simple tasks. A real request spends most of its time waiting: for the database, for an outside service such as payment, or for the network. The language's own work is often a small part.

Some of the busiest sites in the world run on stacks that people call slow: Wikipedia on PHP, Shopify and GitHub on Ruby on Rails. Speed does decide for a few services with enormous, steady traffic. Uber wrote the service that finds which zone of a city you're in using Go, and on New Year's Eve 2015 it answered 170,000 requests a second at its peak. Your project is probably not one of those.

So when someone proposes a stack because it's faster, ask what is slow today, and where the time goes. Measure one slow request, step by step, before choosing anything.

These questions work whoever proposes the stack: an agency, a freelancer, a colleague or an AI agent.

Ask who will maintain it after launch, and what they already know. A stack the team knows well beats a better one that nobody knows. Ask how easy it is to hire for it, in your city, and at what rate.

Ask what it will cost each year: the hosting, and above all the people's time for updates, fixes and new features. Ask for the support dates of each version. Ask how you would leave, and which parts are standard or belong to one provider.

And ask why this stack. If the answer is "it's faster", ask for a measurement.