Killer SaaS : la méthode pour cloner n'importe quel SaaS en une journée

Il y a quelques semaines, j'ai enregistré une vidéo dans laquelle j'annonçais la fin des SaaS mono-fonctionnalité. Ces petits produits qu'un développeur sortait en quelques week-ends pour générer un complément de revenu. Aujourd'hui, n'importe qui avec un agent de code peut les reproduire, donc ce modèle est terminé.

On se disait que les SaaS un peu plus avancés, eux, étaient à l'abri. Ce n'est pas le cas. Avec les bonnes méthodes, on peut reproduire à peu près n'importe quel type de SaaS. C'est ce que je montre dans cette vidéo.

Le déclencheur : 1 800 dollars par an pour rien

J'ai une plateforme qui héberge mes formations, celles que vous connaissez : Next Mastery, React Mastery, et les autres. Elle me coûte plus de 1 800 dollars par an.

Le problème, c'est que je vous ai donné ces formations gratuitement. Elles ne me génèrent donc plus aucun revenu, mais elles continuent de me coûter 1 800 dollars chaque année.

C'est exactement le genre de situation où reproduire l'outil en interne devient rentable.

L'objectif n'est pas de concurrencer Podia

Soyons clairs sur l'intention. Le but n'est pas de construire un SaaS pour aller affronter Podia ou Teachable sur leur marché.

Le but, c'est d'avoir des outils internes qui font économiser de l'argent. La différence est importante : un outil interne n'a pas besoin de support client, de marketing, de facturation multi-devises ni de conformité à grande échelle. Il doit juste faire le travail dont vous avez besoin, pour vous.

Pourquoi j'ai créé une méthode dédiée

J'ai testé beaucoup de méthodes agentiques. Super Power, Every Single Code, Matob, les GStack, Spec Kit, les systèmes d'agences. J'en parle souvent sur la chaîne.

Ce sont de très bonnes méthodes, qui permettent de faire du véritable engineering. Mais elles sont généralistes. Aucune n'est taillée pour un objectif précis : reproduire un SaaS existant, vite et avec une qualité de production.

C'est pour ça que j'ai développé Killer SaaS, une méthode qui permet de reproduire quasiment n'importe quel type de SaaS en environ une journée.

Le workflow, étape par étape

La méthode fonctionne par user story. Pour chacune, l'agent enchaîne les mêmes phases :

1. Research : il cherche ce dont la story a besoin. Les routes, les composants, le détail des champs, la structure de données.
2. Design : il produit les écrans correspondants.
3. Planification détaillée : il découpe l'implémentation.
4. Execute : il écrit le code.
5. Review : il relit son propre travail.
6. Ship : il crée la pull request, la merge, et ça part en production.

À n'importe quel moment du workflow, une commande permet de savoir où on en est :

ks status

ks pour Killer SaaS. Vous voyez immédiatement l'état d'avancement de chaque story.

Le découpage en user stories

La première étape passe par un skill dédié, agentic-stories, qui transforme le besoin en user stories exploitables. Chaque story est rédigée dans le format classique : « en tant que formateur, je veux… », avec ses critères d'acceptation.

Des commandes, pas des prompts

Je fonctionne beaucoup par commandes. La méthode est basée sur Claude, mais elle est déclinée pour Codex : chaque commande existe avec une cible différente. Par défaut c'est Claude, et vous avez les variantes pour Codex, en projet ou en global.

Le boilerplate, ce qui fait gagner la journée

La vitesse ne vient pas seulement de l'agent. Elle vient surtout du fait que le socle technique est déjà là. Ce que le boilerplate intègre :

• Paiement : le SDK Stripe
• Autorisation : CASL
• Validation : Zod
• Multilingue : i18n avec next-intl
• Formulaires : React Hook Form
• Stockage des images : Supabase
• Jobs : Inngest
• Tests unitaires et tests end-to-end

Les tests end-to-end, le point que je sous-estimais

Avant, je faisais les tests end-to-end par acquit de conscience. Je me disais que c'était bien de les avoir, sans plus.

Ce qui a changé : une fois les tests end-to-end en place, Claude sait très bien s'en servir. Il est capable de se connecter, de créer des données, de jouer un parcours complet. Ça devient un outil de vérification pour l'agent lui-même, pas seulement une case à cocher.

La structure en couches

Le repo suit un découpage classique mais strict, dans src/app :

• la couche services, découpée par authentification, autorisation, façades, validations et validateurs ;
• la couche DB, avec les modèles et les repositories.

Quand l'agent implémente une story, il repasse bien par la couche service et la façade, comme le spécifie le boilerplate. Ce n'est pas lui qui décide de l'architecture : elle est déjà posée.

Le parallélisme

C'est le point qui change le rapport au temps. Les phases de research et de design ne sont pas exécutées story après story : toutes les user stories tournent en parallèle.

Pendant que l'agent travaille sur une story, il travaille aussi sur les autres. C'est ce qui permet de tenir la journée au lieu de la semaine.

Le résultat

À la fin du cycle, plus de 20 pull requests ont été mergées, générées automatiquement par Claude.

L'application tourne : thème clair et sombre, catalogue de formations, page de profil, achat d'une formation directement via Stripe. Avec la carte de test Stripe, le paiement fonctionne de bout en bout.

Ce qui n'est pas parfait

Je préfère le dire. Le résultat n'est pas fini au sens produit du terme.

Il reste du travail visuel : les images ne sont pas en place, les données affichées sont encore des données de test, et certains écrans mériteraient une passe de design supplémentaire. La phase de design system devrait aller plus loin sur les maquettes.

Un point de méthode que je referais différemment : il vaut mieux découper le design system et chaque écran séparément, plutôt que de tout lancer d'un coup. Sans la phase de research en amont, l'agent ne connaît pas le détail exact des champs, et il produit des maquettes approximatives.

Ce qu'il faut retenir

Reproduire un SaaS avancé n'est plus une question de mois de développement. C'est une question de méthode, de socle technique préparé, et d'un agent qu'on laisse travailler en parallèle sur des stories bien découpées.

Le vrai calcul n'est pas « est-ce que je peux battre Podia ». C'est « est-ce que cet abonnement annuel vaut encore la journée de travail qu'il me faudrait pour le remplacer ».

Dans mon cas, à 1 800 dollars par an pour un service dont je n'utilise qu'une fraction, la réponse était non.