Mon process réel pour créer un MVP SaaS en 4 semaines : périmètre, stack, semaines 1 à 4, et ce qui fait dérailler les autres.


Quatre semaines entre le périmètre signé et un MVP SaaS que de vrais utilisateurs peuvent payer. Ce n'est pas une promesse marketing — c'est le process que je déroule réellement avec mes clients, et le plus intéressant, c'est que la vitesse vient de ce qui se passe avant le code, pas d'une frappe plus rapide.
En résumé : un MVP SaaS en 4 semaines est possible quand trois choses sont vraies — le périmètre est brutalement réduit à un workflow cœur, la stack est ennuyeuse et éprouvée, et les décisions se prennent en heures plutôt qu'en réunions. Voici la réalité semaine par semaine.
Chaque fondateur arrive avec 12 fonctionnalités. On garde le seul workflow pour lequel un client paierait dès le premier jour, plus les essentiels ennuyeux : auth, facturation, une vue admin. Tout le reste part dans une liste « v2 si les utilisateurs le demandent ». Cette réunion économise plus d'argent que n'importe quel choix technologique — c'est la différence entre le MVP à 8 k$ et celui à 40 k$. Si vous hésitez sur le périmètre, commencez par ce qu'est vraiment un MVP SaaS.
Repo, Next.js + TypeScript + Postgres + Prisma, auth branchée, Stripe en mode test, déployé sur l'infrastructure de production dès le deuxième jour. Déployer d'abord est l'astuce que la plupart des équipes ratent : ensuite, chaque fonctionnalité atterrit dans un environnement réel, et il n'y a pas de terrifiante « semaine d'intégration » à la fin.
La seule chose que fait le produit — construite complètement, plutôt que cinq choses à moitié. Le client voit l'avancement sur une URL en ligne tous les deux ou trois jours et donne son retour par écrit. Les boucles courtes battent les longues specs : un fondateur qui réagit à un écran fonctionnel repère en une minute ce qu'une relecture de document ne verrait jamais.
États d'erreur, e-mails, comportement mobile, performance de chargement, monitoring, sauvegardes — les détails de production qui séparent un produit d'une démo. Les devis qui semblent trop bas sautent presque toujours cette semaine ; les fourchettes de mon décryptage du coût d'un MVP l'incluent.
Next.js, TypeScript, Postgres, Stripe — des technologies que j'ai livrées une douzaine de fois. Les stacks originales, c'est pour les expérimentations ; un MVP est une expérimentation sur votre marché, donc la technologie doit porter zéro risque. C'est la même raison pour laquelle je privilégie le sur-mesure au no-code dès qu'il y a de la vraie logique produit.
Un périmètre qui grossit chaque semaine. Des décisions qui attendent des réunions. Du polissage de pixels avant le product-market fit. Et les frais d'équipe — pour un MVP, un seul développeur senior orienté produit bat une équipe de cinq à la fois sur le coût et sur le calendrier.
Ce process est exactement ma façon de travailler avec les fondateurs — périmètre fixé, forfait fixé, URL en ligne dès la première semaine. Regardez ce que j'ai livré, puis dites-moi ce que vous construisez et je vous dirai ce qui tient en 4 semaines.
Topics
Let's build something together.