Symfony is the framework I’ve built the most on – and taken apart the most. From Symfony 2 at Gestour in 2011 to Symfony 6 at IAD in 2024, I’ve seen the framework evolve, its ecosystem mature, and the same mistakes repeat across projects. This page details where, when and how I’ve used Symfony in real-world conditions.
Architecture choices, API design, team conventions – it’s better to lay the right foundations from the start than to fix them halfway through.
Symfony 2 or 3 still in production, tight coupling, no tests. There is a path between “don’t touch anything” and “rewrite everything” – that’s my playground.
Migration from Symfony 3/4/5 to a recent version, with test coverage as a prerequisite and a progressive migration plan deliverable in stages.
Symfony profiling, Doctrine optimization, caching strategies, N+1 query review – identifying the real bottleneck before investing in hardware.
Code audit, architecture review, prioritized roadmap – without selling a full rewrite if it’s not necessary.
Introducing DDD, hexagonal architecture or TDD into an existing project, without disrupting delivery. Pair-programming sessions and targeted code reviews.
At the heart of IAD’s international expansion (UK and US launch), I joined two successive squads working on application and CRM modules. Developed the “purchase project” – a single entry point for managing buyer criteria – and an automatic property/criteria matching engine. Strict hexagonal architecture with DDD approach from design, on a modular monolith being progressively split.
Following the acquisition of L’Argus, the Import feature team inherited a legacy application for automotive ad distribution. Mission: bring it into production within the Adevinta ecosystem and open it to Leboncoin.fr. Reduced the Docker image from 1 GB to a few hundred MB, set up functional tests on import/export flows, refactored to hexagonal architecture, and developed a client onboarding automation API.
Dockerization of environments, setting up continuous integration and deployment on existing Symfony applications. Technical workshops with teams (Xdebug, Gitflow, WSL, Docker). Migration of suzuki.fr to Platform.sh.
Migration of a concrete slab calculation application (monolithic PHP/Symfony) to a serverless architecture on AWS Lambda. Heavy computations run in parallel via a distributed engine, with significant performance gains.
Intrapreneurial SaaS within Air France, a mission management tool for pilots and ground crew. Extracted business logic from controllers into application services to create an API independent from Symfony and Doctrine. Migration from MySQL 5 to PostgreSQL 11 with queries rewritten as recursive CTEs and materialized views. Defined testing strategy and set up continuous integration.
Nonprofit donation platform startup. Maintained and evolved the central API, developed asynchronous microservices (ZeroMQ), TDD with acceptance tests. Full Docker infrastructure, CI pipelines with Jenkins/CircleCI. Long-term fully remote engagement.
Gestour is the most widely used travel agency management tool in France. Selected and adopted Symfony 2 for new web developments – Gestour 360, a web version meant to replace the C++ desktop client. Developed a CRM for CroisiEurope and a business analytics tool. Scrum context within a structured SaaS vendor.
API Platform was a real revolution in its time. Exposing a documented REST API with a few annotations, complete with pagination, filters and built-in validation – it was impressive. Many Symfony projects adopted the tool without hesitation.
Except API Platform is not a simple bundle. It’s a framework within a framework, with its own vocabulary, its own abstractions, its State Providers and Processors that end up driving code organization. In a hexagonal architecture, this creates real tension: API resources start influencing the domain model, when it should be the other way around. And when a requirement goes off the beaten path – complex permissions, non-standard responses, rich business logic – you spend more time working around the tool than coding the domain.
In 2026, an LLM generates a clean, up-to-date OpenAPI spec from standard Symfony controllers. The “automatic documentation” argument has lost much of its weight. I detail my approach to use-case-driven REST API design on a dedicated page.
Sonata follows the same pattern, with an extra layer of irony. It was there to avoid writing CRUD. But an admin CRUD never stays simple for long – a field is added, a business rule arrives, a custom interface is requested. And that’s when the real pain starts: fitting an evolved requirement into the constraints of a tool that didn’t anticipate that case.
Not to mention migrations. Sonata is one of the most frequent reasons projects stay stuck on Symfony 3 or 4 – its cascade of dependencies makes any version upgrade particularly painful. For a tool used 80% of the time as a simple form generator.
The list is long of tools that addressed a real gap at a time when Symfony didn’t cover these needs natively. User management, REST exposure, advanced serialization – all problems that Symfony has since absorbed into its core.
Projects, however, often keep the dependency out of inertia. Not because of bad choices – simply because a running project doesn’t always have the time or budget to pay down debt with each release.
This isn’t about bad initial choices. It’s simply what happens when a mature framework gradually absorbs its ecosystem. Third-party tools that filled yesterday’s gaps become today’s technical debt. Identifying which ones are truly slowing down the project – and in what order to remove them – is often where the difference lies between a project that moves forward and one that falls behind. I describe my refactoring and legacy modernization strategies in detail.
ready
Discuss your project on LinkedIn
See my profile on Malt
