Comment je construis des produits SaaS avant que l'argent ne s'épuise

Chaque produit SaaS que j'ai construit dans des conditions réelles de startup partage une contrainte définissante : la thèse doit être prouvable avant que la piste ne s'épuise. Ce n'est pas un point philosophique. Cela façonne chaque décision architecturale, chaque intégration tierce, et chaque fonctionnalité que vous acceptez de supprimer. Ceci est une note de terrain sur ma façon d'aborder l'ingénierie de produits SaaS de zéro à un, écrite à partir du travail plutôt que de la théorie.

Les choix de stack qui vous gagnent du temps

Le plus grand goulot d'étranglement dans les premiers SaaS n'est pas la fonctionnalité principale. C'est la plomberie : l'authentification, la facturation, les tâches de fond, et la persistance des données.

Pour l'authentification, j'ai arrêté de construire des flux personnalisés entièrement. Les fournisseurs spécialisés d'identité en tant que service comme Clerk et WorkOS gèrent les passkeys, l'authentification unique d'entreprise, et la multi-location prêts à l'emploi. Une équipe fondatrice n'a pas besoin de posséder cette surface. Le risque est trop élevé et le coût de maintenance s'accumule.

Pour les données, je me fie par défaut à PostgreSQL avec l'extension pgvector. Il y a quelques années, un produit avec n'importe quelle fonctionnalité adjacente à l'IA aurait nécessité une base de données vectorielle séparée aux côtés du magasin relationnel. Cette séparation créait deux systèmes à migrer, sauvegarder, et sur lesquels raisonner sous pression. L'approche unifiée réduit considérablement cette surcharge, et les performances sont de qualité production.

Pour la facturation, le modèle hybride est maintenant l'attente de base : des niveaux d'abonnement à tarif fixe combinés avec une mesure basée sur l'utilisation. Les moteurs de facturation comme Lago s'intègrent à Stripe et vous donnent cette flexibilité sans écrire un système de facturation à partir de zéro. Mal concevoir l'architecture de tarification au départ est coûteux à corriger, donc je la traite comme une infrastructure, pas une décision de produit à reporter.

Quand le travail d'IA en arrière-plan change la forme du produit

Le passage des simples fonctionnalités d'IA de prompt-et-réponse aux flux multi-agents a changé ce que les produits SaaS peuvent promettre. Des frameworks comme LangGraph et CrewAI permettent des tâches de fond asynchrones et orchestrées qui s'exécutent sans que l'utilisateur attende à l'écran. Cela change entièrement le modèle de produit.

En travaillant sur certains projets, j'ai eu besoin d'un traitement de fond qui coordonnait l'état entre plusieurs acteurs sans bloquer l'interface utilisateur principale. Le modèle architectural là, séparant la couche d'orchestration de l'application orientée utilisateur, est le même que j'applique maintenant aux produits SaaS lourds en IA. L'utilisateur soumet un travail. Le système fonctionne. Le résultat arrive. Cette boucle est plus robuste que d'essayer de tout diffuser en continu.

La contrainte qui rend cela difficile est l'observabilité. Quand quelque chose échoue à l'intérieur d'un flux multi-agent asynchrone, vous devez savoir exactement quelle étape a échoué et pourquoi. J'instrumente chaque nœud d'agent avec une journalisation structurée dès le premier jour, pas comme une étape de finition. Déboguer une défaillance silencieuse en production sans trace est le genre de problème qui tue un sprint.

Délimiter le MVP sans perdre la thèse

La conversation la plus difficile dans un engagement de zéro à un est la portée. Un fondateur arrive avec une vision de produit qui est cohérente et ambitieuse. Le travail est de trouver la plus petite version qui prouve encore la thèse principale, pas seulement la plus petite version qui sort.

Avec Job Hunter, un tableau d'affichage d'emplois quotidien et un moteur de sensibilisation, la thèse était que l'exploration automatisée et la sensibilisation personnalisée pouvaient réduire de manière significative le travail manuel d'une recherche d'emploi. La preuve exigeait que l'exploration fonctionne réellement à l'échelle sur 185+ pages de carrière, et que la sensibilisation soit suffisamment personnalisée pour être utile. Couper l'un ou l'autre aurait invalidé la thèse. Nous avons donc coupé le vernis du tableau de bord, les préférences de notification, et les formats d'exportation. Ceux-ci sont venus plus tard.

La discipline consiste à savoir quelles fonctionnalités sont porteuses pour la thèse et lesquelles sont des fonctionnalités de confort pour la démo. Les fonctionnalités de confort semblent importantes dans la salle. Elles ne le sont pas.

La décision d'architecture multi-location que vous ne pouvez pas reporter

Pour tout produit SaaS servant plus d'une organisation, la multi-location n'est pas un détail d'implémentation que vous pouvez ajouter plus tard. Le modèle d'isolation des données doit être décidé avant la première migration.

J'ai travaillé sur trois approches : schéma partagé avec des identifiants de location, schémas séparés par location, et bases de données séparées par location. Chacune a un profil de coût différent et un plafond différent. L'approche de schéma partagé est la moins chère à exploiter à petite échelle et la plus douloureuse à migrer quand un client d'entreprise exige une isolation des données plus stricte. Je me fie par défaut à des schémas séparés sauf si le modèle commercial rend cela opérationnellement impossible.

C'est le genre de décision qui appartient à un examen de diligence raisonnable technique avant qu'un produit ne soit construit, pas après. Si vous vous dirigez vers un tour de financement initial et que votre modèle de multi-location n'est pas documenté ou incohérent, cela apparaîtra dans le processus de diligence raisonnable et cela ralentira la clôture.

Sortir la première version sous des contraintes réelles

J'ai construit Fursa, un produit d'admissibilité aux visas, avec une portée étroite mais précise : étant donné le profil d'un utilisateur, identifier quelles routes de visa sont réellement viables dans quatre pays de destination. La contrainte était que la logique d'admissibilité sous-jacente est complexe, change avec les mises à jour de politique, et ne peut pas se tromper d'une manière qui induirait un utilisateur en erreur dans une erreur coûteuse.

L'architecture séparait les règles d'admissibilité de la couche d'inférence afin que les mises à jour de politique puissent être appliquées sans redéployer le modèle. Cette séparation a ajouté une semaine à la construction initiale. Elle a économisé beaucoup plus de temps dans les mois suivant le lancement quand les règles ont changé, comme elles le font toujours.

Sortir sous des contraintes réelles signifie faire des compromis explicites et les documenter. Pas chaque compromis est mauvais. Certains sont corrects compte tenu des informations et de la piste à l'époque. Ceux qui font mal plus tard sont ceux faits sans reconnaissance.

Ce que la prochaine étape ressemble réellement

Si vous construisez un produit SaaS et essayez de décider si l'architecture est solide avant de vous engager plus de capital, c'est un problème concret avec une réponse concrète. J'offre un examen technique ciblé qui examine le stack, le modèle de données, l'approche multi-location, et l'architecture de facturation, et vous donne une évaluation écrite sur laquelle vous pouvez agir.

Vous pouvez voir l'étendue complète du travail de produit dans les secteurs à /work, y compris les études de cas de produits SaaS et IA référencées ici. Si vous voulez discuter d'une construction spécifique, le formulaire de contact est l'itinéraire le plus rapide vers une vraie conversation.

Le meilleur moment pour tester une architecture est avant que le premier client d'entreprise ne pose une question à laquelle vous ne pouvez pas répondre.