Zona is a software distribution platform dedicated to the audio industry.
It brings together different types of resources (software, SDKs, frameworks, libraries, audio engines, plugins, content, etc.) within a unified catalog.
The first public version focuses on catalog browsing. However, the architecture has been designed from the outset to support the platform's future evolution (administration, organizations, user accounts, community features, etc.) without requiring its foundations to be reconsidered.

My role goes beyond software development.
I am involved in project planning, documentation, version planning, and transforming functional requirements into software architecture.
The functional direction is defined upstream. My role is then to analyze it, structure it, and design the technical solutions needed to bring it to life.

The analysis of the product model resulted in both a data dictionary and a PostgreSQL relational model. Studying the relationships between entities then made it possible to divide the administration into several coherent modules and define endpoint responsibilities, business validations, and transactions.
The first production data proved to be a real test for the model. It revealed several real-world use cases that led to revisiting some design decisions in order to establish a more solid foundation before the public release.

I implemented a dedicated DTO strategy depending on the use case.
Read DTOs are intentionally broad in order to cover the data model efficiently. In contrast, create and update DTOs are much stricter and are only introduced when there is a genuine business need.
The architecture is built around multiple service layers. Some services are exposed directly through the API, while others remain internal or are only used as part of higher-level orchestrations. This approach distributes responsibilities across specialized services instead of concentrating all business logic into a single one.
Operations involving multiple entities rely on transactions to ensure data consistency. Whenever appropriate, additional optimizations are implemented to reduce unnecessary processing and improve performance, notably through Redis caching, batching, and request coalescing.
The platform is designed to eventually allow organizations to publish their own software and resources.
The publication workflow relies on two complementary stages. First, automated business validation ensures that every product satisfies the requirements associated with its type (software, web application, content, etc.). Once those conditions are met, a manual moderation process verifies the official sources and distributed files before publication.
This separation enables progressive publication. A product can become publicly available as soon as its required elements have been validated, while some resources, such as artifacts hosted by the platform, follow their own verification process before being published.
The frontend is built with Next.js and React. The interface follows a desktop-first approach. Although fully responsive, it is primarily designed for desktop usage, which better suits both the type of content being explored and the target audience.

OpenAPI contracts define the interface between the backend and the frontend. TypeScript clients are generated automatically to ensure consistency between the frontend and the API throughout development.
Business logic is intentionally centralized in the backend to minimize client-side processing. The frontend primarily focuses on data presentation, navigation, and user interactions.
The application is deployed on a Linux VPS. The infrastructure consists of several independent Docker services: frontend, API, PostgreSQL, Redis, and a reverse proxy.
Production deployments are automated with GitHub Actions. Each deployment builds the Docker images, publishes them to GitHub Container Registry, and updates the production services. Since the images are versioned, rollbacks remain possible at any time.
The infrastructure also includes separate environments, health checks, data backups, recovery procedures, and HTTPS configuration using Caddy.
In the absence of an administration interface, the initial data is created through API endpoints exposed by Swagger. This ensures that every record goes through the same business validations, transactions, and backend processing as it would in production.
Once validated, the database is exported (schema and data) and re-imported when provisioning new environments.
A significant part of the work also focuses on technical documentation.
Throughout the project, I established conventions covering DTOs, controllers, services, security, and various architectural decisions. I also created several inventories documenting the services, their methods, responsibilities, and the different DTOs.

With the first public version now deployed, development continues across several areas. The next milestones mainly focus on the administration interface, organization management, user accounts, and the platform's first community features.
Zona is a long-term project whose architecture has been designed to support these future developments without requiring its foundations to be reconsidered.