/saas — Constructeur SaaS Full-Stack
Déclencheur : /saas [idée] ou simplement /saas (demande l'idée)
Résultat : Un SaaS complet, prêt pour la production, déployé sur une URL Vercel. Authentification fonctionnelle, backend réel, données en direct, interface utilisateur superbe. Pas une démo. Pas un échafaudage. Un véritable produit.
APERÇU DU PIPELINE
RÉCEPTION → RECHERCHE (parallèle) → PLANIFICATION → CLARIFICATION → CONSTRUCTION → TEST → RÉVISION → DÉPLOIEMENT
Chaque phase conditionne la suivante. Pas de raccourcis. Pas de saut.
PHASE 1 — RÉCEPTION
Si l'utilisateur a exécuté /saas [idée], extraire l'idée de la commande.
S'il a exécuté /saas sans argument, demander :
Quelle est l'idée SaaS ? Décris-la en 1 à 3 phrases. Inclus :
- Ce qu'elle fait
- À qui elle s'adresse
- Quel problème elle résout
Stocker comme IDEA. Confirmer en une phrase avant de continuer.
PHASE 2 — RECHERCHE PARALLÈLE
Lancer deux pistes de recherche simultanément avec l'outil Agent. Ne PAS attendre la fin d'une pour commencer l'autre.
Piste A — Analyse du marché
Lancer un agent general-purpose avec cette invite :
Analyse le marché SaaS pour cette idée : [IDEA]
Fournis un rapport structuré couvrant :
1. ACTEURS EXISTANTS (5-8 concurrents)
- Nom, URL, niveaux de prix, positionnement
- Ce qu'ils font bien, ce qu'ils ratent
- ARR estimé si disponible
2. TAILLE DU MARCHÉ ET DEMANDE
- Catégorie (CRM, gestion de projet, analytics, etc.)
- Estimation de la taille du marché
- Tendance de croissance (croissance/stagnation/déclin)
- Preuves de demande (fils Reddit, votes ProductHunt, offres d'emploi)
3. RÉFÉRENCES DE TARIFICATION
- Freemium vs payant uniquement vs essai
- Niveaux de prix typiques ($/utilisateur/mois, forfait, à l'usage)
- Quels modèles gagnent dans cette catégorie
4. TABLEAU DES FONCTIONNALITÉS
- Liste les 10 fonctionnalités les plus courantes chez les concurrents
- Marque celles qui sont essentielles vs différenciatrices
5. ESPACE LIBRE
- Que ne font PAS les concurrents ?
- Où les utilisateurs se plaignent-ils ? (consulter G2, Capterra, Reddit)
- Quelle est l'opportunité de niche ?
Retourne du markdown structuré. Sois précis. Pas de blabla.
Piste B — Recherche de patterns techniques
Lancer un second agent general-purpose :
Analyse les patterns d'implémentation technique pour ce type de SaaS : [IDEA]
Fournis :
1. PATTERNS DE MODÈLE DE DONNÉES
- Quelles tables/entités ce type d'application nécessite-t-il généralement ?
- Relations et contraintes clés
- Approche multi-locataire (row-level org_id vs schémas séparés)
2. PATTERNS D'AUTHENTIFICATION
- Ce type d'application a-t-il besoin de connexion sociale ? Magic link ? SSO ?
- Invitation uniquement vs inscription ouverte ?
- Patterns de rôles (admin/membre/observateur typique ?)
3. PATTERNS DE FACTURATION
- Par siège, à l'usage ou forfait ?
- Stratégie de niveau gratuit qui fonctionne dans cet espace ?
4. BESOINS D'INTÉGRATION
- Avec quoi les applications de cette catégorie s'intègrent-elles généralement ?
- Webhooks, Zapier, clés API ?
5. RISQUES TECHNIQUES
- Qu'est-ce qui est difficile à construire dans cette catégorie ?
- Qu'est-ce que les équipes font souvent mal ?
- Considérations de performance/échelle
Retourne du markdown structuré. Sois précis.
Attendre la fin DES DEUX pistes avant de continuer.
PHASE 3 — PLAN D'ARCHITECTURE
En utilisant les deux résultats de recherche, produire un plan de construction structuré. Écrire ceci dans .saas-workspace/[project-slug]/PLAN.md.
Le plan doit inclure :
3.1 Définition du produit
## Produit
Nom : [dérivé de l'idée, modifiable]
Slogan : [une ligne]
Proposition de valeur principale : [une phrase]
Utilisateur cible : [persona spécifique]
## Ensemble de fonctionnalités MVP (ce que nous construisons AUJOURD'HUI)
- [Fonctionnalité 1] — [pourquoi elle est dans le périmètre]
- [Fonctionnalité 2] — [pourquoi elle est dans le périmètre]
...
## Hors périmètre (v1)
- [Fonctionnalité] — [reportée en v2 car...]
3.2 Modèle de données
Concevoir le schéma Postgres complet. Pour chaque table :
- Nom de la table, objectif
- Toutes les colonnes avec types, contraintes, valeurs par défaut
- Relations de clés étrangères
- Politiques RLS nécessaires
- Index
Commencer par ces tables requises :
-- Toujours inclure :
profiles (étend auth.users)
organizations (si multi-locataire)
organization_members (si multi-locataire)
subscriptions (si facturation)
Puis ajouter les tables spécifiques au domaine pour le produit.
3.3 Plan des routes
Page d'accueil : /
Authentification : /login /signup /auth/callback
Shell d'application : /app (nécessite authentification)
Fonctionnalités principales : /app/[fonctionnalité] (une par fonctionnalité MVP)
Paramètres : /app/settings
Routes API : /api/... (lister chacune)
3.4 Confirmation de la pile technique
Framework : Next.js 15 (App Router, TypeScript)
Base de données : Supabase (Postgres + Auth + RLS)
Style : Tailwind CSS v4 + shadcn/ui
Email : Resend (transactionnel)
Déploiement : Vercel
Paiements : Stripe (si facturation nécessaire)
3.5 Ordre de construction
Lister la séquence exacte : migrations → auth → routes API → shell d'application → fonctionnalités → page d'accueil → modèles d'email → tests.
PHASE 4 — QUESTIONS DE CLARIFICATION
Avant d'écrire une seule ligne de code, identifier les lacunes. Utiliser AskUserQuestion pour poser les questions suivantes (regrouper en max 4 questions par appel) :
Tour 1 — Périmètre du produit :
- Confirmer le nom (présenter 3 options dérivées de l'idée)
- Multi-locataire (équipes/orgs) ou comptes utilisateur unique ?
- La v1 nécessite-t-elle des paiements/facturation, ou est-elle gratuite pendant la construction ?
- Y a-t-il des fonctionnalités spécifiques issues de la recherche qui sont indispensables vs optionnelles ?
Tour 2 — Conception et déploiement (ne demander que si les réponses du Tour 1 soulèvent de nouvelles questions) :
- Domaine ? (ou utiliser le sous-domaine Vercel pour l'instant)
- Des couleurs de marque / préférences ? (par défaut : système vert foncé Rawgrowth)
- Adresse email de l'expéditeur pour Resend ?
Intégrer les réponses dans PLAN.md avant de continuer.
PHASE 5 — CONSTRUCTION
Configuration pré-construction
Charger ces compétences avant d'écrire du code :
frontend-theme— injecte le système de design complet Rawgrowthui-ux-pro-max— décisions de design, palette, typographie- Invoquer Magic MCP (
@21st-dev/magic) pour les composants complexes
Emplacement du projet : Créer dans ~/saas-projects/[project-slug]/
Commande d'échafaudage :
cd ~/saas-projects
npx create-next-app@latest [project-slug] \
--typescript \
--tailwind \
--eslint \
--app \
--src-dir \
--import-alias "@/*" \
--no-git
cd [project-slug]
Installer les dépendances :
npm install @supabase/supabase-js @supabase/ssr \
resend \
@radix-ui/react-icons \
lucide-react \
class-variance-authority clsx tailwind-merge \
zod \
@hookform/resolvers react-hook-form
# shadcn/ui init
npx shadcn@latest init --defaults
# Ajouter les composants shadcn
npx shadcn@latest add button input label card \
dropdown-menu avatar badge separator toast \
dialog sheet tabs form
Configuration Tailwind v4 — appliquer les jetons frontend-theme à src/app/globals.css.
5.1 Base de données et migrations
Utiliser la compétence add-migration pour chaque migration.
Migration 1 : Schéma de base
-- Activer RLS sur toutes les tables exposées aux utilisateurs
-- profiles : étend auth.users
CREATE TABLE profiles (
id UUID REFERENCES auth.users(id) ON DELETE CASCADE PRIMARY KEY,
email TEXT NOT NULL,
full_name TEXT,
avatar_url TEXT,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Les utilisateurs peuvent voir leur propre profil"
ON profiles FOR SELECT USING (auth.uid() = id);
CREATE POLICY "Les utilisateurs peuvent mettre à jour leur propre profil"
ON profiles FOR UPDATE USING (auth.uid() = id);
-- Créer automatiquement un profil lors de l'inscription
CREATE OR REPLACE FUNCTION public.handle_new_user()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO public.profiles (id, email, full_name, avatar_url)
VALUES (
NEW.id,
NEW.email,
NEW.raw_user_meta_data->>'full_name',
NEW.raw_user_meta_data->>'avatar_url'
);
RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE TRIGGER on_auth_user_created
AFTER INSERT ON auth.users
FOR EACH ROW EXECUTE FUNCTION public.handle_new_user();
Migration 2 : Organisations (si multi-locataire)
CREATE TABLE organizations (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
name TEXT NOT NULL,
slug TEXT UNIQUE NOT NULL,
owner_id UUID REFERENCES profiles(id) ON DELETE CASCADE NOT NULL,
plan TEXT DEFAULT 'free',
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE organization_members (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
org_id UUID REFERENCES organizations(id) ON DELETE CASCADE NOT NULL,
user_id UUID REFERENCES profiles(id) ON DELETE CASCADE NOT NULL,
role TEXT NOT NULL DEFAULT 'member' CHECK (role IN ('owner', 'admin', 'member')),
created_at TIMESTAMPTZ DEFAULT NOW(),
UNIQUE(org_id, user_id)
);
ALTER TABLE organizations ENABLE ROW LEVEL SECURITY;
ALTER TABLE organization_members ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Les membres peuvent voir leur organisation"
ON organizations FOR SELECT
USING (id IN (
SELECT org_id FROM organization_members WHERE user_id = auth.uid()
));
CREATE POLICY "Les membres peuvent voir les appartenances à l'organisation"
ON organization_members FOR SELECT
USING (org_id IN (
SELECT org_id FROM organization_members WHERE user_id = auth.uid()
));
Migration 3+ : Tables domaine — créer les tables spécifiques au produit selon le modèle de données dans PLAN.md. Appliquer RLS à chaque table.
5.2 Configuration du client Supabase
src/lib/supabase/client.ts :
import { createBrowserClient } from '@supabase/ssr'
export function createClient() {
return createBrowserClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
)
}
src/lib/supabase/server.ts :
import { createServerClient } from '@supabase/ssr'
import { cookies } from 'next/headers'
export async function createClient() {
const cookieStore = await cookies()
return createServerClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
{
cookies: {
getAll() { return cookieStore.getAll() },
setAll(cookiesToSet) {
try {
cookiesToSet.forEach(({ name, value, options }) =>
cookieStore.set(name, value, options)
)
} catch {}
},
},
}
)
}
src/middleware.ts — protéger toutes les routes /app/*, rediriger les utilisateurs non authentifiés vers /login.
5.3 Pages d'authentification
Construire /login et /signup comme des pages complètes (pas des modales). Appliquer frontend-theme :
- Fond sombre (#060B08)
- Carte centrée avec bordure (rgba(255,255,255,0.06))
- Boutons CTA verts (#0CBF6A)
- Champs email + mot de passe (+ connexion sociale si configurée)
- Lien "Mot de passe oublié"
- Pas d'émojis. Propre, premium, minimal.
src/app/(auth)/login/page.tsx — formulaire de connexion avec Supabase Auth
src/app/(auth)/signup/page.tsx — formulaire d'inscription avec flux de confirmation par email
src/app/auth/callback/route.ts — gestionnaire de callback OAuth/magic link
Flux de confirmation par email :
- Lors de l'inscription → Supabase envoie un email de confirmation (via Resend SMTP)
- La route callback échange le code pour une session
- Rediriger vers
/app/dashboarden cas de succès
5.4 Shell d'application
src/app/(app)/layout.tsx — layout authentifié avec :
- Barre latérale (réductible sur mobile)
- Navigation supérieure avec avatar utilisateur + menu déroulant (profil, paramètres, déconnexion)
- Fil d'Ariane
- Zone de notification toast
Éléments de la barre latérale dérivés du plan des routes dans PLAN.md.
Utiliser Magic MCP pour récupérer un composant de barre latérale : rechercher "dashboard sidebar dark" et adapter aux jetons frontend-theme.
5.5 Pages de fonctionnalités principales
Pour chaque fonctionnalité de l'ensemble MVP (de PLAN.md) :
- Concevoir d'abord — interroger Magic MCP pour les patterns de composants pertinents
- Couche de données — les composants serveur récupèrent les données directement depuis Supabase
- Mutations — Actions serveur avec validation Zod
- États d'erreur — chaque formulaire a des erreurs de validation, des états de chargement, des états vides
- Pas de types
any— générer les types TypeScript à partir du schéma Supabase
Pattern pour le composant serveur de récupération de données :
import { createClient } from '@/lib/supabase/server'
import { redirect } from 'next/navigation'