This is not just a list of technologies. It is a real example of how technical decisions change when a product grows, gains larger clients, and needs to become more scalable and maintainable.

The first version of Studio Assistant was a relatively small application for independent studios. It was built in Joomla, using PHP and MySQL, with the server rendering complete HTML pages for the browser.

A CMS is software that helps people create and manage content without building everything from scratch. It usually provides an administration interface, user roles, routing, and extension mechanisms — which makes it useful for early-stage products.

Joomla gave us the structure of the application. PHP handled the server-side logic and rendering. MySQL stored the data. This was a very practical combination for building the first version quickly.

In the classic model, the browser asks for a page, the server generates the HTML, and the browser displays it. This works well for simpler applications, but it becomes limiting when the interface needs to feel more interactive.

When the product started to be used by a much larger client, the interface had to become more responsive and application-like. We still used Joomla in the backend, but we started moving more UI rendering to JavaScript in the browser.

AJAX allowed the browser to request new data without reloading the whole page. Fetch is the modern browser API for this. This shift made the interface feel much more responsive and dynamic.

This second phase was hybrid. The backend was still based on Joomla and PHP, but the browser was doing more and more rendering work. This is a very common transitional stage in real projects.

Later, as the product became more serious and investors became interested, we decided to rebuild the application. The goal was not to follow trends, but to create an architecture better suited to long-term product growth.

In the rebuilt version, the backend moved to Express, the database remained MySQL, Prisma provided a safer and more structured way to work with data, Svelte powered the frontend, and TypeScript improved reliability in a growing codebase.

The important change was not only the choice of tools, but the change in architectural thinking. The backend became responsible for business logic and data, while the frontend became responsible for the user interface and interaction.

If I had to summarize the whole story, I would say that the project evolved from a CMS-based monolith, to a hybrid solution, and finally to a more modern separated architecture.

The main lesson is that technology should follow the real needs of the product. The right solution at one stage may not be the right solution later. Real-world software almost always evolves step by step.

For me, this is the most interesting part of the story: each phase was the right answer at its time. The product evolved, and the architecture evolved with it. That is a very realistic lesson from web development.