Si ton projet devait partir en production demain, qu’est-ce que tu coderais aujourd’hui ? C’est la seule vraie question qu’un développeur dans une startup devrait se poser. Et pourtant, dans beaucoup d’équipes, ce n’est pas ce qui se passe. On passe des heures à discuter d’architecture future-proof, à débattre de microservices, à imposer TypeScript "parce que tout le monde le fait", à peaufiner du code pour qu’il ressemble à celui d’un Google engineer. Mais on oublie l’essentiel: on n’est pas Google. On est 24 développeurs. Pas 2 000. Notre priorité, ce n’est pas la beauté du code. C’est d’apporter de la valeur au client. Rapidement. Et c’est là que le contexte change tout. Chez lemlist : – Pas de microservices. Un bon monolithe bien structuré, c’est plus simple à maintenir, plus rapide à déployer, et ça permet de shipper sans friction. Vouloir découper trop tôt, c’est s’infliger une complexité inutile. – Pas de TypeScript. Avec des devs confirmés, des conventions claires, de bonnes revues et des tests auto, JS pur nous permet de livrer plus vite, avec moins de charge mentale. Et non, on n’a pas besoin de types pour comprendre le code ou pour aider nos IA. Cursor, par exemple, s’en sort très bien sans typage strict. Petit rappel : j’ai passé 10 ans à écrire du C++ donc les systèmes de types ultra‐stricts, je connais. Puis j’ai découvert Ruby et son fameux duck typing : "si ça cancane comme un canard…". Résultat ? J’ai adoré la liberté de coder vite sans cérémonial. Bref, tout ça c'est des excuses pour pas coder. C’est exactement la même logique aujourd’hui : Je respecte les langages fortement typés quand ils accélèrent réellement la livraison (banque, safety-critical, très grosse codebase). Je choisis le dynamique quand la priorité, c’est d’itérer en 24 h sur une feature qui fait grimper le revenu. Donc ce n’est pas un débat « team expert vs team feignant ». C’est juste une question de contexte et de ROI, comme le passage de C++ à Ruby me l’a montré dans ma carrière. Beaucoup pensent que certains outils sont “obligatoires”. Mais aucun outil n’est universel. Un outil n’a de valeur que s’il accélère ton time-to-value. Sinon, c’est juste une distraction bien emballée. On ne construit pas un lance-roquettes pour tuer un moustique. Et on n’impose pas une stack “enterprise-ready” sur un produit qui cherche encore son PMF. Ce n’est pas une critique de la tech. C’est un appel à la lucidité. Quand tu es en startup, chaque ligne de code doit se justifier par sa capacité à améliorer l’expérience utilisateur, augmenter la conversion, créer de l’engagement, ou générer du revenu. Le code parfait n’existe pas. Mais le bon code, c’est celui qui fait avancer le produit et rapporte de l'argent. Pendant que ça compile des opinions, nous on push en prod.