- Retour d’expérience concret d’un développeur solo ayant développé et maintenu seul l’ensemble du service avec Rails tout en atteignant 1 million d’euros d’ARR (revenu annuel récurrent)
- Au départ, le projet a commencé avec un MVP basique, puis a évolué vers une structure maintenable grâce à une réécriture complète et une amélioration de l’architecture
- Le point clé réside dans la philosophie cohérente de Rails, ses composants, et sa capacité à répondre aux besoins mobiles via Turbo Native
- Une architecture efficace qui a permis d’absorber l’ensemble du trafic et de l’usage tout en fonctionnant avec moins de 1 500 euros de coûts serveurs par mois
- Au final, le fondateur a cédé une partie du capital à un investisseur orienté long terme et a recruté un deuxième développeur après 14 ans, ouvrant une nouvelle phase
Mise en pratique de The One-Person Framework
1 million d’euros d’ARR avec Rails seul
- Début 2022, PlanGo a franchi le cap de 1 million d’euros d’ARR, un accomplissement presque irréel pour un service reposant sur une seule codebase Rails et un seul développeur
- Tous les domaines hors technique — définition de la vision, acquisition client, stratégie de croissance — étaient pris en charge par le cofondateur et l’équipe support, mais de la conception de l’architecture au déploiement, à l’exploitation, ainsi qu’au développement front-end et back-end, tout était géré seul
- Le concept défendu par DHH de « One Person Framework », c’est-à-dire une structure permettant à un seul développeur de gérer l’application entière, a été prouvé dans la réalité, et pas seulement en théorie
- La philosophie structurelle de Rails — de la conception de la base de données à la logique métier, jusqu’à l’UI front-end dans un ensemble d’outils cohérent — est particulièrement avantageuse pour les petites structures ou les fondateurs solo
- Cet article s’adresse notamment aux profils suivants :
- Développeurs Rails : ceux qui se demandent s’il est encore possible de construire un gros produit seul aujourd’hui
- Fondateurs techniques : ceux qui cumulent plusieurs rôles et ressentent une surcharge
- Personnes attachées à l’artisanat logiciel et aux choix technologiques
Situation au départ
- L’auteur a découvert Rails en 2011, à 21 ans, alors qu’il travaillait jusque-là sur des projets en PHP (CodeIgniter)
- Il n’y avait pas de grande stratégie derrière ce choix : il s’agissait simplement de tester Rails par envie de suivre la tendance
- Sur une idée marketing du cofondateur, l’équipe a lancé une offre : un an gratuit pour les inscrits de la semaine de lancement
- Ils s’attendaient à quelques dizaines d’inscriptions, mais ont en réalité obtenu plus de 500 inscrits dès la première semaine
- Comme le produit n’en était encore qu’au niveau MVP, des centaines de demandes de fonctionnalités, de questions et de requêtes de support ont afflué immédiatement
- Les serveurs tenaient le coup, mais la demande client a explosé alors que le produit n’était pas encore abouti
- Les deux cofondateurs ayant déjà une activité principale, il leur était impossible de répondre à temps plein
- Résultat : ils n’ont pas pu éviter de décevoir nombre de premiers utilisateurs
- Cette expérience leur a fait comprendre que développer un logiciel et faire tourner une entreprise logicielle sont deux problèmes totalement différents
- Ils en ont retenu qu’implémenter des fonctionnalités ne suffit pas : il faut aussi une gestion client durable, une bonne gestion des attentes et un cadre opérationnel solide
Apprendre en construisant
- Le développement a commencé avec l’aide de tutoriels Rails et de Stack Overflow, mais construire une application qui porte réellement le business de vrais clients en production relève d’un tout autre niveau
- Le code Rails des débuts comportait plusieurs erreurs classiques de débutant :
- des méthodes de contrôleur de plus de 200 lignes
- d’énormes modèles aux responsabilités mélangées
- des requêtes SQL inefficaces
- aucune suite de tests
- des valeurs de configuration et des clés secrètes commités dans Git
- Il était possible d’ajouter des fonctionnalités, mais l’application dans son ensemble reposait sur du code de fortune et une structure instable
- L’authentification, l’upload de fichiers, la génération de PDF, l’UI d’administration, le traitement des emails et bien d’autres fonctions ont été implémentés rapidement grâce à des gems, mais avec le temps chaque gem a introduit de nouveaux problèmes et de la complexité supplémentaire
- L’utilisation de
.round(2) a provoqué des erreurs de calcul de montants à cause de l’application inattendue du « banker's rounding »
- En confiant même les calculs simples à une gem externe, le manque de compréhension fondamentale du traitement numérique a fini par poser problème
- Vers 2013, à mesure que l’expérience d’exploitation du produit augmentait, la dette technique a elle aussi progressé rapidement, rendant le développement de nouvelles fonctionnalités de plus en plus difficile
Réécriture complète
- Une réécriture complète est généralement considérée comme un choix risqué et inefficace, mais en 2014 la décision a été prise de repartir entièrement de zéro sur Rails 4
- Pendant plusieurs mois, l’équipe a mené de front la maintenance de l’application existante et le développement de la nouvelle codebase
- L’architecture a été simplifiée, les dépendances en gems réduites de plus de moitié, et des tests ajoutés sur les fonctionnalités clés
- La nouvelle structure était plus simple, plus rapide, et surtout pensée pour être maintenable par un développeur solo à temps partiel
- Cette réécriture a ensuite servi de fondation technique exploitable pendant plus de dix ans par un développeur seul
Rails est un superpouvoir
- Jusqu’en 2025, PlanGo a été exploité par un seul développeur, et la raison principale qui a rendu cela possible, c’était Rails
- Grâce aux caractéristiques structurelles de Rails — Convention over Configuration, tests d’intégration, ActiveRecord, ActiveStorage, ActiveJob, etc. — il a été possible de réduire au minimum les décisions non essentielles et de se concentrer sur la création de valeur
- Après l’adoption de Turbolinks puis de Hotwire, il est devenu possible de créer une UI moderne sans framework JS complexe
- En 2011, au début du développement, la demande pour des applications mobiles était presque inexistante, mais par la suite les apps iOS/Android sont devenues l’interface principale de PlanGo
- Des frameworks comme Titanium, RubyMotion et Objective-C ont été testés, avec à chaque fois le problème du compromis entre qualité et vitesse
- Après l’adoption de Turbo Native, la productivité a fortement augmenté, et il est devenu possible de créer des applications de haute qualité en réutilisant la codebase Rails avec seulement des bases de développement natif
- Cette approche est particulièrement idéale pour les apps B2B ou SaaS, car elle permet d’obtenir des performances et une expérience natives avec un coût de développement réduit
- Résultat : plus de 100 000 téléchargements d’app par an, avec même un moment où l’application a dépassé Duolingo dans l’App Store néerlandais
- Toutes les apps ont été développées et maintenues par un seul développeur Rails
- Indicateurs principaux :
- Code Ruby : 36 170 lignes
- Code JavaScript : 13 495 lignes
- Couverture de tests : 40 %
- Utilisateurs actifs quotidiens : 6 332
- Requêtes par minute aux heures de pointe : 7 000
- Coût mensuel des serveurs : moins de 1 500 €
- Le maintien d’une architecture monolithique structurée a été l’un des meilleurs choix, avec des déploiements simples via Capistrano et un débogage facilité, sans la complexité des microservices
- Pour un fondateur technique, Rails n’est pas simplement un framework, mais un superpouvoir qui permet à une seule personne d’accomplir le travail d’une équipe entière
Au-delà du million d’euros
- Fin 2022, un tournant inattendu s’est présenté : un investisseur étranger a montré de l’intérêt pour PlanGo et a transmis une proposition d’acquisition
- À ce moment-là, PlanGo avait dépassé 1 M€ d’ARR en mode bootstrap et conservait une structure de revenus durable ainsi qu’une exploitation efficace sans financement externe
- Cette proposition a amené l’équipe à se poser la question : « Que voulons-nous pour la suite ? »
- Plusieurs options ont été envisagées : continuer comme avant, accélérer grâce à des capitaux externes, ou vendre complètement l’entreprise
- L’attachement au projet restait fort, mais il devenait clair qu’avec davantage de ressources et d’expertise, certaines opportunités pourraient être exécutées plus facilement
- Du point de vue de la réalisation de valeur aussi, récupérer une partie de la valeur construite pendant plus de dix ans tout en continuant à faire grandir l’entreprise apparaissait comme une option raisonnable
- Le choix final a été un partenariat avec un fonds evergreen néerlandais dont les valeurs et la vision long terme correspondaient bien
- Une partie du capital a été cédée, tout en conservant le contrôle et la majorité
- Cela a permis d’obtenir des ressources supplémentaires sans abîmer la structure ni la culture existantes
- Cette décision ne relevait ni d’un exit rapide ni d’une expansion agressive, mais d’une stratégie de croissance stable fondée sur un business durable et centré sur le client
- Par la suite, l’approche basée sur Rails a été maintenue telle quelle, tout en entrant dans une nouvelle phase où il devenait possible de poursuivre plus activement des opportunités auparavant difficiles à saisir
Ce qui a été appris
- Voici les principales leçons tirées de 14 années passées à opérer PlanGo en tant que fondateur technique solo
- Embrace Rails conventions
- Il est important de ne pas aller à l’encontre de la philosophie et des conventions de Rails
- La « Rails Way » est une manière de résoudre des problèmes déjà éprouvée, et plus on la suit, plus il devient possible de se concentrer sur la valeur propre du produit
- Less is more
- Les gems ou bibliothèques JS peuvent accélérer l’implémentation, mais augmentent aussi la complexité et les risques de casse
- Avant d’ajouter une nouvelle dépendance, il faut toujours se demander : « En ai-je vraiment besoin ? »
- Find a community
- Pour un développeur solo, le lien avec d’autres développeurs Rails est extrêmement important
- Par exemple, la communauté née autour de Spina CMS est devenue un point d’appui précieux pour partager des connaissances et recevoir du feedback, même sans collègues directs
- Technical debt isn't always bad
- Dans certains cas, un choix pragmatique pour arriver vite sur le marché vaut mieux que la perfection technique
- Avec la dette technique, l’essentiel est de savoir consciemment quand l’accepter et quand la rembourser
- You can go far alone
- Avec Rails, un seul développeur peut concevoir, faire évoluer et déployer un produit à l’échelle d’une équipe entière
- Il n’est pas nécessaire de se laisser enfermer par l’idée reçue selon laquelle il faut absolument une équipe
La suite
- Le nouveau partenaire investisseur partageait la vision d’une exploitation légère de PlanGo, mais a posé une seule condition : ajouter un développeur Rails
- Le problème n’était pas un attachement idéologique au développement solo, mais la difficulté même d’onboarder un nouveau développeur sur une codebase ayant évolué pendant 14 ans
- Cette codebase n’était pas seulement l’évolution de PlanGo : elle contenait aussi toute l’histoire de progression personnelle du développeur, passé de débutant à expérimenté, avec
des décisions et des styles de code issus de différentes périodes de sa propre carrière
- Le recrutement d’un deuxième développeur Rails, rencontré à Rails World (Canada), a apporté des changements structurels et des effets positifs
- Réduction du risque technique lié au point de défaillance unique
- Apport de nouvelles perspectives et idées
- Amélioration de la qualité du code grâce au pair programming
- Stimulation intellectuelle liée à la collaboration avec un collègue parlant le même langage technique
- Il n’est toujours pas prévu de constituer une grande équipe de développement
- Comme cela a déjà été démontré, une approche basée sur Rails suffit pour qu’une petite équipe mais puissante construise un logiciel significatif
- Cela dit, même le développeur solo le plus efficace peut encore progresser grâce à de bons coéquipiers
- Le parcours de PlanGo montre que le One-Person Framework de Rails fonctionne réellement, et constitue
une preuve qu’une petite équipe dotée des bons outils peut bâtir un vrai business selon ses propres standards
- Que l’on soit un développeur solo en train de créer son premier produit ou une petite équipe en réflexion sur sa stack technique, cette histoire montre ce qu’il devient possible d’accomplir en tirant pleinement parti de Rails
4 commentaires
J’ai transformé ce contenu en podcast avec l’aperçu audio de NotebookLM.
https://notebooklm.google.com/notebook/…
À ce niveau, c’est déjà excellent. Je vais encore peaufiner ça.
Waouh... c’est impressionnant... vraiment. Que ce soit à ce point naturel...
Et les informations sont vraiment très claires et faciles à assimiler...
Avis Hacker News
Un utilisateur ayant une expérience similaire à Django exploite sa propre application
Un utilisateur affirme que les personnes comptent davantage que les frameworks
Un utilisateur partage son expérience avec Rails et Phoenix
Un utilisateur indique avoir donné une présentation sur le fait que Rails 7+ aide aussi les développeurs solo à construire des applications ambitieuses
Un utilisateur partage une expérience où un nouveau partenaire voulait ajouter des développeurs Rails
Un utilisateur construit une application avec AdonisJS
Un utilisateur pense que Rails est supérieur à Django sur de nombreux points
Un développeur solo construit une application avec Rails
Un utilisateur affirme qu’il faut éviter les réécritures complètes
Un utilisateur pense que le framework n’est pas si important