Field notes / Par email
Une anecdote tech par semaine.
Les décisions techniques, les erreurs et les raccourcis utiles que j’observe en construisant des produits et en accompagnant leurs fondateurs.
Recevoir la prochaine anecdote- 01Une décision ou un retour terrain par édition.
- 02Cinq minutes de lecture, une fois par semaine.
- 03Aucune séquence commerciale déguisée.
De Fabrice PAYET
Anecdote n° 1Ce n'était pas un problème de code
Premier email · 3 minutes de lecture
Quand une startup ralentit, le diagnostic tombe vite.
Lire l’email complet
« Notre architecture ne tient pas. » « La stack n'est plus adaptée. » « La dette technique nous bloque. »
Ce sont des symptômes. En mission, je commence par regarder qui prend les décisions techniques et ce qu'on a laissé traîner.
Un raccourci accepté pour sortir le MVP devient une habitude. Le prestataire choisit l'architecture, garde les accès et documente peu. Comme le produit ralentit, on recrute un développeur en espérant que ça suffira. Mais personne ne lui donne de cap technique.
J'ai fait cette erreur moi-même en début de carrière. Je pensais qu'ajouter des développeurs à une codebase mal structurée allait accélérer le projet. On obtenait davantage de code sans retrouver de vitesse. Les désaccords augmentaient avec l'équipe.
Le problème n'était pas la compétence des personnes. Il venait de décisions prises trop vite, ou jamais prises. Le code reflétait ces choix.
Avant de parler de refonte, je pose maintenant une question : qui est responsable des décisions techniques aujourd'hui ?
Si la réponse est « le prestataire » ou « personne en particulier », changer de framework ne réglera pas grand-chose.
J'ai détaillé les quatre situations que je rencontre le plus souvent ici : https://fabricepayet.fr/p/pourquoi-les-startups-echouent-techniquement
Fabrice
Recevoir les prochaines anecdotes