1 points par GN⁺ 2024-07-05 | 1 commentaires | Partager sur WhatsApp
  • Ce side project lancé en 2018 avait un MVP prêt en quelques jours, mais à force de repousser sans cesse la mise en ligne, il est devenu un projet jamais sorti pendant 2 ans
  • Au cœur du retard, il y avait cette décision répétée de « juste une chose de plus », et l’apprentissage de React Native puis d’Expo a encore élargi le périmètre du produit
  • Une app concurrente qui résolvait le même problème était lente et buguée, mais elle était déjà lancée, avait des utilisateurs et une communauté, et s’améliorait chaque semaine
  • Après les 30 jours d’essai, en payant pour l’app concurrente, son propre produit, resté uniquement sur son disque dur, est devenu un produit de fait mort
  • Dans une mise à jour de 2024, il explique avoir finalement lancé l’app de productivité Benji en 2022, et que sa conclusion, même si elle sonne banale, penche quand même du côté de sortir son produit d’abord

Pourquoi je n’ai pas réussi à sortir en 2 ans un MVP construit en quelques jours

  • Le développement de l’app a commencé le 1er janvier 2018, et le MVP était prêt en quelques jours
  • Même la version alpha 0.0.1 était dans un état publiable, mais à chaque fois, la sortie était repoussée pour « juste une fonctionnalité de plus » ou « juste un écran de plus »
  • En se disant que « sans vraie app mobile native, les gens ne l’utiliseront pas », il a appris React Native et décidé d’y consacrer encore quelques mois
  • Pendant les 2 années qui ont suivi, il a enchaîné plateforme web, React Native, Expo, GraphQL, hésitations sur la stack technique, bascule vers d’autres projets, sortie d’autres apps comme Sizzy, perte puis retour de motivation
  • Il a fini par arrêter le développement et par renoncer à l’idée même de lancer cette app

Le moment où il a découvert une app qui résolvait le même problème

  • Avec le temps, en continuant à utiliser lui-même cette app, il a réalisé qu’il lui fallait beaucoup de fonctionnalités, et s’est retrouvé face au choix de reprendre le développement ou de chercher une alternative
  • En voyant la landing page d’une app alternative, il a été submergé par la sensation que quelqu’un avait déjà résolu le problème qu’il voulait résoudre
  • Il avait déjà envoyé auparavant une vidéo de sa propre app à quelques personnes, au point de se demander si cette vidéo n’avait pas circulé tant les fonctionnalités et la vision du problème semblaient proches
  • Mais il a fini par accepter que l’existence de cette app concurrente n’était pas leur faute, et que c’était surtout parce qu’il avait été trop lent et n’avait pas lancé à temps

Une app concurrente où la sortie passait avant la finition

  • En créant un compte et en regardant les vidéos du centre d’aide, à chaque fois qu’il trouvait une implémentation ingénieuse, il se rappelait qu’il s’agissait de son concurrent
  • Pendant 2 ans, il avait pensé que sa propre app était maladroite, buguée et trop incomplète pour que quiconque l’utilise, mais en essayant l’app concurrente, il a compris que ce jugement était faux
  • L’app concurrente aussi avait été développée pendant plusieurs années, mais elle restait lente, buguée et encore peu polie
  • L’app mobile n’était pas bonne au point que la synchronisation prenait 10 secondes, mais c’était déjà un produit lancé, et les utilisateurs pouvaient attendre la prochaine mise à jour
  • Même avec une longue liste de tâches à faire, les sorties continuaient chaque semaine, et l’app ainsi que la communauté grandissaient ensemble

La leçon retenue après le paiement

  • Après la fin des 30 jours d’essai, il a saisi ses informations de carte bancaire et est devenu non pas un simple abonné, mais un fan
  • La notification de paiement est restée pour lui comme une expérience qui lui rappelait sans cesse qu’il n’avait pas réussi à lancer son propre produit
  • À ce moment-là, il a accepté que son app était officiellement morte
  • La plupart des gens dans la même situation n’ont peut-être commencé leur projet que depuis quelques semaines, donc il faut éviter de refaire la même erreur
  • Si le « juste une chose de plus » consiste à recréer l’authentification, le paiement ou du boilerplate, alors c’est un piège ; et c’est pour réduire ce piège qu’il a ensuite créé Zero To Shipped

Mise à jour 2024 : Benji est finalement sorti

  • D’après la mise à jour de 2024, il a finalement lancé Benji en 2022
  • La raison de cette sortie est qu’aucune app concurrente ne se rapprochait suffisamment de sa vision
  • L’app qu’il voulait combinait Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing, Trips, etc.
  • Benji inclut aussi une timeline publique où les gens peuvent améliorer leur vie et partager leur réussite et leurs accomplissements
  • Même si cela sonne cliché, il faut reprendre son souffle et quand même Just Ship It

1 commentaires

 
GN⁺ 2024-07-05
Avis de Hacker News
  • Dans ce genre d’histoires où « tout s’est terminé parce qu’on n’a pas simplement lancé à ce moment-là », il y a un gros indice : la valeur de l’app en cours de création peut parfois résider dans des détails techniques qu’on ne peut pas bâcler, et dans ces cas-là, « juste lancer » n’est pas la bonne réponse.
    Le travail d’un ingénieur logiciel/architecte consiste aussi à résister autant que possible à la pression du management qui dit « mettez-le juste dehors ». Si c’est un produit que vous possédez directement et que le lancement vous profite, c’est une chose ; sinon, si prendre plus de temps permet d’obtenir un résultat plus professionnel, il faut prendre ce temps. Vous n’êtes pas un automate qui reçoit des tickets JIRA et recrache du code bancal le plus vite possible ; travailler comme ça en continu vous vide mentalement et finit par mener au burnout.
    Si vous n’avez pas de parts dans l’entreprise, votre travail n’est pas de maximiser ses profits, mais de créer du bon logiciel que vous n’aurez pas honte d’inscrire sur votre CV. Le soulagement d’avoir respecté encore une échéance arbitraire n’est qu’une motivation négative de court terme, qui ne dure pas ; il faut donc résister à la pression venue d’en haut et construire les choses correctement. Même si vous êtes licencié, de toute façon, aujourd’hui, changer de poste est souvent la voie pour progresser.

    • Dire que « si vous n’avez pas de parts dans l’entreprise, vous n’avez pas à vous soucier de la rentabilité » me paraît être une mauvaise attitude, qui révèle un manque de séniorité chez un développeur logiciel. Sauf dans une association à but non lucratif, tous les membres d’une entreprise doivent contribuer à sa rentabilité.
      Cela dit, rentabilité ne veut pas dire « juste lancer ». Si une entreprise confond souvent les deux, c’est plutôt le signe d’un manque de séniorité côté direction.
      Le travail d’un développeur consiste moins à faire du « bon logiciel » qu’à fabriquer un bon produit. Un bon produit exige généralement du bon logiciel, mais pas toujours, et il y a beaucoup d’excellents produits derrière lesquels se cache un logiciel médiocre. Les tensions entre produit, ventes et développement devraient mener à des compromis qui maximisent la valeur à court, moyen et long terme ; les développeurs doivent comprendre ce qu’on peut traiter approximativement, quelles sont les priorités de l’entreprise, et quand il ne faut pas transiger et qu’il faut produire du bon logiciel.
      Un développeur qui refuse tout compromis sur la qualité logicielle perd en fait de son influence dans les moments où il ne faudrait vraiment pas transiger.
    • Il faut commencer par regarder pourquoi on développe. Cela peut être par hobby, par plaisir, pour la beauté du code, mais le plus souvent, c’est pour faire accomplir par un logiciel une tâche dont quelqu’un a besoin.
      La priorité numéro 1 est donc de créer de la valeur pour les utilisateurs, et de développer aussi efficacement que possible. Quel intérêt a un logiciel que personne n’utilise ?
      Le travail d’un développeur n’est pas de faire du bon logiciel, mais de livrer de la valeur aux utilisateurs. Dans ma carrière, j’ai plutôt vu des développeurs se griser de surconception, gonfler le code avec des fonctionnalités dont personne n’avait besoin, et l’étendre en prévision de développements futurs qui n’arrivaient jamais. La vraie difficulté est donc de rester minimaliste, et il me semble que c’est aussi ce que dit le texte d’origine.
    • Tout ce commentaire se lit comme venant de quelqu’un qui voit ses relations avec ses collègues de manière purement antagoniste, avec très peu de confiance. Ça doit être assez épuisant.
    • J’ai été l’un des premiers employés d’une startup, et si nous n’avions pas fait de compromis, il est très probable que l’entreprise n’existerait plus aujourd’hui. Cette approche ne fonctionne que dans de grandes entreprises établies où l’influence d’une équipe sur les résultats est limitée.
      Dans les petites et moyennes entreprises, les compromis sont clairement nécessaires, et choisir ce qui mène au meilleur résultat business fait aussi partie du travail d’un professionnel.
      Beaucoup de développeurs sont « protégés » par plusieurs couches de managers, PM et designers, si bien que leur lien avec le côté business est faible. Sortir un produit rapidement permet aussi d’obtenir rapidement du feedback et de voir si l’implémentation correspond aux hypothèses. J’ai trouvé cela moins stressant que de déployer sous pression une solution « parfaite » pour devoir ensuite la réécrire.
      Dans mon poste actuel, mon travail de développeur consiste à réduire la complexité et à pousser les PM et designers à tailler au minimum les plans initiaux. Ainsi, les échéances arbitraires deviennent moins stressantes et l’impact des retards diminue.
    • On dirait une satire. On y trouve une série de phrases frappantes du genre « si ce n’est pas votre affaire, faites ce qu’il ne faut pas ; si c’est la vôtre, lancez vite », ou « votre travail consiste à mettre quelque chose sur votre CV et à vous sentir bien ».
      La seule partie qui ait de la valeur, c’est à peu près l’idée de ne pas trop s’attacher à un emploi particulier et de ne pas s’inquiéter excessivement d’un licenciement, mais je pense même que l’explication donnée est erronée. C’est étonnant de se dire qu’on peut réellement travailler avec des gens ayant une attitude aussi antagoniste.
      Certaines personnes semblent aimer passer leur vie dans le mauvais quadrant de la théorie des jeux.
  • Le passage « je me suis demandé qui avait partagé la vidéo de mon app avec ces gens ; ils résolvaient littéralement le même problème » m’a rappelé une fois où j’ai rencontré quelqu’un qui avait une idée d’app correcte.
    Il m’a demandé de coder l’app gratuitement et de partager les revenus. Quand je lui ai demandé ce qu’il apporterait, il a répondu qu’il « gérerait » l’entreprise, et que ses 50 % revenaient au fait qu’il avait « eu l’idée ». Je lui ai donc dit que je lui laissais six mois d’avance, et que s’il ne l’avait pas mise sur le marché d’ici là, je la développerais moi-même.

    • J’ai participé un temps à un projet de jeu indé. C’était une idée assez ordinaire, presque un mauvais jeu, mais nous étions trois à vouloir acquérir de l’expérience en développement logiciel dans ce domaine.
      Deux d’entre nous se sont simplement assis et ont commencé à donner forme au projet, mais le troisième a poussé du code cassé dans SVN, rédigé un document de conception s’attribuant toute l’idée, puis convoqué une réunion pour dire qu’il était le game designer et qu’il nous poursuivrait si nous faisions un jeu ailleurs. Les deux qui contribuaient réellement se sont regardés et ont abandonné le projet. Il avait abattu toutes ses cartes, et nous avons compris qu’il ne valait pas grand-chose.
      Plus tard, j’ai vu sur Steam un jeu fondé sur une idée similaire. Tant mieux s’ils y ont pensé indépendamment ; tant mieux s’ils l’ont volée à ce loser ; et s’ils ont tenu jusqu’au bout sous ses ordres, ils méritent leur argent.
    • En tant que personne extrêmement orientée logique et programmation, j’aimerais presque rencontrer ce genre de personne. Je ne crois pas être moi-même un « profil idées ».
      Si l’idée était vraiment bonne et crédible, honnêtement, cela aurait pu être une proposition assez correcte.
    • S’occuper des ventes, du marketing, de la comptabilité et de tout le reste nécessaire pour faire tourner une entreprise vaut 50 %, peut-être même plus. Cela dit, il y a de fortes chances que la personne chargée de coder ait été suffisamment compétente, alors que la probabilité qu’il ait été assez compétent pour « gérer » l’entreprise semble faible.
    • Si vous ignorez totalement l’état mental de l’autre personne, je ne suis pas sûr que ce soit très prudent de dire ça.
      Si vous pensez pouvoir dire à quelqu’un « dans six mois, je volerai ta super idée », il faut espérer que cette personne ne soit pas du genre à causer des problèmes, voire, dans le pire des cas, à faire du mal.
  • J’aimerais que quelqu’un résolve mon problème à ma place. Si je m’y accroche aujourd’hui, c’est simplement parce qu’il n’existe pas de solution que je puisse acheter et utiliser telle quelle
    Si quelqu’un se saigne aux quatre veines pour résoudre mon problème, et prend aussi en charge l’astreinte et la maintenance, ce serait une bonne nouvelle
    Pourquoi faut-il absolument résoudre soi-même ce problème ? Pourquoi faut-il absolument que sa propre solution devienne une entreprise ? Une entreprise consiste à créer de la valeur pour soi et pour ses clients. Si l’on est obsédé par le problème lui-même, on peut être reconnaissant que quelqu’un d’autre consacre beaucoup d’efforts à le résoudre ; si l’on était obsédé par les clients, on aurait dû leur mettre quelque chose entre les mains depuis longtemps pour obtenir du feedback

    • Certains développeurs solo semblent vouloir implémenter une nouvelle idée, la transformer en activité ayant un certain succès, verrouiller le marché, puis la vendre à une plus grande entreprise pour gagner beaucoup d’argent
      Peu de gens ont sans doute envie de gérer une entreprise sur le long terme, mais la plupart ne refuseraient probablement pas de recevoir soudainement une grosse somme d’argent parce qu’ils ont résolu ou traité un problème intéressant
    • Je suis l’auteur de l’article original : si c’était important pour moi, c’est parce qu’une app que j’utilisais depuis un moment stagnait et ne recevait plus de mises à jour. En apprenant davantage sur la productivité, j’ai atteint les limites de cette app et j’ai voulu plus de fonctionnalités
      Des idées pour mon app me venaient sans cesse, mais les autres développeurs n’auraient sans doute pas été intéressés par leur implémentation. Je voulais avoir le contrôle, et c’est ainsi que j’ai fini par lancer Benji : https://benji.so
  • Je suis l’auteur de l’article original. Il faudrait que je mette ce billet à jour. Des années plus tard, les commentaires HN publiés à chaque fois que ce texte ressort m’ont réellement motivé
    Les gens demandaient toujours « pourquoi ne pas simplement lancer l’app ? », alors j’ai fini par le faire
    Je suis content d’être allé jusqu’au bout, et je pense qu’elle est bien meilleure que n’importe quel produit concurrent dans cette catégorie
    Vous pouvez la voir sur https://benji.so. La landing page est encore en cours de travail

    • La landing page fait ramer le navigateur. C’est un écran d’accueil avec quelques images, je ne comprends pas comment c’est possible. Que fait donc cette page ?
    • J’ai traversé un cycle de développement d’app similaire, sans parvenir à la lancer. J’ai commencé avec React, puis je suis passé à React Native et Flutter, et j’ai même fini par migrer de GraphQL vers SQLite
      Mon app avait un objectif similaire : relier la motivation liée aux habitudes, la mesure du respect des objectifs, ainsi que la planification et la replanification des tâches. J’y ai travaillé pendant des années, et l’idée d’en faire un jour une entreprise bootstrapée était fortement liée à mon identité
      La décision d’abandonner le projet est venue en plusieurs étapes, mais l’un des grands déclencheurs finaux a été de réaliser que je ne voulais pas vivre sur le long terme comme développeur d’apps. C’était difficile de lâcher prise, mais je suis satisfait de cette décision aujourd’hui. Comme dans l’article original, on pourrait dire que « rien ne disparaît complètement », puisqu’il pourrait peut-être ressusciter plus tard, mais je ne pense pas revenir à ce projet précis
      L’une des idées clés pour dépasser la « forte charge cognitive » de la plupart des apps de productivité était une marketplace de modules de vie. Par exemple, un influenceur fitness pourrait vendre un pack comprenant routines d’entraînement, régime alimentaire et modèles de journal, que l’utilisateur « installerait » ensuite dans sa propre vie
      Les grands modèles de langage rendront beaucoup plus faisables la détection du décrochage, l’estimation de ses causes, ou la réaction à des « actions non effectuées ». Je pense que c’est important pour les personnes qui n’ont pas une personnalité de type A et qui n’utilisent pas assidûment une app de productivité tous les jours
    • Je viens d’essayer, et le nom du fuseau horaire détecté s’affiche comme « Africa/Ceuta (Romance Standard Time) (UTC+01:00) Brussels, Copenhagen, Madrid, Paris »
      Le décalage avec GMT est correct, mais Brussels, Copenhagen, Madrid, Paris ne sont pas en Afrique, donc c’est très déroutant. Il vaudrait mieux vérifier les informations de fuseau horaire utilisées
      En voyant les commentaires ci-dessous, ce n’était finalement pas un problème
    • Les liens du menu en blanc sur fond blanc ne sont pas visibles. Je le signale au cas où : https://i.imgur.com/Yd1hniV.png
    • Ça a l’air bien. Je l’essaierai peut-être. Le nom vient-il de ce copain-ci https://en.wikipedia.org/wiki/Benji ? Je l’adorais quand j’avais environ 6 à 8 ans
      Et désolé d’avoir exprimé de la frustration et de la méfiance parce que vous ne donniez pas le nom du « concurrent ». Maintenant que vous avez lancé votre propre app, j’imagine qu’il est encore moins probable que vous mentionniez ce produit concurrent, même s’il existe encore
  • Devenir un véritable utilisateur de son propre système change complètement la perspective. Moi aussi, je construisais quelque chose pour moi-même, et je pensais que ce n’était pas prêt et absolument pas utilisable
    Après avoir abandonné le projet, j’ai décidé de l’utiliser comme un vrai utilisateur, et j’ai compris que les utilisateurs s’habituent à une multitude de petits problèmes et trouvent automatiquement des contournements. Quand on a créé quelque chose, on oublie souvent que beaucoup d’imperfections ne sont pas rédhibitoires, et que les utilisateurs évitent de nombreuses insuffisances sans grand effort. À ce stade, la quête de perfection ressemble plutôt à de l’ego
    Ignorer momentanément le fait qu’on en est le créateur, s’en servir réellement pendant un moment tout en s’interdisant de le modifier, peut tout changer

    • C’est pour cela que « lancer et itérer rapidement » est souvent la meilleure voie. N’importe quel projet logiciel peut contenir des bugs critiques. Si un logiciel de comptabilité ne fait pas correctement la comptabilité, il ne faut évidemment pas le lancer tel quel ; mais si un rapport s’affiche deux fois pour une raison quelconque, les utilisateurs peuvent le supporter jusqu’à l’itération suivante. À condition que cette itération suivante n’arrive pas dans plusieurs mois ou années
      En pratique, tant qu’on ne l’a pas mis entre les mains de vrais utilisateurs, on ne trouve pas la plupart des « bugs » auxquels ils seront confrontés. Si l’on ne lance pas, on n’a pas non plus l’occasion de corriger les bugs qui affectent réellement les utilisateurs
    • Une app que je viens d’utiliser avait un navigateur web iOS intégré qui ne fonctionnait pas correctement
      J’ai simplement ouvert directement la page web, et le nom d’utilisateur et le mot de passe étaient évidemment synchronisés via iCloud. Reprendre le parcours utilisateur dans Safari m’a pris 5 secondes, et le terminer seulement 30 secondes
  • Ce n’est pas le meilleur exemple de « sortez-le, c’est tout ». Les catégories comme les apps de productivité, les listes de tâches, le suivi d’habitudes, le suivi des dépenses, le journaling ou les programmes d’entraînement sont des idées auxquelles beaucoup de gens arrivent indépendamment
    Vous n’imaginez pas à quel point je me suis senti intelligent quand j’ai eu l’idée d’une app pour enregistrer ses dépenses. Puis j’ai regardé le Play Store. KRAZAM s’en moquait déjà il y a 5 ans dans sa vidéo « The Hustle »

    • C’est peut-être la catégorie la plus surfaite de toute l’histoire des catégories d’apps surproduites
      Ça ne veut pas dire qu’une nouvelle variante ne peut pas réussir. La plupart de celles qui ont réussi ne sont pas totalement originales. Simplement, si vous avez peur que quelqu’un sorte sa version avant vous et gagne, il suffit de regarder autour de vous
    • La partie « j’ai regardé le Play Store » semble passer à côté du cœur du texte. L’idée centrale, c’est de sortir quand même, même s’il y a des concurrents. Au contraire, les concurrents sont un bon signal de validation de l’idée, pas un mauvais signal
  • Personnellement, je ne supporte pas ce style d’écriture qui « essaie très fort d’être drôle »

    • D’accord. C’est assez fatigant à lire. Une ou deux piques bien placées, ça va, mais il ne faut pas en abuser
    • Vous n’êtes pas le seul, et c’est très bien que les goûts diffèrent d’une personne à l’autre
  • J’ai abandonné en cours de lecture. Trop puéril et trop gênant
    Au final, ils n’ont fait qu’une preuve de concept et s’en sont contentés. C’est dommage, mais c’est la vie. Ils ont fait le travail et ont été récompensés
    La leçon à en tirer, c’est que les idées ne se possèdent pas

  • Je suis totalement d’accord avec ça. Quand nous avons lancé Kviklet, nous étions trois, et l’un d’entre nous était bien plus perfectionniste que les deux autres. Franchement, il a déjà fallu beaucoup convaincre pour mettre en ligne la première version du site, qui était mauvaise, et rendre le dépôt public a été encore plus difficile
    Ce « cofondateur » est parti tôt, mais je suis vraiment content que nous ayons essayé de sortir le produit et de le vendre rapidement
    Ça n’a pas marché et nous n’avons pas trouvé d’acheteurs, mais imaginer que nous serions encore en train de construire le produit dans le noir, accrochés à l’espoir sans aucune idée de savoir si quelqu’un paierait, est terrifiant
    Aujourd’hui, nous l’avons passé en open source comme plan B, et nous avons quelques utilisateurs plutôt sympas. On pourrait même parler d’une petite communauté : https://github.com/kviklet/kviklet
    Ce n’est pas l’histoire de succès de startup que nous espérions il y a un an, mais c’est bien mieux que de rester encore dans l’attente, déconnectés de la réalité. Et ce n’est pas parce que c’est open source qu’on ne peut pas gagner un peu d’argent en vendant du support ou une version premium. Pour l’instant, c’est juste un side project amusant

    • La description « un flux de revue/approbation façon Pull Request pour les requêtes de base de données » n’est pas très bonne. Une requête ne devrait pas donner l’impression d’avoir besoin d’une approbation
      Il faudrait utiliser des mots comme mutation, edit, update ou modification. Même si query est techniquement correct, le terme sonne mal et prête à confusion
  • Si je construis quelque chose pour moi-même, je ne serais pas triste que quelqu’un l’ait fait avant. Ce serait seulement la preuve que l’idée était bonne
    Bien sûr, beaucoup de projets personnels que j’ai en tête ou sur papier, même ceux que j’ai réellement un peu commencés, ne sont pas destinés à être lancés comme produits à vendre. Ce sont des choses que je veux, ou que des amis, de la famille ou d’autres personnes pourraient trouver utiles
    S’il y avait ne serait-ce qu’une qualité alpha, je pourrais les publier en espérant que quelqu’un se dise : « l’idée est utile, mais l’implémentation est médiocre, je devrais faire mieux »

    • En réalité, dans presque toutes les situations, quelque chose vous a déjà devancé. Même quand vous automatisez quelque chose pour la première fois de l’histoire, la méthode manuelle existante est votre premier concurrent. L’app de l’article ne concurrence pas seulement d’autres apps, mais aussi toutes les combinaisons de solutions partielles que les clients visés utilisent déjà
      Et même si vous êtes le premier entrant, des concurrents apparaîtront bientôt et grignoteront votre avantage, ce qui vous obligera à continuer d’essayer de garder une longueur d’avance
      Donc, puisqu’il y a toujours déjà quelqu’un avant vous et que la concurrence est certaine, maintenant ou plus tard, mieux vaut ne pas s’inquiéter de se faire devancer et se concentrer sur son avantage concurrentiel. L’auteur original semble finalement être arrivé à cette prise de conscience, et je lui souhaite de réussir