Cinq jours pour sortir un MVP SaaS avec Claude Code, c'est possible, mais uniquement si tu acceptes deux règles avant même d'ouvrir ton terminal : la stack est figée le lundi matin, le scope tient sur une page A4. Sans ça, tu vas dériver au jour 3 et livrer un demi-produit au jour 7. Ce guide décrit un plan jour par jour testé sur des projets réels, avec les prompts qui marchent et les pièges qui reviennent. Si tu débutes avec Claude, commence par la base d'apprentissage Claude avant de lancer ce sprint : les fondamentaux de prompting te feront gagner une journée entière.
On part du principe que tu as une idée validée (au moins trois personnes t'ont dit qu'elles paieraient), un abonnement Claude Pro ou Max, et que tu sais lire du TypeScript. Si tu n'as jamais touché à Claude Code, fais d'abord le tour de l'agent CLI pour comprendre comment il lit et écrit dans tes fichiers.
Ce qu'on entend par MVP SaaS ici (et ce qu'on exclut)
Un MVP en 5 jours, c'est un périmètre très précis : authentification email, une fonctionnalité coeur qui résout un problème payant, un checkout Stripe optionnel, un déploiement public accessible via une URL. Point. Pas de back-office admin, pas de multi-tenant, pas d'app mobile, pas de dashboard analytics maison.
Deux exemples qui rentrent dans le scope : un outil qui résume des PDF longs en fiches structurées (upload, traitement, export markdown), ou un mini CRM pour freelance avec 4 champs par contact et un rappel hebdomadaire par email. Deux exemples qui n'y rentrent pas : une marketplace deux faces avec paiement escrow, ou un outil de matching temps réel entre utilisateurs. Dès qu'il y a plusieurs rôles utilisateur ou du temps réel, tu passes à 3 semaines minimum.
Les prérequis non négociables : Next.js 15 + Supabase + Vercel comme stack par défaut (ne cherche pas mieux, ces trois-là couvrent 90 % des cas), un compte Stripe en mode test, un domaine acheté. Si tu hésites encore sur la stack Vercel + Next.js, tranche avant lundi 9h.
Jour 1 : cadrer la spec et générer le squelette avec Claude
La matinée est pour la spec, pas pour le code. Tu ouvres Claude en conversation et tu lui demandes de rédiger un document d'une page contenant : trois user stories au format Given/When/Then, un modèle de données avec les tables et les relations, la liste des écrans (pas plus de cinq). Le prompt qui marche :
Tu es product manager. Je veux un MVP qui [décrire le problème en 2 phrases].
Rédige une spec d'UNE page contenant :
1. Trois user stories (Given/When/Then)
2. Le modèle de données (tables, colonnes, relations)
3. La liste des écrans avec leur rôle en une phrase
4. Ce qui EST EXCLU du MVP (au moins 5 items)
Contrainte : tout doit tenir en 400 mots max. Si tu dois choisir, sacrifie le nice-to-have.Cette dernière contrainte ("ce qui est exclu") est celle qui te sauve la semaine. Imprime la spec et colle-la au mur.
L'après-midi, tu bascules sur Claude Code. Tu crées un dossier vide, tu lances claude, et tu demandes un scaffold Next.js avec App Router, Supabase pour l'auth et la DB, Tailwind, et shadcn/ui préinstallé. Objectif fin de journée : un repo git initialisé, l'app tourne en local sur localhost:3000, tu peux créer un compte avec email/password et voir un dashboard vide. Rien de plus. Si tu as encore de l'énergie, écris un README.md avec la spec dedans et pousse sur GitHub.
Jour 2 : la fonctionnalité coeur, rien d'autre
C'est le jour qui fait ou casse le MVP. Tu identifies la seule feature qui justifie qu'un utilisateur sorte sa carte bleue. Pour l'outil de résumé PDF, c'est "j'upload un PDF, j'obtiens un résumé structuré en moins de 30 secondes". Pas la gestion multi-documents, pas l'historique, pas l'export vers Notion. Juste ça.
La méthode qui accélère vraiment Claude Code : prompter par couche, pas par feature complète. Une itération = une couche. Exemple concret :
Ajoute une table 'summaries' dans Supabase avec les colonnes suivantes :
- id (uuid, pk)
- user_id (uuid, fk vers auth.users)
- source_file_name (text)
- content (text)
- created_at (timestamptz, default now())
Génère la migration SQL et applique-la. Ajoute une RLS policy qui permet à un user de ne lire que ses propres summaries.Une fois validé, tu passes à la couche suivante : la route API qui reçoit le PDF, extrait le texte, appelle Claude via l'API, sauvegarde le résultat. Puis le composant UI. Trois prompts distincts, chacun sur 20 lignes de fichiers modifiés max. Tu relis à chaque fois avec le panneau de diff intégré avant de laisser Claude enchaîner.
Toute demande qui commence par "tant qu'on y est, ajoute aussi..." va dans un fichier backlog.md à la racine. Tu ne l'ouvres pas avant vendredi. C'est la règle qui te fait tenir les 5 jours.
Jour 3 : UI présentable sans designer
Fin du jour 2, ton app marche mais elle a l'air d'un projet d'école. Le jour 3 sert à passer de "ça fonctionne" à "je peux montrer ça à quelqu'un sans m'excuser". Utilise les composants shadcn/ui déjà installés (Button, Card, Dialog, Input, Toast) et demande à Claude Code de refaire tes trois écrans principaux en s'appuyant uniquement sur ces primitives.
Génère aussi une landing page simple : une accroche, trois bénéfices, un CTA vers la page d'inscription, un pied de page. Pas de sections témoignages fictifs, pas de FAQ inventée. Une bonne référence pour cadrer cet exercice : créer une landing page avec Claude.
Deux passes utiles en fin de journée : une passe accessibilité (Claude vérifie les contrastes, les alt sur les images, la navigation clavier) et une passe responsive (les 3 écrans doivent tenir sur 375px de large sans scroll horizontal). Si tu bloques sur des mockups avant de coder, jette un œil au pilier design pour générer des wireframes en amont plutôt qu'en aval.
Jour 4 : paiement, emails, déploiement
Stripe d'abord. Ne fais pas de checkout custom, utilise Stripe Checkout hébergé : tu crées un produit et un prix dans le dashboard Stripe, tu génères un lien de paiement, tu ajoutes un endpoint webhook qui active le compte utilisateur après paiement. Claude Code fait ça en trois prompts si tu lui donnes les clés API en variables d'environnement.
Emails ensuite. Un seul email transactionnel au démarrage : bienvenue après inscription. Resend + un template React Email suffisent. Tu peux voir la mise en oeuvre détaillée sur envoyer des emails avec Resend et Claude.
Déploiement enfin. Tu connectes ton repo GitHub à Vercel, tu ajoutes toutes tes variables d'env (Supabase URL, Supabase anon key, Supabase service role, Stripe secret, Stripe webhook secret, Resend API key), tu branches ton domaine custom. La checklist des 7 points à vérifier avant de partager l'URL :
| # | Point à vérifier | Comment |
|---|---|---|
| 1 | Auth marche en prod | Créer un compte depuis un navigateur privé |
| 2 | Feature coeur marche en prod | Test bout-en-bout sur le domaine custom |
| 3 | Webhook Stripe reçoit | Test un paiement en mode test, vérifier les logs |
| 4 | Email de bienvenue arrive | Vérifier dans un vrai Gmail, pas les spams |
| 5 | 404 et 500 personnalisées | Aller sur une URL bidon, voir une vraie page |
| 6 | Meta tags OG | Coller le lien dans Slack ou WhatsApp, voir l'aperçu |
| 7 | Aucune clé API dans le code client | Rechercher "sk_" dans le bundle Next.js |
Jour 5 : mettre entre les mains de 5 utilisateurs
Cinq testeurs, pas plus, pas moins. Trois d'entre eux doivent correspondre à ton persona cible ; les deux autres peuvent être des amis techniques. Tu leur envoies l'URL avec un message court : "peux-tu passer 10 minutes dessus mardi soir, je te regarde faire en visio, je ne parle pas".
Le script de test tient en 4 étapes : "crée un compte", "fais [la tâche coeur] avec ce fichier que je t'envoie", "paie l'abonnement en mode test avec la carte 4242 4242 4242 4242", "raconte-moi à voix haute ce qui te surprend". Tu observes, tu ne guides jamais. Chaque hésitation de plus de 5 secondes est un signal.
Après les 5 tests, tu prends tes notes brutes et tu demandes à Claude de les ranger dans trois colonnes : bugs (à corriger cette semaine), frictions (à travailler la semaine prochaine), idées (à noter, potentiellement à jeter). Tu décides ce qui part en v0.2 et surtout ce qui va au cimetière. La suite immédiate : 2 semaines d'itération sur les frictions avant un vrai lancement public (Product Hunt, LinkedIn, ta liste email).
Les 4 pièges qui font exploser le planning
Refactorer trop tôt. Ton code sera moche le jeudi, c'est normal. Tu refactoreras en v0.3 quand tu sauras ce qui reste. Contre-mesure : interdiction de toucher au code du jour J-1 sauf si un bug bloque un test utilisateur.
Laisser Claude choisir la stack au fil de l'eau. Si tu ne fixes pas Supabase le lundi, tu vas te retrouver avec Prisma + Neon + NextAuth au mercredi. Contre-mesure : écris ta stack dans le README avant le premier prompt Claude Code.
Ajouter une deuxième feature "vite fait". Elle prendra une journée complète, pas deux heures. Contre-mesure : tout va dans backlog.md, sans exception.
Négliger les seed data. Tu ne peux pas tester un CRM vide. Contre-mesure : demande à Claude Code de générer 20 lignes de données réalistes en fin de jour 2 et lance-les à chaque déploiement local.
Aller plus loin après le jour 5
Un MVP en 5 jours est un point de départ, pas un produit fini. Tu as maintenant une base de code que tu comprends, une URL publique, cinq personnes qui ont un avis. Le vrai travail commence : itérer sur les frictions, décider si tu factures, ajuster ton positionnement. Pour approfondir Claude Code au-delà du scaffold basique, le pilier créer une application avec Claude Code sans être développeur couvre les patterns avancés (agents, MCP, hooks). Pour ceux qui veulent un cadre plus long, avec accompagnement en cohorte et un projet suivi de bout en bout, Construire votre produit IA en 5 semaines reprend la même logique de sprint sur 10 sessions live avec livraison d'une app Next.js + Supabase déployée sur Vercel.