Tech buzzwords: do you really need MongoDB, NoSQL, Next.js or a trendy stack?

Short answer: no, a trendy stack is not automatically the best stack. MongoDB, NoSQL, Next.js, Symfony, MySQL, Varnish and a PWA do not all address the same problem. You must first understand the business, the data, the user journeys, the operational constraints and the available budget. A proven technology can be the most modern choice when it reduces risk and allows the business to evolve.

The first trap: comparing technologies that do not play the same role

In project discussions, you sometimes hear: "We need NoSQL", "The site must be in Next.js" or "A PWA would be more modern". The problem is not that these technologies are bad. The problem is that they belong to different layers and are not interchangeable answers.

MongoDB is a document-oriented database. NoSQL refers to a family of databases that do not necessarily follow the classic relational model; MongoDB is just one of the possible options. Next.js is a web application framework based on the React ecosystem. Symfony is a PHP framework, often used to build the application and business core. MySQL is a relational database. Varnish is a caching and reverse proxy tool. A PWA mainly describes a way to make a web application feel more like a mobile app experience.

The first question is therefore not "which technology is the newest?", but rather: which layer is actually causing a problem and which solution solves that problem without creating three others?

MongoDB or MySQL: choose based on data, not reputation

MySQL is based on a relational model. It is very suitable when data has clear relationships, integrity rules and operations that must remain consistent: customers, orders, invoices, products, appointments or access rights. For many small business sites and tools, this structure is an advantage: it makes data readable, controllable and easy to use by professionals accustomed to this model.

MongoDB primarily stores documents and can be interesting when data structure varies a lot, when documents are naturally nested or when the application needs to absorb specific volumes and usages. This choice can be relevant, but it requires serious thought about modelling, indexing, backups, migrations and how the data will be queried over time.

The word "flexible" does not mean "without constraints". A database that easily accepts different structures can also make controls and evolutions more delicate if business rules are not documented. Conversely, the relational model does not prevent evolution: you can evolve a schema, add tables, version migrations and build an adapted architecture.

Next.js or Symfony: the framework does not replace product thinking

Next.js is often cited for its possibilities around server-side rendering, React interfaces and modern web applications. It can be a very good base when the project needs a rich interface, interactive journeys or a particular front-end architecture.

Symfony, for its part, provides a robust framework for building structured PHP applications: data models, business rules, forms, security, administration and integrations can be organised in a clear way. For a company that needs a manageable site, a business area or a long-lasting back-office, this approach can be perfectly current, even if it is less visible in trendy conversations.

It's not about declaring a winner between the two. A project can even combine several building blocks when this adds real value. But adding a front-end layer, an API and several deployment systems has a cost: more skills needed, more testing, more monitoring and more points to maintain.

The right framework is the one the team can design correctly, secure, evolve and troubleshoot. A brilliant interface built on an architecture that no one knows how to operate quickly becomes a management problem.

Varnish and PWA: useful building blocks, not sales pitches

Varnish can speed up page delivery by caching certain responses between the server and visitors. It is an interesting building block when traffic, frequency of consultation or application load justify it. But a cache does not fix a poorly thought-out architecture, unnecessarily heavy code or a poorly indexed database. You also have to manage invalidations: quickly displaying an old version of a page is not progress if the content needs to be up to date.

A PWA, or progressive web app, can bring a more comfortable experience on mobile: installation from the browser, degraded operation in certain situations, fast access and an interface designed for repeated use. It is relevant when users return often and an application journey brings a real benefit.

For a showcase site consulted occasionally, a full PWA can, on the other hand, add work without improving contact requests. As always, the choice must start from usage: who returns, to do what, how often and in what connection conditions?

Why are "shiny" technologies so attractive?

A new name sometimes gives the impression of a new start. It allows you to tell an ambitious project story, to recruit certain profiles more easily or to differentiate yourself in a sales presentation. Demonstrations are often impressive: fast interface, automated deployment, distributed architecture, offline mode.

But a demonstration does not always show the years that follow. Who monitors the services? Who fixes dependencies? Who restores a backup? Who understands the code when the service provider changes? How much does a simple evolution cost? What is the plan if the third-party tool increases its rates or disappears?

The risk is confusing novelty with progress. A technology can be excellent in its original context and disproportionate for a small business. It can also be chosen to solve a problem that does not yet exist, while much more concrete needs remain unanswered: better qualifying requests, simplifying appointment booking, securing access or regularly publishing content.

The real subject: total cost of ownership

The price of a site or an application is not limited to the first invoice. To compare two solutions, you have to look at their total cost over several years.

A technically elegant but expensive solution to operate may be less interesting than a more sober solution. The choice must take into account the budget available today, but also the time the team can dedicate to the project tomorrow.

A proven stack is not an outdated stack

Symfony, MySQL, Varnish or a progressive web application are not "uncool" choices because they have been known for a long time. Their maturity can, on the contrary, reduce risk: documentation available, feedback, monitoring tools, accessible skills and better-understood behaviours.

The modernity of a project is also measured by its operational quality. A fast, accessible, secure, well-backed-up, correctly followed and easy-to-evolve site is more modern than a spectacular but fragile architecture. For a small business, the most innovative technology is often the one that allows you to remain autonomous and make good decisions without recruiting an entire team.

Proven foundations should not, however, become an excuse to never evolve. A healthy architecture accepts improvements: better interface, API when useful, better-configured cache, automated deployments, testing and performance monitoring. Pragmatism is not stagnation.

Seven questions to ask before choosing a technology

1. What business problem do we want to solve? Save time, sell, inform, book, manage data or connect tools?
2. Who will use the product and how often? An occasional visitor does not have the same needs as a daily user.
3. What complexity must be managed from launch? A clear scope is better than an architecture planned for every imaginable scenario.
4. Which data must remain consistent and traceable? This answer often guides the choice of database.
5. Who will maintain the solution? An adapted technology is one that you actually know how to operate.
6. What is the cost over three to five years? Include hosting, licences, services, maintenance, evolutions and training.
7. How will we check that the choice is working? Define indicators: time saved, requests received, speed, availability or data quality.

At Cadarsir, technology serves the project

For Cadarsir, choosing a stack is not about piling up the most visible tools of the moment. It's about starting from the business activity, commercial objectives, content, data and daily constraints to build a clear and sustainable solution.

A proven base can be the best choice for a showcase site, a blog, a business area or an application that must remain simple to maintain. A more specialised technology can also be chosen when it brings a measurable benefit: better experience, necessary integration, real scaling or productivity gain.

The goal is to keep an architecture solid enough to evolve, but sober enough to be operated. The site must help the company move forward, not become a permanent technical subject.

Conclusion: choosing a technology is choosing a level of risk

MongoDB, NoSQL, Next.js, Symfony, MySQL, Varnish and PWA can all have their place. None of these words, however, is enough to define a good solution. The right choice depends on the need, data structure, frequency of use, available skills, operation and total budget.

Before following a trend, ask yourself what it concretely improves for your business. If the answer is clear and measurable, the technology deserves study. If it only fits into a list of buzzwords, it's better to get back to business.

A modern stack is not the one that impresses the most in a presentation. It is the one that remains reliable, understandable and profitable when the project has to live for several years.