Douze semaines, c’est assez de temps pour construire un vrai produit — et assez court pour ne pas pouvoir en gaspiller une seule. La différence entre un MVP qui survit à sa levée seed et un autre qui s’effondre face aux 1 000 premiers utilisateurs n’est presque jamais le framework. Ce sont les décisions prises la première semaine.
Semaine 1–2 : le périmètre, pas les fonctionnalités
La première tentation est de lister des features. Nous faisons l’inverse : nous écrivons la seule chose que le produit doit prouver. Tout ce qui ne sert pas cette preuve est mis de côté, pas supprimé — mis de côté.
Un MVP n’est pas un produit plus petit. C’est la plus petite expérience honnête possible.
Semaine 3–8 : construire sur une colonne qui passe à l’échelle
Nous choisissons une architecture affirmée dès le commit zéro — auth, paiements, jobs en arrière-plan, observabilité. Pas parce que le MVP en a besoin dès le premier jour, mais parce que les rajouter après le product-market fit, c’est là que les équipes perdent un trimestre.
- Des choix ennuyeux côté base de données, des choix excitants côté produit.
- Des feature flags dès le départ, pour que la démo ne bloque jamais un déploiement.
- Un environnement qui reflète la production, même minuscule.
Semaine 9–12 : instrumenter, puis durcir
Le dernier mois est une question de confiance. Nous ajoutons le tracing, montons les dashboards que les fondateurs vont vraiment regarder, et exécutons les parcours comme le ferait un vrai utilisateur. Le polish se fait ici — pas avant, où il aurait relevé de la devinette.
Pour savoir où vous en êtes avant d’attaquer ces 12 semaines, notre test « prêt pour la levée ? » vous situe en quelques questions face à un tour de seed.
Si vous avez 12 semaines devant vous et souhaitez un deuxième regard sur le plan, parlons-en. Une heure de discovery peut vous épargner un semestre.