En bref — DHH et Basecamp relancent le paiement unique contre l'abonnement SaaS. Ce que ça change concrètement pour les makers bootstrappés qui veulent sortir du MRR.

once DHH basecamp modèle paiement unique logiciel Image : Startup Stock Photos — Openverse (cc0)

En bref — DHH et Basecamp ont lancé Once, une gamme de logiciels vendus en paiement unique où l'acheteur reçoit le code source et l'héberge lui-même — rupture directe avec le SaaS à abonnement. Pour les makers bootstrappés, c'est une piste sérieuse, mais elle exige une discipline de pricing et de distribution que l'abonnement mensuel permet de reporter indéfiniment.

Le SaaS à abonnement, c'est le modèle qu'on a tous intégré comme une évidence. MRR, churn, LTV, ARR — le vocabulaire s'est imposé avec la mécanique. Et puis DHH a posé une bombe tranquille : et si on revenait à vendre des logiciels comme on vend des livres ?

C'est la promesse d'Once, la nouvelle gamme de Basecamp. Payer une fois. Posséder le code. L'héberger où tu veux. Fin de la dépendance.

Pour un maker bootstrappé qui cherche à construire quelque chose de solide sans se noyer dans la course au MRR, la question mérite d'être prise au sérieux — pas comme une posture idéologique, mais comme un vrai choix de modèle économique.

C'est quoi 'Once' ? Le pari radical de DHH contre le SaaS classique

Once, c'est la réponse de Basecamp à ce que DHH appelle le « racket de l'abonnement ». Le principe est simple : tu paies une fois, tu reçois le code source, tu l'installes sur ton propre serveur. Pas de compte chez Basecamp, pas de données chez eux, pas de facture mensuelle qui revient.

Le premier produit de la gamme est Campfire, un outil de chat d'équipe. L'idée est explicitement positionnée comme une alternative à Slack — mais vendue, pas louée.

Ce n'est pas une nouveauté absolue. Avant le règne du SaaS, tous les logiciels fonctionnaient ainsi. Tu achetais une boîte, tu installais, tu possédais. Ce que DHH fait, c'est ressortir ce modèle du placard et le réhabiliter avec un argument contemporain fort : la souveraineté des données et la fin de la dépendance fournisseur.

Pour les makers, l'angle est différent de celui des grandes entreprises. Ce n'est pas tant la souveraineté des données qui est en jeu — c'est la structure de revenus. Et là, ça devient intéressant.

Les arguments économiques : pourquoi le paiement unique peut battre un MRR fragile

Le MRR est présenté comme le Graal. Revenus prévisibles, croissance lissée, valorisation multipliée. Sauf que pour un solopreneur ou une micro-équipe bootstrappée, le MRR a un envers qu'on évoque rarement.

Le churn ronge. Un abonnement à 29 €/mois génère une pression permanente : le client peut partir le mois prochain. Tu dois justifier ta valeur chaque mois, assurer le support, sortir des features, maintenir l'infrastructure. Le coût de rétention est réel, même si tu ne le comptabilises pas.

La trésorerie est décalée. Avec un abonnement, tu encaisses petit à petit. Avec un paiement unique bien pricé, tu encaisses tout de suite. Pour financer du développement ou traverser un creux, c'est un avantage concret.

La comparaison sur 3 ans change tout. Un outil à 299 € en paiement unique contre 19 €/mois en SaaS : au bout de 16 mois, l'acheteur du paiement unique est gagnant. Et toi, tu as encaissé 299 € dès le premier jour au lieu d'attendre 16 mois pour atteindre la même somme — en espérant que le client ne churne pas avant.

Le paiement unique n'est pas magique. Il déplace le problème : au lieu de gérer le churn, tu gères la distribution. Tu dois constamment trouver de nouveaux acheteurs parce que chaque client ne paie qu'une fois. C'est pour ça que la distribution est souvent supérieure au produit dans ce modèle — encore plus qu'en SaaS.

Ce que ça implique concrètement pour un solopreneur

Adopter le paiement unique, ce n'est pas juste changer la page de pricing. C'est repenser trois choses fondamentales.

Le support. En SaaS, le support est justifié par l'abonnement mensuel. En paiement unique, jusqu'où tu t'engages ? DHH a tranché pour Once : support inclus pendant un an, puis optionnel. C'est une règle simple, communicable, et qui protège ton temps. Si tu ne définis pas cette limite dès le départ, tu te retrouves à assurer du support gratuit à vie pour des clients qui ont payé une fois il y a trois ans.

Les mises à jour. Même logique. Deux approches coexistent dans l'écosystème indie : le modèle « version majeure payante » (tu achètes v1, la v2 est un nouvel achat à tarif réduit pour les anciens clients) ou le modèle « mises à jour incluses à vie ». Le premier est plus sain économiquement. Le second est plus simple à vendre mais crée une dette de maintenance invisible.

Le positionnement prix. C'est le point le plus critique, et on y revient en détail dans la section suivante. Mais l'erreur classique est de sous-pricer parce que « ça fait cher d'un coup ». Un outil à 49 € en paiement unique, c'est moins de deux mois d'un abonnement à 29 €. Tu viens de te condamner à trouver des clients en permanence pour un revenu dérisoire par transaction.

Si tu es en train de valider une idée avant de coder, le modèle de paiement unique peut d'ailleurs simplifier la validation : une liste d'attente avec un prix affiché dès le départ te donne un signal de demande beaucoup plus fort qu'un freemium.

Des makers qui ont adopté ce modèle — et ce qu'on peut en apprendre

⚠️ Règle anti-invention : on ne cite ici que des dynamiques observables et des plateformes documentées, sans inventer de chiffres de revenus ou de MRR.

Gumroad est la plateforme de référence pour les créateurs qui vendent des produits numériques en paiement unique — logiciels, templates, ebooks, plugins. Des centaines de makers y distribuent des outils à prix fixe. La plateforme publie des données publiques sur ses créateurs les plus actifs, et le modèle paiement unique y est dominant pour les outils techniques.

Lemon Squeezy (racheté depuis par Stripe) a été pendant longtemps le terrain de jeu des indie hackers qui voulaient vendre des licences logicielles à prix fixe avec gestion de la TVA intégrée. Beaucoup de makers y ont testé le « lifetime deal » — une version du paiement unique avec accès à vie et support inclus.

Le mouvement des « lifetime deals » sur des plateformes comme AppSumo a montré une chose importante : les acheteurs de paiement unique existent, ils sont nombreux, et ils sont prêts à payer un prix significatif si la valeur perçue est claire. Mais AppSumo impose des remises agressives qui cassent le pricing sur le long terme — ce n'est pas le modèle Once, c'est l'inverse.

Ce que DHH fait avec Once, c'est différent : prix plein, pas de remise de lancement, positionnement premium. C'est le modèle que les makers bootstrappés devraient étudier, pas le lifetime deal bradé.

Pour distribuer ce type de produit sans budget pub, les canaux organiques restent les plus efficaces : build-in-public sur X, Reddit, Product Hunt, SEO. Si tu veux structurer ta présence sur ces canaux, des outils comme PurrPlan ou son concurrent Buffer peuvent t'aider à planifier et maintenir une cadence de publication — la régularité étant le vrai levier de visibilité organique.

Comment fixer le bon prix unique sans se tirer une balle dans le pied

C'est la question qui tue. Et la réponse commence par une comparaison honnête avec l'équivalent SaaS.

Étape 1 : calcule le coût total de possession SaaS sur 3 ans. Ton outil résout un problème que des SaaS facturent combien par mois ? Multiplie par 36. C'est le plafond théorique de ce qu'un acheteur rationnel accepterait de payer en paiement unique.

Étape 2 : positionne-toi entre 50 % et 80 % de ce plafond. C'est la zone où l'acheteur perçoit une vraie économie sans que tu te brades. Un SaaS concurrent à 49 €/mois représente 1 764 € sur 3 ans. Ton paiement unique peut se positionner entre 880 € et 1 400 € sans que ce soit irrationnel pour l'acheteur.

Étape 3 : crée deux niveaux. Un prix d'entrée (code source, installation autonome, support 12 mois) et un prix « managed » ou « extended support » pour ceux qui veulent plus d'accompagnement. C'est exactement ce que fait Once avec ses différentes offres.

Étape 4 : valide avant de lancer. Une liste d'attente avec le prix affiché, c'est le test le plus honnête. Si les gens s'inscrivent en voyant le prix, le modèle tient. Si tu caches le prix jusqu'au lancement, tu te prépares une mauvaise surprise. Des outils comme GoNoGo permettent de structurer cette validation avant d'écrire une ligne de code.

L'erreur à éviter absolument : pricer en fonction de ce que tu as mis comme temps de développement. Ton client s'en fiche. Il paie pour la valeur que ça lui crée, pas pour tes heures. Un outil qui lui fait gagner 5 heures par semaine vaut beaucoup plus que 49 €, même si tu l'as codé en un week-end.

Verdict : modèle d'avenir ou niche pour une certaine clientèle ?

Le paiement unique n'est pas l'avenir universel du SaaS. C'est une option sérieuse pour une certaine catégorie de produits et de makers.

Ça marche bien quand :

  • Le problème résolu est stable dans le temps (pas de besoin de synchronisation en temps réel, pas de données centralisées indispensables)
  • La cible est technique ou autonome (capable d'héberger, de maintenir)
  • Le marché est allergique aux abonnements — PME, indépendants, équipes qui ont déjà trop de lignes sur leur carte de crédit
  • Tu as une audience ou un canal de distribution qui peut générer des vagues de ventes ponctuelles

Ça marche moins bien quand :

  • Ton produit dépend d'une infrastructure que tu dois maintenir (API tierces, synchronisation de données, IA à la demande)
  • Ta cible est grand compte — les grandes structures préfèrent souvent l'abonnement pour des raisons comptables
  • Tu n'as pas encore de distribution établie et tu comptes sur la récurrence pour lisser ta trésorerie le temps de construire ton audience

Ce que DHH prouve avec Once, c'est surtout que le modèle est défendable à grande échelle quand le positionnement est assumé jusqu'au bout. Pas de remise, pas de freemium, pas d'excuse. Le produit vaut ce prix, point.

Pour un maker bootstrappé qui démarre, la leçon n'est pas forcément « abandonne le SaaS ». C'est plutôt : arrête de choisir le modèle abonnement par défaut parce que tout le monde le fait. Interroge-toi sur ce que ton client préfère vraiment payer, sur ce que tu es capable de maintenir, et sur le canal qui te permettra de générer des ventes régulières sans MRR comme filet de sécurité.

Le mouvement indie hacking a toujours valorisé l'indépendance. Le paiement unique, c'est de l'indépendance appliquée au modèle économique — pour toi comme pour ton client. C'est une graine qui mérite d'être plantée, même si elle ne pousse pas dans tous les terreaux.

À retenir

  • Once by Basecamp remet le paiement unique à l'agenda : acheter le code, l'héberger soi-même, zéro abonnement.
  • Le MRR a un coût caché : churn, support permanent, trésorerie décalée. Le paiement unique déplace le problème vers la distribution, pas vers la rétention.
  • Le pricing est le point critique : calcule l'équivalent SaaS sur 3 ans, positionne-toi entre 50 % et 80 % de ce montant, crée deux niveaux.
  • Valide le prix avant de coder : une liste d'attente avec prix affiché est le test le plus honnête du marché.
  • Le support et les mises à jour doivent être définis contractuellement dès le départ — sinon tu crées une dette invisible.
  • Ce modèle convient aux produits stables, aux cibles techniques, aux marchés saturés d'abonnements.
  • Ce modèle est risqué sans canal de distribution établi ou pour des produits qui dépendent d'infrastructure centralisée.
  • La vraie leçon de DHH : ne choisis pas le modèle abonnement par défaut. Choisis-le parce que c'est le meilleur choix pour ton produit et ta clientèle.

Graine de startup est édité par Sébastien Debollivier, maker bootstrappé qui pilote une constellation de produits auto-financés — zéro VC, zéro levée, 100 % ship.