Construire un MVP SaaS en 5 jours avec Claude

Cinq jours pour sortir un SaaS payant, c'est tendu mais faisable, à condition de couper 90% de ce que tu voudrais inclure. Cet article te donne le déroulé jour par jour, les prompts à coller dans Claude Code, et les arbitrages qu'on assume. Pas une success story, un canevas reproductible. Si tu veux le contexte plus large sur le rôle de l'IA dans ton sprint, le guide complet pour apprendre Claude couvre l'amont. Ici on rentre direct dans le sprint.

Ce que veut dire "MVP SaaS en 5 jours" (et ce que ça ne veut pas dire)

Un MVP en 5 jours, c'est : 1 persona, 1 problème, 1 workflow payant. Trois choses, pas quatre. Si tu rajoutes un dashboard analytics, un mode équipe ou une API publique, tu sors du périmètre et tu ne livres rien.

Ce qui rentre dans le sprint :

• Authentification email + Google
• Une feature core de bout en bout
• Paiement Stripe en subscription avec trial
• Onboarding minimal et déploiement en prod sur un domaine custom

Ce qui ne rentre pas : multi-tenant avec invitations, RBAC fin, i18n, mode sombre, dashboard admin, app mobile, intégrations tierces autres que Stripe. Tu les noteras pour plus tard, tu n'y touches pas cette semaine.

Le stack par défaut retenu ici : Next.js déployé sur Vercel et Next.js, Supabase pour auth et base de données, Stripe pour le paiement, et Claude Code comme pair sur le terminal. Pourquoi ce stack ? Parce que chaque brique est documentée à mort, que Claude connaît leurs conventions par cœur, et que tu peux passer du init au déploiement en une commande. Tu peux changer, mais chaque substitution te coûte une demi-journée.

Avant le jour 1 : le cadrage que Claude ne fera pas à votre place

Si tu ouvres Claude Code sans avoir écrit ces quatre choses, tu vas coder dans le vide :

1. Promesse en une phrase : "X fait Y pour Z, en moins de N minutes."
2. Persona précis : titre, contexte, le job-to-be-done exact qu'il essaie de finir.
3. Le workflow payant : les 3 à 5 écrans que l'utilisateur traverse entre "je m'inscris" et "je paie".
4. Pricing initial : un seul plan, un seul prix. Tu ajusteras après.

Avant de coder, colle ça dans Claude (chat, pas Code) pour challenger :

Tu es product manager senior. Voici mon idée de SaaS :
- Promesse : [...]
- Persona : [...]
- Workflow payant : [...]
- Prix : [...]

Donne-moi :
1. Les 3 hypothèses les plus fragiles
2. Le moment "aha" candidat dans les 90 premières secondes
3. Un PRD court (1 page) avec : objectif, scope in, scope out, métriques de succès
4. Les 2 raccourcis techniques qui sauveraient 1 jour

Si tu ne sais pas répondre à "qu'est-ce que l'utilisateur fait dans les 60 premières secondes après login", tu n'es pas prêt. Reviens en arrière, retravaille le workflow, recommence.

Jour 1 : squelette technique et auth

L'objectif du jour 1, c'est d'avoir une URL en HTTPS qui répond, avec un écran de login fonctionnel. Rien de plus.

Init Next.js, premier commit, branchement Vercel : URL live avant midi. Tu n'écris pas une feature avant que le déploiement marche. Cette règle te sauve des soirées entières plus tard.

Prompt Claude Code pour scaffolder :

Initialise un projet Next.js 14 (app router) avec :
- TypeScript strict
- Tailwind + shadcn/ui (composants par défaut, pas de custom)
- Supabase client (auth helpers next)
- Auth email magic link + Google OAuth
- Variables d'env dans .env.local + .env.example
- Server actions activées

Crée les pages : /, /login, /app (protégée), /pricing.
Donne-moi les commandes shell à exécuter dans l'ordre,
puis le contenu de chaque fichier.

Le piège classique du jour 1 : passer quatre heures sur le design system. La réponse : tu utilises les composants shadcn par défaut, tu ne touches ni aux couleurs ni aux polices. Si tu veux travailler le visuel sérieusement après le sprint, voir générer l'identité visuelle et les mockups avec Claude. Pas maintenant.

Avant de fermer la journée : vérifie que l'inscription crée bien une ligne dans la table users de Supabase, que le redirect vers /app marche, et que la page /app est inaccessible sans session. Trois tests manuels, deux minutes.

Jour 2 : la feature core, rien d'autre

Identifie LA feature qui justifie le paiement. Une seule. Exemple concret : un outil qui transforme un transcript de réunion en compte-rendu structuré, ou un générateur de fiches produit e-commerce à partir d'un nom et d'une catégorie, ou un planner éditorial qui sort 4 semaines de contenu LinkedIn.

La méthode avec Claude Code : tu décris la feature en termes d'inputs et d'outputs, tu le laisses proposer le schéma de base de données, tu valides, puis tu itères écran par écran.

Feature : [description en 3 lignes]
Input utilisateur : [type de donnée, taille max, format]
Output : [structure exacte, où c'est stocké, comment on l'affiche]

Proposez :
1. Le schéma Supabase (tables, colonnes, RLS policies)
2. La server action qui traite la requête
3. Les 2 écrans : formulaire d'entrée, page de résultat
4. Le gating : free user voit 1 résultat tronqué, payant voit tout

Ne touche pas à l'auth, elle est déjà en place.

La règle non négociable du jour 2 : aucune feature "nice to have". Pas d'export PDF, pas de partage par lien, pas d'historique avec recherche. Tu notes ces idées dans un fichier backlog.md et tu les ignores jusqu'au lundi suivant.

Pour creuser la posture "vibe coding" avec Claude, l'article sur le vibe coding détaille la boucle prompt-test-corrige.

Jour 3 : paiement Stripe et gating

Stripe Checkout en subscription mode, webhooks pour activer ou désactiver l'accès, une table subscriptions liée à l'user. Un seul plan payant, un trial de 7 jours, pas de free tier compliqué.

Prompt Claude Code pour le webhook :

Génère un webhook handler Next.js (route /api/webhooks/stripe)
qui gère ces events :
- checkout.session.completed : crée/update la row subscriptions, set status=active
- customer.subscription.updated : sync le status
- customer.subscription.deleted : set status=canceled, l'user perd l'accès
- invoice.payment_failed : set status=past_due

Vérification de signature obligatoire (STRIPE_WEBHOOK_SECRET).
Logs structurés à chaque event.
Idempotence : vérifier event.id avant d'agir.

Test en local avec la CLI Stripe : stripe listen --forward-to localhost:3000/api/webhooks/stripe. Tu déclenches un checkout test, tu vérifies que la row apparaît, tu annules, tu vérifies que le status passe à canceled. Vingt minutes de test bien faites te sauvent un weekend.

Le gating côté app : un helper hasActiveSubscription(userId) que tu appelles dans les server actions sensibles. Si false, redirect vers /pricing. Simple, vérifiable.

Jour 4 : onboarding et finitions UX

Première connexion après inscription : où atterrit l'utilisateur, qu'est-ce qu'il fait dans les 90 secondes, comment tu l'amènes au moment aha.

Trois étapes max dans l'onboarding. Si tu en veux quatre, coupe-en une. Exemple : (1) un input préfilled avec un exemple, (2) clic sur "Générer", (3) résultat affiché avec CTA pour passer payant. Pas de tour produit, pas de checklist gamifiée.

Le reste de la journée :

• Emails transactionnels via Resend (welcome, trial ending, payment failed)
• Page de pricing claire : un plan, le prix, 4 bullets, un CTA
• CGU et politique de confidentialité générées avec Claude puis relues ligne à ligne
• Page 404 et page d'erreur custom
• Favicon et metadata OG pour le partage

C'est la journée où tu coupes 80% de ce que tu voulais ajouter. Si tu hésites sur quelque chose, coupe. Tu rajouteras lundi prochain si un utilisateur le demande.

Le setup global de Claude pour ce type de travail (chat + Code, projets, instructions persistantes) est détaillé dans configurer Claude pour un usage quotidien.

Jour 5 : déploiement, monitoring et premiers utilisateurs

Bascule en environnement de prod : variables Stripe live, Supabase project prod (pas staging), domaine custom branché sur Vercel, certificat HTTPS auto.

Monitoring minimal :

• Sentry pour les erreurs serveur et client
• PostHog ou Plausible pour mesurer l'usage (3 events suffisent : signup, first_action, paid)
• Un dashboard Stripe ouvert dans un onglet, point.

Ouverture à 10 utilisateurs identifiés. Pas un Product Hunt, pas un post LinkedIn générique. Dix personnes que tu connais, qui correspondent au persona, à qui tu envoies un message personnalisé avec le lien et une question : "Tu peux essayer dans les 48h et me dire si ça t'a servi ?"

Script de feedback pour les 2 semaines suivantes, en visio, 3 questions :

1. Qu'est-ce que tu as essayé de faire et tu n'as pas réussi ?
2. À quel moment tu as failli abandonner ?
3. Pour quoi tu paierais si on développait la suite ?

Ton MVP n'est pas "fini". Il est en mesure de recevoir un retour utile. C'est la définition correcte.

Les arbitrages qu'on a faits (et ceux qu'on a refusés)

Voici ce qui a été sciemment laissé de côté pendant le sprint et le signal qui justifierait d'y revenir :

Signal inverse, qui justifie d'arrêter le MVP plutôt que de le pousser : aucun des 10 premiers utilisateurs n'arrive au moment aha sans aide, ou personne ne convertit après le trial, ou les retours convergent vers "j'ai pas compris à quoi ça sert". Dans ces cas, tu retournes au cadrage produit, tu ne rajoutes pas des features.

Le rôle exact de Claude dans ce sprint

Claude excelle sur : scaffolding initial, glue code entre Supabase et Next.js, schémas DB simples avec RLS, génération de webhook handlers Stripe, refacto de composants répétitifs, rédaction des CGU et de la politique de confidentialité, copy d'onboarding, messages d'erreur lisibles.

Tu gardes la main sur : choix du persona, arbitrages produit, décision de pricing, qualité du moment aha, ton éditorial de la marque, choix des 10 premiers utilisateurs. Ces décisions ne se déléguent pas, elles se prennent en regardant des humains en face.

Trois prompts de référence à garder dans un fichier prompts.md à la racine du repo :

1. Prompt de cadrage (avant le jour 1, déjà donné plus haut)
2. Prompt de génération de feature (jour 2, déjà donné)
3. Prompt de revue avant déploiement :

Voici le diff de ma branche avant merge en prod.
Revue critique en 4 points :
1. Risques de sécurité (injection, fuite de données, RLS manquante)
2. Bugs probables (edge cases, états null, race conditions)
3. Performance (requêtes N+1, payloads inutiles)
4. Code mort ou commentaires TODO oubliés

Sois direct, liste les fichiers et lignes concernés.

Pour aller plus loin sur la stack applicative complète (architecture, déploiement, scaling après le MVP), la page créer une application avec Claude Code couvre l'après-sprint.

Et maintenant

Tu as le canevas. Cinq jours, un persona, un workflow payant, un stack qui tient. Le seul vrai obstacle qui reste, c'est de couper ce qui ne sert pas, jour après jour, sans céder à la tentation d'ajouter "juste une petite chose".

Si tu veux faire cet exercice encadré, avec une cohorte qui sprint en parallèle et un suivi sur tes arbitrages produit, on a construit un parcours dédié : Construire votre produit IA en 5 semaines avec Claude Builders. Cinq semaines plutôt que cinq jours, parce qu'on prend le temps de valider chaque étape avec de vrais utilisateurs avant de pousser la suivante.