When I started the ACCENSEO accounting SaaS in early 2025, I knew I would be the only person coding for 14 months on more than 200K lines of code, with a regulated domain that does not forgive shortcuts (PCG, CGI, 2026-2027 e-invoicing). The classic trap on this kind of codebase is to start with a technical-layer split (controllers / services / repositories) that becomes unmanageable past 30 modules. I needed an architecture that would hold for 2 years without structural debt.

I committed to a feature-driven architecture from the very first commit: 42 autonomous modules under `src/features/` (banking, invoicing, accounting, tax, payroll, AI assistant, reporting, legal, OCR...), each with its own components, hooks, services, models, and types. `src/app/` only holds Next.js routing, never business logic. On the data side, 91 Prisma models organised around domain entities (not around SQL tables), with 63 typed enums, and 6 differentiated roles controlled through Better Auth. Cross-feature contracts go through a single `index.ts` per feature that defines the consumable public surface - everything else stays internal to the module.

382 API routes generated, new features added in days rather than weeks, and the module/feature boundaries survived several major refactors (Next.js 16 upgrade, React 19 migration, Teledec Chrome extension addition) without any need to touch the overall structure.

What I validated on this project is that good architecture makes growth linear instead of exponential: at the 30th feature I was as fast as at the 5th. That is exactly the promise I have to keep on the next CTO scale-up role - and I have now stress-tested it solo, which makes the team transposition far more credible.

The European Sourcing extranet was the central back-office of Europe's largest online tradeshow for promotional products - 15 interconnected sub-projects, a shared MySQL database of 15 GB across 97 tables, 7 languages, 800 suppliers, and some catalogues like SOL's carrying 15,000 variations for a single product. The v1, written in 2008-2013 on a homegrown PHP MVC framework, could not keep up anymore: every business addition cost more and more.

On March 14th, 2016, we started the v2 on Symfony 3.1, with PostgreSQL instead of MySQL, RabbitMQ for async messaging, and most importantly 2 shared bundles - ESCoreBundle (entities, auth, file system) and ESSourcingBundle (business logic) - to consolidate what the 15 sub-projects were duplicating. Core development was co-led with Thomas C. on v2, inside a tight 4-developer crew where I was the principal author of v1 and the Supplier BO. To industrialise the admin screens, I built a generic EntityList system with configurable columns, bulk actions, per-row actions, and pagination. On the form side, I shipped more than 70 Symfony Form Types covering products, variants, static and dynamic markings with profiles, simple/multiple/group attributes, categories, keywords, labels with synonyms, subscriptions, and import/export workflows.

The v2 ran for more than 5 years in production (2016-2021), powering 37 automated supplier connectors, and the pattern library laid down on this project was reused by every downstream app without ever requiring an architectural rewrite.

This project taught me how to share without coupling: the shared bundles stayed stable while each sub-project evolved at its own pace. That is the pattern I now replay on the ACCENSEO Turborepo monorepo and that I will impose on the next scale-up platform - the cost of good factoring is low, the cost of bad factoring is toxic over 10 years.

On the Fleurance Nature refactor in 2017 at Smile, I inherited a Magento Enterprise Edition 1.10 platform packed to the brim: 1,040 modified PHP files, 60 accumulated custom modules, 3 storefronts (Fleurance Nature France, International, Mincifine) to serve with a shared EAV pricing matrix across 4 customer groups (anonymous, general, loyalty subscribers, works councils) - meaning 12 active pricing combinations. The specs themselves went through 7 versions in 2 months (from 30 to 50 pages) as we discovered the business rules buried in the legacy code.

I refused the big-bang temptation. I drove a clean backend/frontend split across the 3 storefronts, backported ElasticSearch onto Magento EE 1.10 to replace Solr (autocomplete, faceted navigation, virtual categories), and enforced on every custom module the Observer/Strategy patterns to stay PCI-aware without touching the Magento core. To secure releases, I rolled out a full regression suite across the 3 sites before every deployment, because a single module change could ripple through 12 pricing matrices.

The refactored platform held for more than 5 years in production without any further architectural rewrite, zero major security incident during and after the migration, and the Varnish cache stayed operational throughout the process despite the live-site sensitivity.

What I learnt on this project is that module/core boundaries are what makes a codebase survive vendor changes and version upgrades - not the quality of the code itself. On every CTO advisory audit I now run at ACCENSEO, that is the first thing I look at in the customer codebase.