MVP Starter Kit expliqué simplement (avec schémas et vrai code)
MVP Starter Kit : l'essentiel en un article — vrai code, schémas et étapes concrètes, extraits d'un cours de 43 leçons.
Un guide qui va droit au but : MVP Starter Kit décortiqué avec des schémas, des exemples concrets et des commandes testées. Tout vient d'un cours structuré de 11 chapitres — en voici le meilleur.
- Introduction et Mindset MVP
- Ideation et Validation
- Architecture du Starter Kit
- Authentification et Utilisateurs
- Construire le Core du MVP
CRUD avec Server Actions Next.js
Objectifs pédagogiques
- Comprendre ce qu'est une Server Action et pourquoi elle remplace une API REST pour un MVP
- Écrire une action de création, lecture, mise à jour et suppression
- Rafraîchir l'interface avec
revalidatePathaprès une mutation - Valider les entrées côté serveur avant l'écriture en base
- Comprendre comment la RLS sécurise automatiquement chaque requête
L'intuition : appeler une fonction serveur depuis un formulaire
Traditionnellement, pour modifier des données, le client envoie une requête HTTP (fetch('/api/tasks', ...)) à une route API, qui parle à la base, puis renvoie une réponse. Les Server Actions de Next.js suppriment cette plomberie : vous écrivez une fonction marquée "use server", et vous l'appelez directement depuis un formulaire ou un composant. Next.js crée la requête HTTP pour vous, en coulisses.
Pour un MVP, c'est un gain de temps majeur : moins de fichiers, moins de code de sérialisation, pas de gestion manuelle d'états de chargement pour chaque appel. Vous écrivez la logique métier, Next.js s'occupe du transport.
Le client Supabase côté serveur
Toute Server Action a besoin d'un client Supabase qui connaît l'utilisateur connecté (via les cookies de session). On le centralise dans un helper :
Schéma Postgres et migrations Supabase
Objectifs pédagogiques
- Modéliser les entités centrales de votre MVP en tables Postgres
- Écrire une migration SQL versionnée avec la CLI Supabase
- Comprendre et activer Row Level Security (RLS) sur chaque table
- Lier les données à l'utilisateur connecté via
auth.uid() - Garder le schéma simple : ne modéliser que ce que le MVP exige
L'intuition : le schéma raconte ce que fait votre produit
Avant d'écrire la moindre ligne de code applicatif, posez-vous une question simple : quelles sont les 2 ou 3 entités que mon produit manipule ? Une application de gestion de tâches manipule des projets et des tâches. Un SaaS de notes manipule des notes. Un outil de facturation manipule des clients et des factures. Le schéma de base de données est la traduction directe de cette réponse.
La tentation du débutant est de tout prévoir : tags, catégories, historique, pièces jointes, partage. Pour un MVP, on coupe. On garde la table principale, sa relation à l'utilisateur, et c'est tout. On ajoutera le reste quand un vrai client le demandera.
Modéliser les entités du MVP
Prenons un exemple concret : un MVP de gestion de tâches partagées. Deux entités suffisent pour la première version : projects et tasks. Chaque projet appartient à un utilisateur, chaque tâche appartient à un projet.
| Table | Colonnes clés | Relation |
|---|---|---|
projects | id, user_id, name, created_at | appartient à un user (auth.users) |
tasks | id, project_id, title, done, created_at | appartient à un project |
Notez la convention : un identifiant uuid généré automatiquement, une clé étrangère vers le parent, un created_at par défaut. Cette structure se répète pour 90% des tables d'un MVP.
Écrire la migration SQL
Supabase versionne le schéma via des fichiers de migration SQL dans supabase/migrations/. On crée un nouveau fichier avec la CLI :
with check
Contrôle quelles lignes peuvent être insérées ou modifiées. Empêche un user de créer un projet au nom d'un autre.
anon (publique par nature) peut lire toute votre base. C'est la fuite de données numéro un des MVPs Supabase. Activez RLS sur CHAQUE table, sans exception.Appliquer la migration
En local avec le conteneur Supabase, puis vers la base distante :
Webhooks Stripe et synchronisation Supabase
Objectifs pédagogiques
- Comprendre pourquoi le webhook est la seule source de vérité du paiement
- Créer une route webhook dans Next.js
- Vérifier la signature Stripe pour rejeter les fausses requêtes
- Mettre à jour la table d'abonnement dans Supabase
- Tester le webhook en local avec la CLI Stripe
L'intuition : Stripe vous prévient quand quelque chose se passe
Après un paiement, Stripe envoie une requête HTTP à une URL que vous déclarez : c'est un webhook. Cette requête porte un événement (checkout.session.completed, customer.subscription.deleted, etc.). C'est la seule information fiable : la page de retour navigateur peut être rafraîchie, fermée ou fausse, mais le webhook vient des serveurs de Stripe.
Le principe est donc : on n'accorde l'accès payant que lorsque le webhook nous le dit. C'est plus robuste et impossible à contourner par un utilisateur malin.
La table d'abonnement dans Supabase
Cet article couvre les extraits les plus utiles — le cours complet MVP Starter Kit (11 chapitres, 43 leçons, exercices corrigés et projet final) t'emmène jusqu'au bout.
./acceder-au-cours-complet cours gratuit : Vibe CodingFAQ
Combien de temps pour apprendre MVP Starter Kit ?
Faut-il des prérequis ?
Par où commencer concrètement ?
📬 Tu veux recevoir ce type de guide chaque semaine ? Abonne-toi gratuitement — code réel, zéro blabla.