Skills
Backend development covers processing performed on the server: business rules, data access, authentication and authorization, APIs, scheduled tasks, external integrations, and observability. A route returning a correct response is only part of the work. Accepted data must be defined, inputs validated, invariants preserved, errors handled, secrets protected, side effects controlled, and behavior made testable.
My practice is not limited to one language. I use Python with Odoo's ORM for ERP processes, PHP and Symfony on the B2B website, Node.js with Express, Prisma, and PostgreSQL for CAP2vie, and Next.js Server Actions for the portfolio. This diversity has taught me to recognize the same responsibilities behind different tools: exchange contracts, transactions, access control, resilience, and traceability.
I pay particular attention to integrations. When two systems exchange customers, products, orders, or emails, apparent availability does not prove that data is complete and consistent. I therefore verify formats, errors, recovery behavior, possible duplicates, and each system's responsibility.
Symfony 8.0.0 became stable on November 27, 2025, together with its feature overview and upgrade guide. This major release is a reminder that maintainable backend work requires tests, gradual compatibility work, and a migration strategy.
Read the source: SymfonyThe Symfony B2B website depends on customers, products, stock, and orders managed in Odoo. When standard mechanisms did not precisely satisfy the required contract, I developed focused controllers in internal modules. I had to select useful data, respect permissions, avoid exposing confidential information, and preserve a clear boundary between the ERP domain and the website. The Odoo 19 migration then required adapting most exchanges to JSON-2 and checking flows in both directions.
Result — The B2B website and main integrations resumed operation after the migration. Custom routes remain localized in version-controlled modules, making their responsibility and evolution identifiable.
For CAP2vie, the team built a JavaScript backend with Express, PostgreSQL, and Prisma. We defined the questionnaire's main entities, stored answers, and associated events with trajectory dimensions. During the project, I led the multi-screen connection using Socket.io: creating a password-protected room, synchronizing the state required by the second screen, and keeping input available when the secondary display disconnected. The prototype remained local and reconnection was still manual, limitations that we documented.
Result — The multi-screen demonstration worked, and the next developer successfully installed the project. The experience taught me to reason about real-time connection state, interruptions, and a security scope acceptable only for a controlled proof of concept.
The portfolio contact form uses a Next.js Server Action that revalidates data with Zod before calling Resend. I added several layers against unwanted submissions: a honeypot field, elapsed-time check, a limit of five requests per hour per IP address, and reCAPTCHA v3 when configured. The browser never decides validity alone. Error responses remain generic for users, while tests simulate external dependencies to cover branches without sending real emails.
Result — The delivery chain has been validated through my own trials and has tests for validation and the main protections. I retain an explicit limitation: external services are simulated in automated tests and still deserve integration scenarios closer to the real deployment.
I assess myself as intermediate. I can design models, business rules, APIs, and integrations across several ecosystems, then test and deploy them. My deepest experience remains Odoo; with Symfony, distributed architecture, and large-scale real-time systems, I still lack recent projects carried through to heavy production load.
Backend development connects my ERP specialization to my full-stack profile. It prevents me from treating Odoo as an isolated application: B2B orders, logistics, email, analytical data, and public interfaces depend on reliable server contracts.
My advice is to start an API with its contract, actors, and errors before writing the happy path. It is necessary to know who owns the data, which validations are authoritative, how the call may be replayed, and what trace will diagnose a failure. Interface checks complement this protection but never replace server-side controls.
Reach an advanced level by consolidating API design, transactions, observability, and integration testing, with a stronger ability to compare architectures rather than reason from a single framework.
I continue practicing Symfony on the B2B platform, deepening PostgreSQL knowledge, and designing JSON-2 integrations. The Business Intelligence project connected to Odoo should also develop my skills in data pipelines, error recovery, and separating analytical reads from ERP transactions.