J'ai commencé à coder à 15 ans — un site World of Warcraft qui s'est fait DDoS dès le premier jour. À 18 ans, je construisais des bots et j'apprenais comment les systèmes en production résistent aux interactions externes. Après l'université, j'ai choisi la voie difficile : développeur Java en finance réglementée. Trois ans chez Finologee à construire des systèmes pour le secteur bancaire, où chaque déploiement est audité et chaque erreur a des conséquences juridiques. C'est là que j'ai compris que le production-grade n'est pas une fonctionnalité — c'est une discipline.

En 2020, j'ai co-fondé kodehyve en tant que CTO. L'objectif : construire le système d'exploitation des promoteurs immobiliers — une plateforme multi-modules, multi-acteurs couvrant la gestion de projet, le CRM, la gestion financière, la conformité et le cycle de vie des investisseurs.

J'étais le seul développeur la première année. J'écrivais le code, choisissais la stack, concevais l'architecture. À mesure que la boîte grandissait, j'ai construit tout le processus de développement : environnements, CI/CD, workflows de code review, onboarding, programmes de formation.

J'ai fait passer l'équipe dev à 10+ ingénieurs, introduit l'architecture event-driven, construit un design system partagé, et mené une refonte complète de la plateforme quand on a dépassé la codebase originale — parce que reconstruire était plus rapide que de se battre contre la dette technique accumulée sous pression.

En parallèle, j'ai construit une plateforme de signature électronique sur l'infrastructure de confiance nationale du Luxembourg. Elle est utilisée par plus de 100 agences immobilières aujourd'hui.

Plus de 5 ans à construire à cette échelle — de développeur seul à une équipe de 20+ — m'ont appris que chaque décision fondatrice se cumule. Les bonnes vous portent. Les mauvaises vous hantent.

Et puis l'IA est arrivée. J'ai passé une année entière à creuser en profondeur — pas à construire des démos, mais à tester ce qui se passe quand l'IA écrit du code dans une vraie codebase complexe. La réponse : sans garde-fous, elle crée un chaos magnifique. Avec des fondations solides et des patterns définis, elle devient l'outil le plus puissant que j'aie jamais utilisé.

Ce constat est devenu ITzWorking — ma méthodologie, codifiée en framework opinioné. Chaque décision fondatrice dont un SaaS a besoin, déjà prise, déjà éprouvée. L'architecture qui transforme l'IA d'un stagiaire 2x en un senior 10x.

Puis j'ai poussé l'idée plus loin. Si des fondations solides rendent l'IA puissante pour construire du logiciel — que se passe-t-il quand on applique la même discipline à chaque projet ?

J'ai transformé tout ce que j'avais appris — les patterns d'architecture, les standards de production, les décisions qui se cumulent — en méthodologie. Auth, facturation, monitoring, multi-tenancy, déploiement. Chaque problème qu'un SaaS rencontrera, déjà résolu. Pas un framework à vendre. Une façon de construire qui garantit le production-ready dès le premier jour.

C'est là que j'ai compris ce que la plupart des MVPs font mal. Pas l'idée. Les fondations. Des prototypes vibe-codés qui cassent avec de vrais utilisateurs. Du code de freelance qu'il faut réécrire au bout de six mois. Des startups qui brûlent du runway sur de la dette technique qu'elles ne savaient même pas qu'elles accumulaient.

Je construis des MVPs pour les fondateurs qui ne peuvent pas se permettre de rater ça. Prix fixe. En semaines, pas en mois. Chaque projet est livré avec les mêmes standards que ceux que j'utilisais pour construire des plateformes pour des clients institutionnels.