Les décisions d'ingénierie qui vous permettent de construire un MVP réussi sont souvent exactement les décisions qui vous paralyseront à l'échelle. Ce n'est pas un échec du jugement d'ingénierie — c'est l'application correcte de celui-ci. Le problème survient quand les équipes ne reconnaissent pas le moment où ces décisions doivent changer.
Pourquoi l'ingénierie MVP ressemble à de la dette technique
Lors de la construction d'un MVP, l'objectif est de valider une hypothèse avec un investissement minimum. Chaque décision d'ingénierie doit être prise au service de cet objectif. Les bases de données partagées conviennent. Les appels synchrones partout conviennent. Ces ne sont pas de mauvaises décisions — ce sont des décisions appropriées pour le stade.
Les trois points d'inflexion
- 10x utilisateurs : Les performances de la base de données deviennent un goulot d'étranglement.
- 5x taille d'équipe : La base de code qu'une équipe comprenait devient quelque chose qu'aucune personne ne connaît complètement.
- Premier client enterprise : Les exigences de sécurité, conformité, SLA et audit deviennent soudainement des exigences dures avec des implications contractuelles.
“La meilleure architecture pour une entreprise en croissance n'est pas l'architecture la plus sophistiquée. C'est l'architecture qui vous permet de prendre la prochaine décision avec le plus d'informations et le moins de perturbations.”
Architecturer pour le voyage
L'objectif n'est pas de construire pour l'échelle dès le premier jour — c'est du sur-engineering qui vous ralentit quand vous devez vous déplacer rapidement. L'objectif est de construire avec des coutures : des frontières claires entre les composants qui vous permettent de remplacer, extraire ou mettre à niveau des pièces individuelles sans réécrire tout le système.