Pourquoi je livre un MVP en 3 semaines et pas en 3 mois
La plupart des MVP que je vois traîner sont des projets qui ont eu peur d'eux-mêmes. On les a chargés d'options, de "au cas où", de "ce serait bien de". Résultat : trois mois plus tard, l'équipe a perdu son énergie, le marché a bougé, et le produit livré ressemble à un compromis fatigué.
Le vrai coût d'un MVP long
Un MVP de 3 mois, ce n'est pas trois fois plus cher qu'un MVP de 3 semaines. C'est dix fois plus cher. Parce qu'on paie :
- Le temps d'ingénierie
- Le coût d'opportunité (ce qu'on n'apprend pas pendant ce temps)
- La démotivation de l'équipe
- Les décisions produit prises sans feedback utilisateur
Le pire, c'est que la valeur produite est souvent inférieure : trop de features, pas assez d'usage réel.
Mon cadre en 3 semaines
Je découpe systématiquement en trois blocs d'une semaine.
Semaine 1 — Cadrage. On écrit l'histoire utilisateur, on tranche le périmètre, on prototype les écrans clés. Aucun code. Objectif : sortir de la semaine avec un scope figé et un plan technique clair.
Semaine 2 — Construction. On code le parcours principal de bout en bout, avec de vraies données. Pas d'admin custom, pas de dashboard analytics maison. On utilise les outils existants (Supabase, Stripe, Cal.com, etc.).
Semaine 3 — Rodage. Tests avec utilisateurs réels, correctifs, préparation du lancement. On fige les features et on ne rajoute plus rien.
Ce que je refuse en semaine 3
Toute demande qui commence par "et si on ajoutait juste…" est reportée au post-MVP. Sans exception. Un MVP qui glisse d'une semaine, c'est un MVP qui glisse d'un mois.
Le rôle du builder, c'est aussi de protéger le client de ses propres bonnes idées.