Il y a un an, j’ai décidé de me consacrer entièrement au développement d’apps en solo. Mon objectif n’était pas seulement d’écrire du code, mais de créer, publier et gérer de vrais produits de façon indépendante.
12 mois plus tard, j’ai créé et publié 5 apps différentes sur l’App Store et Google Play. En consultant l’historique des commits et les chiffres de téléchargement, un constat s’impose : développer le logiciel était la partie facile. Le marketing était le véritable défi.
Voici les principales leçons techniques et non techniques que j’ai tirées d’une année de développement en solo.
Partie 1 : Le développement (la zone de confort des développeurs)
Quand on est développeur, passer 10 heures dans VS Code à configurer la gestion d’état ou à résoudre des problèmes de compilation native semble productif. C’est notre zone de confort. Mais publier 5 apps multiplateformes en un an m’a obligé à repenser profondément ma façon de développer.
1. Constituer son propre arsenal d’infrastructure
Créer cinq apps à la suite m’a appris à ne jamais résoudre deux fois le même problème. Dès la troisième app, j’avais constitué mon propre socle de code réutilisable :
- Framework : React Native / Expo (avec des Config Plugins pour automatiser le code natif iOS/Android).
- Architecture : stockage local-first (AsyncStorage) pour éliminer la complexité du backend et les coûts d’infrastructure cloud.
- Intégrations : hooks préparés pour des intégrations natives comme Apple HealthKit, Google Health Connect et les widgets iOS.
En solo, la vitesse est votre seul levier. Une architecture réutilisable permet de consacrer 80 % de son temps à la valeur principale de l’app et seulement 20 % à sa mise en place.
2. Le local-first n’est pas qu’une technologie. C’est la liberté
Chaque ligne de code backend doit être maintenue, sécurisée et financée, même pendant votre sommeil. Adopter une architecture strictement local-first m’a évité les migrations de base de données et les inquiétudes liées à la disponibilité des serveurs, tout en offrant une app instantanée aux utilisateurs. Les personnes sensibles à la confidentialité apprécient aussi que leurs données ne quittent jamais leur appareil.
3. La perfection est l’ennemie de la mise en ligne
Au début, mon principal piège était de peaufiner les cas limites avant même de savoir si l’app intéressait quelqu’un. À partir de la quatrième app, j’ai adopté une règle stricte : publier d’abord le parcours principal. Les finitions viennent après les retours des vrais utilisateurs.
Partie 2 : Le marketing (le vrai défi)
En tant qu’ingénieurs, nous aimons croire à la méritocratie : « Si je crée un excellent produit, les utilisateurs viendront naturellement. »
Ce n’est pas le cas. L’App Store et Google Play sont des cimetières d’apps techniquement supérieures qui n’ont aucun téléchargement. Comprendre que le code ne représente que 20 % de la réussite en indie hacking a été ma leçon la plus difficile de l’année.
1. Miser sur la distribution organique (X et Reddit)
Sans gros budget publicitaire, je me suis concentré entièrement sur le marketing organique :
- X (Twitter) pour « build in public » : publier des extraits de code, des itérations d’interface, des captures d’étapes importantes et des difficultés techniques m’a permis d’attirer mes premiers utilisateurs et de rejoindre un formidable réseau de créateurs.
- Reddit pour des retours utiles : Reddit est d’une franchise brutale. Publier un simple lien vers son app puis disparaître, c’est s’exposer aux votes négatifs. En revanche, expliquer un problème technique complexe dans une publication utile permet d’obtenir des retours précieux et de trouver ses premiers utilisateurs.
2. Le « marketing caché » par la rédaction technique
L’une de mes plus grandes avancées marketing a été de rédiger des études de cas techniques sur les fonctionnalités de mes apps. Partager « Comment j’ai créé un hook unifié pour Apple HealthKit et Google Health Connect » sur des plateformes de développeurs avait un double effet : apporter une vraie valeur à la communauté et faire découvrir naturellement mon app aux personnes qui apprécient les logiciels bien conçus.
3. La règle du 50/50
Si je pouvais revenir au premier jour, j’appliquerais la règle du 50/50 : consacrer la moitié de mon temps à développer l’app, et l’autre moitié à en parler, à écrire à son sujet ou à améliorer sa fiche sur les stores. Une bonne app bien commercialisée l’emportera toujours sur une app exceptionnelle sans distribution.
En conclusion : changer d’état d’esprit
Passer d’ingénieur logiciel à créateur indépendant demande un changement complet de perspective. Il faut cesser de se voir uniquement comme un « codeur » et agir aussi comme chef de produit, spécialiste marketing, designer et responsable du support client.
Créer 5 apps en un an ne m’a pas seulement rendu meilleur développeur : cela a complètement changé ma façon de voir le logiciel.
À tous les développeurs solo qui travaillent encore dans le secret : ouvrez votre éditeur, supprimez les fonctionnalités superflues, publiez votre app et commencez à en parler dès aujourd’hui.