Nous avons construit la facturation avant de construire les fonctionnalités.

L’opinion la moins populaire dans les startups

Voici quelque chose que vous n’entendrez pas lors d’une rencontre de startup : nous avons mis en place la facturation dès le troisième jour.

Pas la page de tarification. Pas le “nous verrons la monétisation plus tard” en agitant la main. Une véritable synchronisation des abonnements, des gardes de paiement et un suivi de l’utilisation. Avant même d’avoir construit la moitié de nos fonctionnalités.

Chaque mentor, chaque article de blog, chaque vidéo de Y Combinator dit la même chose : ne vous inquiétez pas pour la monétisation pour l’instant. Concentrez-vous sur l’acquisition d’utilisateurs. Les revenus peuvent venir plus tard.

Nous ne sommes pas d’accord.

Pourquoi facturer en premier est en réalité centré sur l’utilisateur

L’argument contre la facturation précoce est qu’elle “détourne de la construction.” Mais voici ce qui se passe réellement lorsque vous retardez la facturation :

Vous construisez une plateforme d’IA où chaque utilisateur a un accès illimité. Vous acquérez des utilisateurs qui adorent cet accès illimité. Puis un jour, vous actionnez le interrupteur et dites à ces utilisateurs qu’ils doivent payer. Certains le feront. La plupart ne le feront pas. Et ceux qui restent sont ceux qui utilisaient des fonctionnalités correspondant à vos niveaux de tarification conçus à la hâte.

Nous ne voulions pas de cet avenir.

En construisant la facturation dès le troisième jour, chaque fonctionnalité que nous avons ajoutée par la suite a été conçue en tenant compte de l’échelon auquel elle appartenait. “Cela doit-il être dans le niveau gratuit ou pro ?” est devenu une question naturelle lors du développement, et non un douloureux ajustement six mois plus tard.

À quoi ressemblait le troisième jour

24 novembre 2025. Trois jours après le premier commit. Le produit avait un chat, une gestion de fichiers, des espaces de travail et des capacités d’agent de base. Voici ce que nous avons ajouté :

Synchronisation des abonnements via RabbitMQ. Notre service de facturation envoie des mises à jour sur l’état des abonnements. Le tableau de bord les reçoit et sait exactement quel plan chaque utilisateur utilise. En temps réel. Pas de polling. Pas de données obsolètes.

Gardiens de facturation sur les routes protégées. Essayez d’accéder à une fonctionnalité pro sans un abonnement pro ? Vous obtenez un modal clair expliquant la limite et comment passer à l’étape supérieure. Pas de plantage. Pas de page blanche. Une expérience conçue.

Suivi des crédits. Nous suivons l’utilisation de l’IA par utilisateur. Pas parce que nous voulons gratter chaque centime, mais parce que des coûts prévisibles nécessitent un suivi d’utilisation prévisible. Les utilisateurs d’OpenClaw rapportent dépenser entre 50 et 750 $/mois sans aucune visibilité sur l’utilisation de leur argent. Nous avons décidé que cela ne serait jamais notre histoire.

Gestion des abonnements annuels. Parce que nous savions que certains utilisateurs voudraient payer annuellement, et ajouter cela “plus tard” signifie toujours l’ajouter mal.

Le bénéfice cumulatif

Voici ce que la plupart des gens manquent à propos de la facturation en premier : cela se cumule.

Lorsque nous avons ajouté la génération d’images deux semaines plus tard, le garde de facturation était déjà en place. Nous avons juste étiqueté la génération d’images comme une fonctionnalité pro et cela a fonctionné. Pas de code de facturation supplémentaire.

Lorsque nous avons ajouté le marché des compétences, même chose. Les utilisateurs gratuits voient un badge “Pro” sur les compétences premium. Pas de nouvelle logique de facturation nécessaire.

Lorsque nous avons ajouté l’exécution de tâches en arrière-plan, le compteur d’exécution du sandbox suivait déjà l’utilisation. Nous avons juste défini les limites par niveau.

Chaque fonctionnalité que nous avons construite au cours des 80 derniers jours a hérité de la conscience de facturation gratuitement. C’est le bénéfice cumulatif de construire les fondations tôt.

Le vrai coût du “plus tard”

Nous avons vu d’autres startups dans notre domaine lutter avec cela. Elles construisent de beaux produits avec tout illimité. Puis elles essaient d’ajouter la facturation et découvrent :

• Leur base de données ne suit pas l’utilisation par utilisateur
• Leur API ne fait pas la distinction entre les opérations gratuites et payantes
• Leur frontend n’a pas de concept de “vous ne pouvez pas faire cela avec votre plan”
• Leurs utilisateurs se sentent trahis lorsque des limites apparaissent

Intégrer la facturation dans un produit qui a été conçu sans elle est l’une des choses les plus coûteuses qu’une startup puisse faire. Pas en termes d’argent — en termes de dette architecturale et de confiance des utilisateurs.

Tarification basée sur les crédits

Notre tarification s’est avérée simple : achetez des crédits, utilisez des crédits. Vous obtenez 20 000 crédits gratuits à l’inscription et 5 générations d’IA gratuites par jour. Lorsque vous avez besoin de plus, achetez un pack de crédits. Les modèles moins chers coûtent moins de crédits, les modèles premium coûtent plus. Le code de facturation qui suit cela a été écrit le troisième jour et fonctionne depuis.

Chaque utilisateur sait exactement ce pour quoi il paie. Personne ne reçoit de facture surprise.

Ce n’est pas parce que nous sommes généreux. C’est parce que nous avons construit la facturation avant de construire des fonctionnalités.