L’app que j’ai conçue et développée, mais jamais lancée : Stocketa

• Au début du confinement lié au Covid, en mars 2020, Stocketa a commencé comme un projet personnel pour apprendre Swift et SwiftUI ; il a été développé plus de deux ans à raison de 10 à 20 heures par semaine, mais n’est jamais sorti sur l’App Store
• L’objectif était un tracker de portefeuille pour investisseurs occasionnels, permettant de voir au même endroit des actifs dispersés entre plusieurs courtiers et services financiers, ainsi que les gains/pertes par transaction, réalisés et non réalisés
• L’app mettait l’accent sur des interactions conçues sur mesure plutôt que sur les composants iOS standards, avec notamment pull-to-search, cartes d’actions, sheets et menus personnalisés, swipe actions, widgets et import TSV
• La plus grande contrainte concrète qui a empêché le lancement était celle des API de données financières : problèmes de qualité et de couverture chez IEX, fiabilité douteuse d’un fournisseur à 100 $/mois, et tarifs de données commerciales à partir de 2 000 $/mois, inadaptés à une app indépendante
• Bien que le projet ait eu une LLC, un backend Node/Express, environ 1 000 testeurs sur TestFlight et plusieurs milliers de personnes en liste d’attente, il a été abandonné à cause du coût des données, de la charge de support client et du manque de temps ; l’apprentissage de SwiftUI a ensuite directement servi dans le travail sur Rewind AI

---

Le problème que Stocketa voulait résoudre

• Stocketa visait à être une application de suivi de portefeuille bien conçue permettant de voir, sur un seul écran, des actifs d’investissement dispersés entre plusieurs plateformes
  • Le projet est né d’une expérience personnelle : il était fastidieux de consulter des actifs répartis entre plusieurs courtiers et services financiers
  • L’idée n’était pas seulement de voir le prix, mais de suivre les gains et pertes réels par transaction, en tenant compte de son propre prix de revient
• Les options disponibles à l’époque ne répondaient pas au besoin
  • Des apps boursières simples comme Apple Stocks fournissaient des graphiques et des actualités, mais pas de suivi des quantités détenues ni des gains/pertes
  • Des apps de courtage comme Robinhood n’affichaient que les positions détenues chez ce courtier
  • Des services avancés comme TradingView n’étaient pas centrés sur le mobile ou n’offraient pas une expérience aussi élégante que souhaité
  • Des services de conseil en investissement comme Personal Capital permettaient la connexion aux comptes, mais rendaient difficile l’analyse détaillée des actifs individuels et mettaient surtout en avant leur propre offre de conseil
  • Les petites apps de suivi de positions disponibles sur l’App Store n’étaient pas satisfaisantes en matière de design et d’UX
• Les apps financières existantes privilégiaient généralement la densité d’information, obligeant à passer sans cesse d’une liste à un écran de détail ; Stocketa voulait afficher davantage d’informations directement dans les cartes de l’écran principal

Une architecture d’app construite avec une UI sur mesure

• Stocketa a été conçu autour d’un feed unique et de cartes d’actions, avec un minimum d’éléments d’interface périphériques
  • L’objectif était d’éviter la tab bar standard et les en-têtes de navigation classiques
  • La plupart des fonctionnalités étaient intégrées directement dans les cartes d’actions de la timeline d’accueil
• Presque toute l’interface a été créée à partir de composants personnalisés basés sur SwiftUI
  • À la place du pull-to-refresh, l’app utilisait un pull-to-search pour rechercher et ajouter de nouvelles valeurs
  • Les cartes d’actions fournissaient en ligne la plupart des informations : scrubbing sur les graphiques, swipe actions, statistiques clés, etc.
  • Lorsqu’on tapait sur une carte, celle-ci restait en place et des cartes animées de news ou de détails de position apparaissaient ; l’implémentation reposait notamment sur overlayPreferenceValue et anchorPreference
  • Les sheets personnalisées comprenaient un sélecteur de date, des écrans d’introduction, un fond étoilé scintillant et une interpolation de la transparence du fond pendant le drag
  • Le menu personnalisé de l’app prévoyait un espace pour afficher une offre payante ou l’état d’un abonnement, et pouvait être fermé par tap ou scroll
• Les swipe actions et les headers ont aussi été implémentés à la main
  • Les actions se déplaçaient en fonction de la distance du swipe, puis passaient en état sélectionné avec une animation au-delà d’un certain seuil
  • Les boutons du header apparaissaient sans bordure en haut de page, puis se transformaient en boutons discrets lors du scroll
  • Le texte Stocketa se décalait vers le haut et disparaissait progressivement pendant le scroll

Suivi des transactions et fonctionnalités de l’app

• L’implémentation initiale a commencé par une scrollview de cartes d’actions, des graphiques et la persistance en base de données
  • Au départ, l’app utilisait Core Data, puis a migré vers Firebase
  • Les appels et le polling des fournisseurs de données financières ont ensuite été intégrés, avec IEX comme premier fournisseur
• Stocketa n’enregistrait pas seulement le nombre d’actions détenues par valeur, mais mettait en place un suivi au niveau de la transaction
  • L’objectif était d’afficher non seulement les gains/pertes globaux à l’achat et à la vente, mais aussi les gains/pertes par transaction
  • Lors d’une vente, il fallait gérer des méthodes de coût comme FIFO et LIFO, et calculer à partir de quelles transactions passées les actions étaient vendues
  • Pour les splits d’actions, il ne suffisait pas de modifier l’historique : il fallait gérer à la fois l’application automatique des nouveaux splits et leur application manuelle
• Les fonctionnalités se sont étendues à toute l’app
  • Onboarding : au lieu d’un carrousel classique, l’app utilisait une transition où les pages entraient selon l’axe Z, avec présentation de composants clés comme les cartes d’actions
  • Import TSV : les transactions pouvaient être importées depuis des fichiers TSV créés dans un tableur, et l’état de l’import était réécrit dans le TSV pour permettre une réimportation après synchronisation iCloud
  • Saisie d’achat : formulaire dédié aux actions, centré sur quantité, prix et date ; en changeant la date, le prix historique du jour concerné apparaissait en placeholder
  • Saisie de vente : prise en charge de FIFO, LIFO, Average cost, Highest cost, Lowest cost et des lots spécifiques
  • Écran d’abonnement : texte en parallaxe, flou qui se dissipe au scroll, cartes de fonctionnalités animées par le mouvement, petit effet fireworks en bas de page
  • Carte de membership : affichage interactif de l’état d’un compte abonné actif, avec effet de starfield en fond et effet shimmer
  • Réglages d’affichage des cartes d’actions : plusieurs styles de cartes et options, avec micro-animations lors des bascules
  • Carte de position : affichage d’informations agrégées basées sur les réglages en haut du scroll principal
  • Widgets : trois types — action individuelle, portefeuille, portefeuille simplifié — avec de grands dégradés qui changent selon la performance
  • Délai Face ID : l’app, traitant d’actifs financiers, permettait d’ajuster le délai avant reverrouillage après un changement d’app
  • Sheet des jours fériés de marché : affichage des jours de fermeture pour les comptes détenant des actions, ce qui nécessitait aussi du code serveur pour reproduire le même comportement dans les widgets
  • Sheet de feedback : affichage des problèmes connus et des fonctionnalités prévues, avec possibilité d’inclure un token de vérification de compte pour les questions liées à un compte
  • Suppression de compte : suppression complète du compte directement dans l’app, en réponse à une exigence de l’App Store introduite en 2021

Apprendre et reconstruire avec SwiftUI

• Stocketa a été développé en parallèle d’un apprentissage de Swift et SwiftUI, ce qui a conduit à une reconception et réimplémentation continues de nombreux écrans et parties de l’app
• Depuis iOS 13, SwiftUI a progressé en performance, en composants et en fonctionnalités ; avec iOS 17, il propose aussi des éléments comme les shaders, keyframes et scroll transitions
• SwiftUI s’est révélé utile non seulement comme outil de code, mais aussi comme outil de design
  • Un designer peut créer rapidement des layouts
  • Il est facile d’y ajouter des interactions
  • Il permet de ressentir concrètement un design avec des outils natifs
• Les cas nécessitant UIKit sont restés limités
  • Champs de texte personnalisés pour un contrôle plus fin de la saisie, du style et du formatage
  • CollectionView pour réorganiser l’ordre des valeurs par drag
  • Émetteurs de particules pour des effets comme confetti ou ciel étoilé nocturne
  • UILongPressGestureRecognizer pour récupérer le point de départ d’un appui long

Backend et exploitation de TestFlight

• Au départ, l’idée était une app simple sans backend ni comptes utilisateur, mais il est vite devenu nécessaire d’avoir un backend dédié
  • Un proxy backend a été créé pour éviter d’intégrer les clés d’API financières directement dans l’app
  • Du rate-limiting et du throttling ont été ajoutés pour éviter que l’abus d’API n’augmente les coûts
  • Sign In With Apple a été intégré
  • Les statistiques par valeur étaient mises en cache pendant un certain temps afin que plusieurs comptes demandant la même donnée ne déclenchent qu’un seul fetch
• Le backend, basé sur Node/Express, a grossi jusqu’à environ 13 000 LOC
  • Il tournait sur Cloud Run
  • Il gérait l’authentification, le cache, les actualités, la logique métier principale, le nettoyage des données, les notifications, les widgets, plusieurs intégrations d’API et un peu de scraping
• La gestion du travail se faisait avec Linear
  • Tâches, idées, fonctionnalités, feedback client et jalons y étaient suivis
• TestFlight a commencé comme une petite alpha réservée à des proches, puis s’est élargi progressivement
  • Jusqu’à environ 1 000 personnes ont été invitées à un moment donné
  • La liste d’attente comptait plusieurs milliers de personnes, mais elle n’a pas été davantage ouverte à cause du coût des API et de l’hébergement, ainsi que de la charge liée au support et au traitement des retours
  • Les retours mêlaient bonnes premières impressions, demandes de fonctionnalités et rapports de bugs

Design et implémentation du site web

• Le site initial était une landing page simple destinée à susciter de l’intérêt et à collecter des e-mails pour la liste d’attente
• Le design initial comprenait des formes ondulées inspirées librement des montées et descentes des graphiques boursiers, ainsi que de petites cartes d’actions flottantes
  • Ces mini-cartes contenaient des line charts en SVG, animés au chargement de la page
  • Le mouvement doux en arrière-plan était réalisé avec offset-path en CSS et deux animations keyframe
• La page d’accueil v1.0 a été finalisée début 2021
  • Une version plus aboutie du site a été créée une fois suffisamment de fonctionnalités de l’app implémentées pour être montrées
  • Au lieu du schéma classique frame de téléphone + headline, le site proposait un dispositif où un téléphone 3D bougeait au scroll et où une vidéo teaser de l’app se lançait
  • Plutôt que Lottie, le choix s’est porté sur un rendu en JavaScript dessinant une séquence d’images sur canvas et offscreenCanvas
  • Rotato a servi à produire un court screencast de Stocketa sous forme de vidéo 3D de téléphone et de séquence d’images PNG
  • La génération, l’optimisation et la mise à jour de cette séquence d’images sont ensuite devenues une grosse contrainte
• La page d’accueil v2.0 a été redessinée un an plus tard
  • Pour montrer davantage de fonctionnalités et d’améliorations, l’objectif était de proposer une liste de fonctionnalités facile à parcourir, plutôt qu’une longue série de modules répétitifs
  • Le site a adopté une structure en deux panneaux, avec à droite un cadre d’appareil fixe et à gauche une liste de fonctionnalités scrollable
  • Au survol d’un élément, la capture affichée dans le cadre de l’appareil changeait
  • Sur mobile, le header a été remplacé par un carrousel scrollable de cadres d’appareil
  • Un gradient sur le texte hero au scroll, des changements de couleur d’icônes, un gradient de fond au hover et des émetteurs de particules pour les icônes ont été ajoutés

Les limites imposées par les API de données financières

• La qualité des données financières dont dépendait Stocketa n’était pas suffisante pour un lancement viable
• Le premier fournisseur, IEX, présentait plusieurs problèmes
  • Les graphiques pouvaient être obsolètes ou les prix inexacts
  • Les problèmes étaient particulièrement marqués pour les actifs peu échangés sur la place IEX
  • Il n’y avait pas de données de marché OTC, et il aurait fallu signer une licence coûteuse directement avec OTC
  • Les données sur les actions cotées au Nasdaq étaient aussi fortement limitées, et il manquait même des données de base comme le pre-market et l’after-hours
  • Les données sur les fonds communs de placement ont été totalement supprimées sans préavis
• Un autre fournisseur ensuite envisagé pour un usage commercial coûtait 100 $/mois, mais ses problèmes de données et de fiabilité étaient encore plus graves
  • Des endpoints renvoyaient des données obsolètes ou incorrectes
  • Lorsqu’un problème était signalé, les bugs étaient ignorés ou niés
• Certaines données étaient difficiles à obtenir même via des API payantes, ce qui a obligé à créer dans le backend un moteur de scraping
  • dividend yield
  • earnings dates
  • données OEF
• Les données de marché de haute qualité avaient une structure tarifaire incompatible avec un développeur d’app indépendant
  • Les tarifs commerciaux de certains grands fournisseurs de données sur les marchés américains commençaient à 2 000 $/mois
  • Les données d’indices ou d’options impliquaient des coûts supplémentaires
  • Un fournisseur a proposé un plan startup à 499 $/mois plus un tarif par MAU, mais cela restait jugé beaucoup trop cher au regard des besoins
• Un projet qui dépend d’API de données financières porte le risque de bâtir un business sur les API d’entreprises tierces, un problème vu comme similaire aux changements d’API de Twitter et Reddit

Pourquoi le lancement a été abandonné

• Dès le départ, Stocketa était un side project, pas une véritable entreprise
  • Pour en faire un vrai business, il aurait fallu davantage de fonctionnalités et un modèle de monétisation plus développé
  • Cela aurait potentiellement impliqué d’aller vers le conseil financier ou le trading d’actions, des secteurs très encombrés dominés par de grandes entreprises
  • Cette direction ne correspondait pas à l’idée de départ, qui était de créer une app simple et élégante
• Trois raisons principales expliquent l’arrêt
  • Les données : pour lancer l’app avec un prix d’abonnement raisonnable, il fallait des données financières fiables, abordables et de haute qualité, mais leur coût et leur difficulté d’accès étaient trop élevés
  • Le support : l’usage observé via TestFlight montrait qu’un investissement conséquent serait nécessaire en support client, e-mails, maintenance et développement continu
  • Le temps : Rewind AI a été choisi comme priorité, et Stocketa occupait déjà depuis des années les soirées, les week-ends et même le temps consacré à l’écriture sur le blog
• L’objectif initial d’apprentissage de Swift et SwiftUI a néanmoins été atteint
  • Même sans lancement, le projet a permis d’apprendre en profondeur le développement iOS natif
  • Les connaissances de SwiftUI acquises avec Stocketa ont été très utiles pour le travail sur Rewind AI

[GN⁺]

Avis sur Hacker News

• Le fait qu’un projet de plusieurs années ne soit jamais réellement utilisé peut presque ressembler à une médaille d’honneur. Pas une médaille très sage, mais pour un développeur comme moi, qui a tendance à s’obséder dans le bon sens du terme et à se faire totalement absorber, c’est presque un apprentissage nécessaire.
  Quand je parle de mes expériences passées et de la douleur qui en est venue, j’ai l’impression que les gens restent interdits. Si l’on n’a jamais passé plus de 10 heures par jour pendant plus d’un an sur quelque chose, il est difficile de comprendre ce que l’on ressent après y avoir consacré des milliers d’heures sans aucun résultat.
  J’ai eu beaucoup de projets réussis, et certains marchent encore bien, mais ces projets de plusieurs années sont irréversibles. C’était peut-être nécessaire pour apprendre, mais y repenser me rend encore triste et mélancolique.

  • J’ai vécu quelque chose de similaire en 2016, en créant une app iOS tout en apprenant Swift et UIKit par moi-même. Pendant deux ans, j’y ai consacré environ 2 heures par jour, 5 jours par semaine, soit plus de 1 000 heures, mais l’app n’a finalement jamais été publiée.
    En revanche, j’y ai gagné des compétences qui ont fait de moi un bien meilleur programmeur, et j’ai appris à aimer Swift. Aujourd’hui, grâce aux progrès des outils de développement et des API d’Apple au cours des 7 dernières années, je pense que je pourrais recréer toute cette app de zéro en un week-end.
    Ce genre de projet mérite d’être célébré. La programmation peut être un art, et l’art, en tant qu’exutoire créatif, peut aussi être fait uniquement pour soi-même.
  • Les regrets à propos de ce genre de choses n’ont de sens que si, à l’époque, on pouvait déjà savoir que ça ne marcherait pas, mais qu’on a continué à forcer malgré un meilleur jugement. Si l’on a pris la meilleure décision possible avec les informations dont on disposait à ce moment-là, c’était tout ce qu’on pouvait faire ; le reste relève de la chance.
    Se torturer pour un projet passé avec des connaissances acquises plus tard, ce raisonnement axé sur le résultat, n’est pas très utile. La plupart des projets et des entreprises échouent, c’est la réalité.
    Je me souviens d’un ancien financier qui écrivait que « personne n’est licencié pour avoir gagné de l’argent par hasard sur une mauvaise transaction ». Dans une culture centrée sur les résultats, on oublie facilement que la seule chose que nous contrôlons réellement, c’est le processus.
  • J’ai passé 10 ans sur un projet logiciel, et six mois après l’avoir terminé, je n’ai toujours pas gagné un centime :(
    J’en ai tiré une leçon précieuse, comme savoir quand s’arrêter, mais ce fut un cours beaucoup, beaucoup trop long. Je n’arrive toujours pas vraiment à y repenser.
  • Il n’y a rien de plus démoralisant que de consacrer des années à un projet, puis de le montrer à quelqu’un qui le rejette aussitôt en disant « bof », ou qui vous dit simplement de faire X.
  • C’est probablement plus douloureux parce que l’objectif était la réussite, c’est-à-dire l’usage de l’app ou les revenus. Si le plaisir ou l’apprentissage avaient été la raison principale, on l’aurait peut-être vécu différemment.
    Je me demande si l’on ne devrait pas conseiller de ne jamais lancer un projet de plus d’un an sans être certain de ne pas le regretter même si personne ne l’utilise.

• Excellent billet, mais la conclusion me semble triste. Il y a tellement d’apps pour lesquelles j’aimerais avoir une version comme celle-ci, « sans rien d’inutile », et la quantité de travail investie ici est impressionnante.
  J’ai lancé une app iOS plus simple, qui est montée jusqu’à environ 1 000 utilisateurs actifs par jour grâce au trafic organique, mais j’ai fini par la fermer. J’avais ajouté un achat in-app à 1,99 $ ou 2,99 $ pour supprimer les pubs, et je gagnais environ 70 $ par mois tout en gérant les rapports de bugs.
  À l’époque, SwiftUI n’était pas encore mature, donc il fallait utiliser UIKit, et je me heurtais sans cesse à des cas limites difficiles à corriger.
  Le coup de grâce a été lorsque Google a affirmé que j’avais cliqué sur mes propres publicités et a suspendu leur diffusion. Pratiquement tous mes revenus ont disparu, et j’ai compris que même en travaillant dur sur quelque chose, tout dépendait au final des caprices des géants de la tech.
  Apple prenait 30 % sur tous les achats in-app, les revenus publicitaires étaient dérisoires, et Google pouvait les couper sans raison ni possibilité de recours. Je ne cherchais pas à gagner beaucoup d’argent, mais il me fallait une raison de continuer à y consacrer du temps et de l’énergie, et je ne pouvais plus le justifier.

  • Que Google coupe les pubs au motif qu’on a cliqué sur ses propres annonces ressemble à une absurdité beaucoup trop sévère.
    Je ne comprends pas pourquoi ils ne permettent pas aux développeurs d’enregistrer des appareils exclus des revenus, des plages d’IP ou des listes de lieux. On finit forcément par utiliser sa propre app, et dans bien des cas, quand on fait défiler l’écran, il est presque impossible de ne jamais toucher une pub par accident.
    Les tests en conditions réelles sont aussi importants, et il existe même une petite possibilité qu’une publicité soit réellement intéressante et qu’on clique dessus légitimement en tant que client potentiel. Mais dans l’état actuel, cela revient pratiquement à dire de ne pas utiliser sa propre app.
    Je ne vois pas à qui profite une politique aussi fondamentalement stupide, à part aux développeurs ou managers de Google qui s’y accrochent. On se demande si c’est vraiment si difficile de gérer ça un minimum correctement.

• On peut penser de la même manière au musicien de chambre qui n’a donné ni concert ni album en 20 ans, à l’athlète d’enfance qui n’a plus touché un ballon depuis ses 18 ans, au coureur qui ne participe pas à des courses, ou à l’intellectuel qui n’enseigne pas.
  Avec le même présupposé « production externe = valeur », on pourrait même l’étendre à un être humain qui a vécu des décennies sans avoir d’enfant. Ce n’est pas ma conviction, je dis seulement que c’est là où mène la logique.
  Mais ce genre de jugement est une construction humaine, et ressemble au miroir d’un impératif biologique qui nous pousse à envoyer dans le monde « nos enfants » longtemps portés. Nous nous demandons pourquoi ces choses ne devraient pas acquérir leur propre vie, et nous souhaitons qu’elles continuent elles-mêmes à produire des résultats et à tisser l’avenir.
  Suivre cet impératif est-il le sommet moral, éthique et joyeux ? Pour certains, oui, et je ne veux pas juger. Mais pour d’autres, curieusement, ce n’est pas le cas.

• Je me demande s’il envisagerait de vendre ce projet. Le concept me plaît, et il semble y avoir des clients intéressés, mais il n’a pas l’air de vouloir assumer la charge du support ni la commercialisation.
  Cela fait environ un an que j’ai créé un outil de suivi d’actifs (https://jch.app), mais il est encore très loin en termes de fonctionnalités et d’expérience utilisateur.
  C’est un travail énorme, et j’ai aussi beaucoup apprécié le récit détaillé du parcours. J’ai hâte de voir ce qui sortira ensuite de rewind.ai

• Ce n’est pas très différent des innombrables personnes qui consacrent sans fin du temps à d’innombrables projets qui n’ont pas beaucoup de sens pour qui que ce soit d’autre. Comme bricoler un vélo ou s’occuper de trains miniatures.
  La différence, c’est qu’une app peut être publiée, documentée et archivée aussi facilement, alors que « le temps passé à découper et souder des pièces de vélo bizarres » est plus difficile à traiter ainsi, sauf à tout mettre sur YouTube.
  Bien sûr, beaucoup de gens le font, et cela a une certaine valeur, mais quand on essaie de transformer des hobbies et des quêtes personnelles en produits poursuivant un autre objectif qu’eux-mêmes, on passe parfois un peu à côté de l’essentiel.
  Je ne veux pas dire que ce texte est mauvais. Il ne donne pas l’impression de se plaindre ou d’être en colère ; comme dit au début, on sent plutôt l’envie de « garder une trace quelque part, d’une manière ou d’une autre ». La majeure partie de mon GitHub, c’est pareil.

  • L’idée que ce qui aurait été possible devienne le point de référence pour évaluer ce qui s’est réellement passé est profonde.
    Cet ajustement prématuré du référentiel d’évaluation peut ne pas être très utile, car il brouille le résultat réel. Dans ce cas, il est facile pour l’auteur d’avoir honte de l’effort « gaspillé », alors qu’une réaction plus juste serait sans doute de la gratitude pour ce qu’il a appris.
    Ce qu’on apprend dans ce type de projet est énorme.

• Ce texte fait peur parce que je m’y reconnais beaucoup trop. Se laisser absorber par la création d’un excellent produit, s’identifier à l’artisanat, et ressentir du rejet pour l’approche « sans âme » du MVP rapide et bricolé, puis des tests de marché itératifs.
  Si vous avez déjà mis les pieds sur le subreddit r/SaaS, c’est exactement l’inverse de ce que j’aime dans le développement logiciel.
  Mais je sais aussi que si j’arrive à changer mon état d’esprit vis-à-vis des tests de marché et des itérations rapides et imparfaites, cela peut au contraire me donner une meilleure base pour lâcher prise et me concentrer sur l’artisanat.

• Je comprends. Moi aussi, je suis encore en train de construire un backend bancaire. Cela fait 5 ans, avec le cœur de système, la comptabilité, les clients, les comptes, les paiements (SEPA et cartes), les notifications (un truc façon ServiceNow), le filtrage des sanctions, un moteur de risque et de monitoring, les flux d’événements et le reporting.
  Je commence à me demander si je suis fou ou stupide d’avoir pris en charge un chantier aussi énorme. Je n’ai même pas encore conçu de landing page, et le code fait environ 150 000 lignes.

  • Étant dans ce domaine, je recommande vivement de prendre contact avec des clients potentiels et de commencer à bâtir la confiance le plus vite possible.
    Même avec tous les bugs, limites et problèmes de sécurité des plateformes existantes, il nous a fallu bien plus de 5 ans pour obtenir assez de confiance afin de convaincre des clients de passer à notre plateforme de core banking.
  • Moi aussi, j’ai construit une solution e-commerce avec paiements, messagerie REST, serveur e-mail (IMAP/SMTP), publicité d’affiliation, ainsi que notre propre système de paiement, de reporting et de contrôle d’accès. J’avais amené toute la solution jusqu’à l’état d’alpha, avec des frontends web desktop et mobile.
    Puis, comme les apps mobiles devenaient importantes, j’ai aussi commencé à développer des apps natives, et là c’était trop. J’ai fini en burnout, puis en faillite, donc je ne recommande pas les projets gigantesques.
    J’ai beaucoup appris, mais le gâchis n’en valait pas la peine. Le temps est trop précieux pour reconstruire autant de choses. Maintenant, je ne fais plus que des « petits » projets de 6 à 12 mois maximum.
  • Tu construis un backend bancaire comme side project ? Intéressant. Je me demande si c’est plutôt un projet pour le plaisir, ou s’il y a un objectif commercial.
    Je me demande aussi s’il pourrait être open source.
  • Il faut le lancer. Publie des captures d’écran, une liste de fonctionnalités et une liste distincte de fonctionnalités prévues, puis commence par un formulaire d’inscription à la bêta.
    Si tu ne peux pas lancer une version de base en retirant tout ce que tu aimerais encore ajouter, il faut envisager de mettre le projet de côté un moment.
    Ces 20 dernières années et plus, j’ai créé beaucoup de projets et de produits, et 2 ou 3 ont connu une forte croissance. Les autres ont des milliers d’utilisateurs, mais pas de source de revenus durable.
    Celui qui est devenu une activité rentable a été lancé dans une version « construite en un week-end », puis développé progressivement pendant 7 ans.
  • Il faut aussi te demander : « À quoi ressemblerait le succès ? » Si tu n’as pas eu de revenus pendant 5 ans, il est probable que tu te sois habitué à cette étape.
    Cet état familier peut devenir un piège qui te fait constamment trouver du travail à faire avant le lancement. Il peut donc être utile de recadrer les choses mentalement.

• J’ai lu récemment que Leonardo DaVinci était un énorme procrastinateur, et qu’il avait beaucoup de projets inachevés.
  Je l’ai toujours admiré comme quelqu’un qui avait si bien réussi dans plusieurs domaines, mais l’apprendre a changé ma façon de voir la procrastination : elle fait partie de nous, les personnes créatives.
  On peut y voir un échec, mais on peut aussi la réinterpréter comme une partie du processus. Au fond, nous aimons créer des choses.

• Il a en fait pris le conseil habituel « construisez un MVP, lancez vite, itérez », puis a fait exactement l’inverse.

  • Après 10 ans à ne lancer que des expériences médiocres dans de grandes entreprises tech, il était prévisible qu’il fasse exactement l’inverse en se concentrant sur la qualité. https://paulstamatiou.com/craft/
  • Je ne sais pas si ce conseil s’applique aussi aux développeurs solo. Dans un produit forcément maximaliste comme cette app, il faut être seul responsable des moindres détails, donc il n’y a pas vraiment moyen d’avancer vite.

• Excellent article sur un side project qui a l’air génial. Je le lisais avec intérêt quand j’ai découvert rewind.ai, qui a l’air pas mal aussi
  La confidentialité est essentielle pour quelque chose de potentiellement intrusif comme l’enregistrement automatique continu de l’écran et de l’audio ; en lisant la section « Privacy first », une question m’est venue
  Il est écrit : « Chiffrez vos données avec FileVault. Apple FileVault fonctionne avec Rewind. Activez-le et vos données seront chiffrées ». Est-ce que Rewind fait quelque chose pour qu’Apple FileVault « fonctionne avec Rewind » ?
  Ou bien parle-t-on simplement du chiffrement du disque standard qui s’applique à tout ? C’est une vraie question. J’aimerais utiliser Rewind, mais cette formulation peut être interprétée comme un habillage un peu gratuit
  La phrase « seules les données textuelles pertinentes sont envoyées dans le cloud et sont chiffrées en transit » me donne une impression similaire. « Chiffrées en transit », cela veut-il dire le chiffrement TLS standard ? Rewind a l’air bien, mais il faut pouvoir lui faire confiance

  • Le site web de Rewind indique ceci
    « Aucune intégration cloud requise. Tout fonctionne automatiquement, sans avoir à connecter divers services comme Gmail, Dropbox ou Slack »
    Pourtant, dans les détails de la politique de confidentialité officielle sur https://www.rewind.ai/privacy, on lit ceci
    « [Éléments collectés :] Informations générées par OpenAI. Dans le cadre de l’intégration OpenAI de Rewind AI, nous pouvons également collecter les sorties générées par OpenAI, notamment les résumés de transcription d’enregistrements audio et d’autres données générées par l’intégration OpenAI »
    Dans ce cas, même si « aucune intégration cloud n’est requise », mon audio est-il partagé avec OpenAI ?
    Par ailleurs, sur https://www.rewind.ai/privacy-first, il est écrit : « Que se passe-t-il quand vous effectuez une recherche dans Rewind ? Toutes les données d’enregistrement restent en local »
    Je ne sais pas laquelle de ces deux versions est la bonne. J’aimerais faire confiance à Rewind, mais les incohérences dans les explications sur la manière dont les données utilisateur sont traitées me font hésiter
  • Merci de l’avoir signalé. Il semble que cette page doive être mise à jour, et il existe aussi un chiffrement propre au produit. Plus de détails ici : https://help.rewind.ai/en/articles/7242593-is-the-rewind-dat...