Comment je gère 6 apps tout seul (spoiler : je les gère pas tout seul)

De 3 apps à 6 : le chaos dont personne ne te parle

Y a un moment dans la vie de chaque solo dev où tu regardes ton écran et tu penses : "Qu'est-ce que je fais là ?"

Pour moi, c'est arrivé en février 2026. Trois apps shippées. Trois nouvelles apps en développement. Une personne qui code. Pas d'équipe. Pas de backup. Juste moi et la possibilité infinie que tout casse.

CookBook AI c'était gérable. Je suis en cuisine, je pense aux recettes, l'app vit littéralement rent-free dans ma tête.

TipLog c'était fun. Résoudre le problème du pourboire c'était bon. L'app est assez simple pour que tu puisses vraiment la finir.

OmniDrop ça stretch les choses. Chiffrement, support desktop cross-platform, NFC sur mobile — tout d'un coup je deal avec de la complexité que j'avais pas prévue. Mais ça valait le coup.

Ensuite j'ai dit "oui" à trois autres.

La panique a frappé vers 2h du matin.

Comment Claude est devenu mon pair programming partner

Voilà la vraie discussion : je code pas toutes les six apps tout seul. J'écris l'architecture, la logique de base, les décisions dures. Claude écrit l'échafaudage, trouve les bugs, et demande "et si on faisait comme ça ?" toutes les cinq minutes.

Voilà comment ça marche vraiment :

Je décris le problème. "J'ai besoin d'une app Flutter où les utilisateurs peuvent uploader des fichiers et les transférer P2P, chiffrés, sans serveur."

Claude la code. Pas du code parfait — j'm'attends pas à ça. Mais du code fonctionnel. De l'armature. De la gestion d'état. La forme du truc.

Je la teste. Généralement ça casse de trois façons que j'avais pas prévues.

Je dis à Claude ce qui a cassé.

Claude le fixe. Parfois avec des explications que j'vais utiliser dans les commentaires de l'app elle-même. Parfois avec des questions qui me font réaliser que j'ai mal designé un truc.

On itère. Répète jusqu'à ce que ça marche.

Ce processus c'est *rapide*. Pas "move fast and break things" rapide. "Move purposefully and break things strategically" rapide.

L'IA gère les trucs qui sont purement mécaniques : connecter les boutons aux fonctions, écrire des requêtes database, gérer les edge cases spécifiques à chaque plateforme. Moi je gère les trucs qui demandent du goût : ce bouton doit-il être bleu ou vert, ce flow est-il vraiment intuitif, ça ressemble-t-il à une app ByNeel ?

Sans Claude, je shipperais une app par an. Avec Claude, je ship deux par mois.

L'architecture c'est tout

La raison pour laquelle six apps c'est pas l'équivalent de quarante apps c'est parce qu'elles suivent toutes le même pattern architectural.

Offline-first. Ça seul m'épargne des cauchemars. J'ai pas de serveurs à gérer. J'ai pas de databases pour lesquelles je paie le scaling. J'ai pas de soucis de uptime. L'app fonctionne sur le device, sync quand elle veut, c'est tout.

Patterns de code partagés. Chaque app ByNeel utilise Riverpod (ou Provider pour les plus anciennes) pour la gestion d'état. Chaque app utilise le même pattern d'authentification — Firebase pour certaines, supabase pour une, local-only pour d'autres, mais toujours en suivant la même interface. Chaque app utilise Inter comme font. Chaque app a le même système de couleurs (une primaire, une accent, une danger).

Quand je change d'app, je context-switch pas vers des mondes complètement différents. Je change entre différentes implémentations du même design language.

Flutter partout. Même framework. Même langage. iOS, Android, macOS, Windows, Linux — je m'en fous. J'écris du Dart, et Flutter gère le reste. C'est un force multiplier pour les solo devs. Tu apprends pas mobile native, web, desktop — tu deviens juste très bon dans un truc.

Compare ça à un monde hypothétique où j'aurais build CookBook AI en Swift, TipLog en React Native, OmniDrop en Rust desktop, Ephemera en Flutter... Je serais mort à l'heure qu'il est. Probablement dans un endroit sympa où les gens portent des vestes confortables et font de longues promenades.

Le défi de la cohérence de marque

Voilà un problème dont personne parle : quand t'as une app, tes couleurs c'est ce que tu veux. Quand t'en as six, tu as besoin d'un système.

Chaque app ByNeel a sa propre palette de couleurs. CookBook AI c'est des jaunes et oranges chauds (bouffe, chaleur, énergie). TipLog c'est émeraude et teal (voyage, sophistication). OmniDrop c'est des bleus cool (vitesse, sécurité). Ephemera c'est ambre et indigo (temps, mystère). BridgeGen c'est corail et rose (humains, connexion). EarthPulse c'est cyan et lime (tech, nature).

Mais elles utilisent toutes Inter. Toutes. Inter c'est la voix ByNeel, typographiquement. Mêmes formes de boutons. Mêmes règles d'espacement. Même philosophie : simple, direct, pas de fioriture.

Un utilisateur qui a utilisé CookBook AI va immédiatement se sentir chez lui dans TipLog, même si les couleurs sont différentes, parce que la *grammaire* est la même. La façon dont les boutons fonctionnent. La façon dont la navigation coule. La façon dont l'information est présentée.

Cette cohérence c'est la seule chose qui fait que six apps ressemblent à une famille au lieu de six projets random.

Le système de planning qui fonctionne vraiment

J'utilise trois fichiers markdown :

CHECKLIST.md — pour chaque app, ce qui ship vs. ce qui est déféré. Drapeaux de production, métadonnées App Store, politiques de confidentialité. Des trucs chiants qu'il est facile d'oublier et qui sont dévastateurs quand tu les oublies.

PLAN.md — le trimestre qui vient. Ce qui ship quand. Quelles features sont "nice to have" vs. "core." Quelle est la plus petite version de cette app qui résout le problème.

MANAGEMENT.md — comment je travaille. Comment Claude et moi on interagit. Quelles décisions je prends seul vs. ce dont on débat. Patterns pour tester. Règles pour shipper.

Pas de Jira. Pas de Notion. Pas d'outil de gestion de projet fancy. Juste des fichiers markdown que je peux éditer dans n'importe quel text editor, commités dans git, toujours disponibles.

Pourquoi ? Parce que les outils c'est l'ennemi du shipping. Jira te fait sentir productif. T'écris des stories, tu moves des cards, tu updates des statuses. Mais est-ce que tu ship vraiment ? Notion c'est beau et complet, mais maintenant tu maintiens Notion au lieu de maintenir des apps.

Markdown + git c'est le système le plus simple qui pourrait marcher. Et ça marche.

Le secret : finir > perfectionner

C'est la part qui sépare les solo devs qui ship de ceux qui burnout.

T'as de l'énergie limitée. T'as du temps limité. Tu dois choisir : est-ce que tu perfectionnes l'app #3 ou tu ship les apps #4, #5, et #6 ?

La réponse c'est toujours : ship.

CookBook AI a quelques rough edges. L'import PDF pourrait être plus smart. Les suggestions IA pourraient être meilleures. Mais c'est dehors, en train d'améliorer la cuisine des gens, maintenant.

TipLog n'a pas toutes les devises du monde. Elle a les 51 les plus utilisées et elle ship avec ça.

OmniDrop n'a pas de feature de collaboration built-in (bien que Claude la suggère souvent). Elle se concentre sur ce qu'elle fait : les transferts chiffrés. Si je commençais à ajouter la collaboration, je buildais quelque chose qui rivalise avec Figma et c'est pas l'histoire.

Ephemera va ship avec la feature core — des capsules temporelles chiffrées verrouillées par GPS et date — et c'est tout. Pas de réseau social, pas d'app de messaging, pas rien d'autre. Juste ce un truc, bien fait.

Le perfectionniste en moi veut continuer à polir. Le réaliste en moi dit : ship le truc qui résout le problème, puis résous de nouveaux problèmes.

Pourquoi six c'est tenable

À une app : t'es un développeur.

À deux apps : t'es un petit studio.

À trois apps : tu commences à sentir le stretch.

À six apps : soit tu as une équipe, soit t'as complètement restructuré ta façon de travailler.

J'ai restructuré.

L'architecture offline-first gère le burden de l'infrastructure. Flutter gère le burden du cross-platform. Une planning claire gère le burden du chaos. Claude gère le burden du coding. Et moi je gère le burden de la décision — le truc que personne d'autre peut faire.

Six apps tout seul c'est pas possible si tu le fais comme avant. Mais si t'es prêt à penser différemment à l'architecture, aux outils et ce que "shippé" veut dire — si t'es prêt à avoir un pair programming IA et une philosophie claire sur ce que chaque app doit faire — ça devient pas juste possible mais tenable.

Est-ce que j'ajouterais une septième app cette année ? Probablement pas. Mais six ? Six c'est right. Six c'est le sweet spot où je ship des produits significatifs sans sacrifier la qualité qui fait que ByNeel c'est ByNeel.

Les apps ne sont pas parfaites. Mais elles sont réelles. Elles résolvent des problèmes. Elles sont finies.

Et c'est tout le point.