When I took over the DAM in February 2019, the project was not late - it was stuck. 5 project managers had come and gone, more than 360,000 euros had been spent on OpenText licenses, integrator fees, and internal management, and the platform was serving barely 20 people where it should have equipped the 1,400 employees of Groupe Pichet. Leadership was hesitating between dropping the initiative entirely and onboarding yet another vendor - which would have reproduced the same failure pattern.

I refused to attack the solution before reframing the problem. Together with Stéphanie L., the new Communications Director, we set 3 foundational questions before relaunching anything: what business outcome does the platform have to produce (eliminate the manual asset redistribution, not just host images), what contractual reversibility is non-negotiable (exit the SaaS without lock-in), and what does a successful day 90 look like (a salesperson finds her own program visual in under 2 minutes). Only after locking those 3 criteria did I build the 6-step independent benchmark methodology and steer the evaluation toward Bynder rather than yet another OpenText attempt.

Bynder went live on November 18th, 2020, 1,400 users onboarded, contract signed with SLA and reversibility clauses locked down by our legal counsel. Where 5 attempts had failed, the reframing shipped the project in less than 2 years for a few tens of thousands of euros.

That reframing method - reformulating the problem before touching the solution - has become a reflex I now replay on every CTO advisory engagement at ACCENSEO. The core lesson: a failing project almost never has a solution problem, it has a problem statement problem.

Late 2025 Tailwind v4 shipped, fully rewritten in Rust/Oxide. The only existing obfuscation tool (unplugin-tailwindcss-mangle) relied on patching Tailwind internals - an approach that broke instantly with v4. No compatible solution existed on the market, and several teams I advise explicitly needed that tooling to ship their design system. The window was tight: 6 weeks before the community would fall back to ad-hoc workarounds.

I made a counter-intuitive call: instead of patching the internals like the incumbent, I bet on pure static analysis - directly scanning source files for the classes used, with zero dependency on Tailwind internals. That meant betting on a stack I had never touched: Babel AST to parse JSX/TSX/Vue/Svelte/Astro/Qwik, PostCSS to transform the compiled CSS, magic-string for replacements that preserve sourcemaps, and 5 bundler plugins (Vite, Webpack, Rollup, esbuild, Nuxt module) sharing the same core engine. I learned the stack in pair-programming with Claude Code, validating every hypothesis with tests.

6 weeks later I shipped tailwindcss-obfuscator to npm: 82K lines of TypeScript, 295 tests, 10 frameworks supported, automatic detection of Tailwind v3 vs v4, monorepo TurboRepo. First Tailwind v4-compatible tool on the market, picked up by external teams within the first weeks.

What I keep is not the tool, it is the method: when an unfamiliar stack is on the critical path you do not work around it, you learn it - and you learn through tests, not through tutorials. The same mechanic will let me absorb Bun + edge runtimes tomorrow, or any stack a future scale-up CTO role demands.

When I started the ACCENSEO accounting SaaS in early 2025, I knew full-stack development inside out but I had no formal accounting expertise. The domain does not forgive approximation: PCG, CGI, Code de commerce, EDI Teledec, DSP2 for Open Banking, the 2026-2027 e-invoicing mandate. Any tax computation error has a direct financial consequence for the customer. And the horizon was non-negotiable: e-invoicing compliance had to be ready before end of 2026.

I treated the regulation as a system specification, not as an afterthought layer. I archived the key PCG pages, intercepted competitor API responses, ran a market study of dematerialisation platforms, and audited the security of existing SaaS players (which surfaced IDOR + KYC vulnerabilities at several competitors). Then I mapped the rules into Prisma models: 91 models, 63 enums, 6 differentiated roles (Admin, Collaborator, Consultant, Accountant, Accounting, Banking). For every feature - VAT CA3, IS, CFE, CVAE, DAS2, PAS - I wrote the spec, then verification scripts for every calculation, before chaining systematic non-regression tests.

234K lines of code shipped solo, 42 features, 382 API routes, integration with 3 Open Banking providers (GoCardless/Nordigen, Bridge, Qonto), EDI submissions via Teledec, multi-provider AI assistant (OpenAI, Claude, Gemini), 2026-2027 e-invoicing compliance reached ahead of schedule.

Adaptability did not just help me survive - it turned a regulated domain into a product moat. That is exactly the posture a B2B scale-up CTO is hired for in regulated industries (healthcare, finance, institutional real estate): proving you can absorb a legal frame in months and code it without compromise.