Le code de ma startup, qui a échoué après 3 ans, est désormais public

 (dylanhuang.com)
3 points par GN⁺ 2024-12-18 | 1 commentaires | Partager sur WhatsApp
  • Konfig a démarré comme une startup d’outils pour développeurs visant à faciliter les intégrations d’API, puis a fermé trois ans plus tard en publiant sa base de code ainsi que ses livrables opérationnels
  • Le produit principal était un générateur de SDK capable de créer des bibliothèques clientes à partir de spécifications OpenAPI, avant de s’étendre à la documentation et à un environnement interactif de test d’API
  • Malgré l’intérêt de certains clients startup, il était difficile d’en faire une activité à hypercroissance en raison de la complexité des contrats et d’un niveau de prix trop bas
  • L’entreprise a ensuite pivoté vers un produit d’IA vertical B2B SaaS, mais n’a pas trouvé de traction suffisante, malgré de nombreux entretiens et démarches commerciales, pour y voir les bases d’un grand marché
  • Le dépôt public est publié dans l’état exact de la fermeture, sans nettoyage ni correction, et inclut le code produit, les expérimentations du pivot, les scripts commerciaux, la configuration de déploiement et le site marketing

Les outils API pour développeurs créés par Konfig

  • Konfig est une startup d’outils API pour développeurs lancée fin 2022, avec pour objectif de simplifier la manière dont les développeurs travaillent avec les API
  • L’objectif était d’améliorer la génération de SDK, la documentation et les outils autour des tests
  • Le produit phare était le générateur de SDK
    • Il prenait des spécifications OpenAPI en entrée pour générer des bibliothèques clientes dans plusieurs langages de programmation
    • Il s’est ensuite étendu à un outil de documentation d’API et à un environnement interactif de test d’API

Limites de croissance et pivot vers l’IA

  • Il y avait de la traction chez certains clients startup, mais cela ne s’est pas transformé en activité à hypercroissance
  • Il était difficile de conclure des contrats avec des prospects, et même avec un ROI démontrable, le niveau de prix restait trop bas
  • Avec les avancées de l’IA générative, l’équipe a estimé pouvoir résoudre des problèmes auparavant difficiles à traiter et a pivoté vers un produit d’IA vertical B2B SaaS
  • Plusieurs idées ont fait l’objet d’entretiens utilisateurs et d’efforts commerciaux, mais aucune n’a montré une traction suffisante pour convaincre qu’elle pouvait devenir une très grande entreprise

Un dépôt public ouvert tel qu’il était à la fermeture

  • Le dépôt public est konfig-dev/konfig
  • Le dépôt est publié dans l’état exact où se trouvait l’entreprise à sa fermeture
    • Aucun nettoyage
    • Aucune mise en forme
    • Aucune correction
    • La base de code montre l’état brut et non filtré d’un vrai code de startup

Principaux produits développés en 3 ans

Code opérationnel et expérimentations publiés avec le reste

Le regard rétrospectif du fondateur

  • Dylan Huang a quitté son emploi en mars 2022 pour se consacrer entièrement à sa startup, en relevant ce défi tout en connaissant le risque d’échec
  • Il considère cet échec comme une expérience qui lui a appris plus que le succès
  • Pour la suite, il prévoit d’explorer de nouvelles opportunités, de chercher un poste adapté sur le marché de l’emploi et de continuer à apprendre et à progresser
  • Il reste aussi ouvert à l’idée de se relancer un jour dans la création de quelque chose par lui-même

À lire aussi

1 commentaires

 
GN⁺ 2024-12-18
Avis de Hacker News

  • Si l’objectif avait été une petite entreprise plutôt qu’une « énorme activité » en « hypercroissance », je me demande combien d’excellents produits de niche existeraient encore aujourd’hui.

    • C’est facile à dire, mais en pratique c’est vraiment difficile, car il faut tenir 3 à 5 ans quasiment sans salaire tout en espérant des résultats comparables à ceux d’une entreprise financée par des investisseurs.
      Dans les pays développés, pour qu’une startup de 2 ou 3 personnes survive, il faut vendre énormément de licences à 10 dollars par mois, sans oublier le coût d’opportunité.
    • Si l’on lève des fonds pour couvrir les coûts nécessaires chaque mois, du point de vue des investisseurs il faut un potentiel d’hypercroissance pour que le calcul de portefeuille tienne.
      Si l’on vise dès le départ une petite entreprise durable et qu’on réussit, on peut éviter l’investissement ; mais si l’entreprise a pivoté vers une direction entièrement nouvelle en milieu ou fin de parcours, il y a de fortes chances que la majeure partie des réserves ait déjà été brûlée.
    • Avec un tel résultat, il est plus logique d’aller travailler dans une grande entreprise et de recevoir une rémunération similaire sans risque.
    • Je me posais aussi cette question. Je suis l’un des trois cofondateurs d’une entreprise bootstrapée qui fait du conseil dans une région où le coût de la vie est faible ; nous versons depuis plusieurs années 50 000 dollars par an à chaque fondateur, et sans avoir eu une chance particulière ni un jugement business exceptionnel, nous nous en sortons plutôt bien.
      Cette année, le chiffre d’affaires est de 400 000 dollars, le bénéfice de 150 000 dollars, la croissance de 40 %, et les perspectives commerciales sont bien meilleures qu’en début d’année. Nous nous attendons à une forte croissance l’an prochain aussi, et nous sommes loin de la saturation du marché, donc il reste de la marge pour croître pendant encore plusieurs années.
      En combinant le salaire et un tiers des bénéfices, cela fait 100 000 dollars cette année ; avec 40 % de croissance, l’entreprise double tous les deux ans. Si tout se passe bien, les salaires et les bénéfices deviennent déjà très intéressants, auxquels peut s’ajouter une opportunité de vente permettant aux fondateurs de gagner plusieurs millions de dollars.
    • On sent là un sous-entendu du type « tu vois, je t’avais dit que c’était difficile ! ».
      Vouloir bâtir une entreprise comme Google ou une entreprise comme Basecamp, ce sont deux objectifs valables ; ce sont simplement des types d’entreprises différents.
      Au contraire, il est facile de sous-estimer le risque de créer une « activité à faible risque », et toute entreprise est difficile. Bravo à Konfig.

  • En tant que client de Konfig, c’est vraiment regrettable. Nous avons peut-être même été leur premier client, et je crois que nous étions mentionnés dans les premiers commits.
    Dylan et Anh-Tuan ont résolu pour nous plusieurs vrais problèmes de façon remarquable. Ils fournissaient au même endroit des SDK générés ainsi qu’une documentation et des tutoriels hébergés et agréables à consulter, et permettaient aux utilisateurs d’appeler directement notre API pour expérimenter tout de suite avec de vraies données.
    Avant Konfig, nous écrivions à la main, de manière assez désordonnée, les SDK enveloppant notre API, et notre documentation était hébergée sur ReadMe, mais à cause des exigences de signature des requêtes de notre API, cela ne fonctionnait pas bien de façon interactive.
    Grâce à l’ouverture en open source de Konfig, nous hébergeons désormais nous-mêmes la documentation : https://docs.snaptrade.com/
    J’ai beaucoup de respect pour cette équipe, et j’aurais vraiment aimé qu’ils trouvent un moyen de continuer.
    Si vous gérez un produit comme Konfig, que les clients adorent mais dont le chiffre d’affaires ne croît pas autant que nécessaire, cela vaut aussi la peine d’envisager d’augmenter davantage les prix. Nous aurions payé 2 à 3 fois ce que Konfig nous facturait, et davantage encore en grandissant, mais ils ne nous l’ont jamais demandé et n’ont pas non plus mis en place de tarification à l’usage, par exemple un abonnement mensuel par SDK ou par démo.

    • J’ai découvert Konfig grâce à votre produit. La documentation était si bonne que j’ai été obligé d’aller voir ce qui était utilisé derrière, et c’est vraiment mieux que Swagger ou Redoc.
    • Je me demande si vous avez essayé d’utiliser directement https://github.com/OpenAPITools/openapi-generator.
    • Si vous cherchez une alternative légère pour la documentation d’API, je recommande Scalar. C’est simple et facile à utiliser, tout en étant bien meilleur que la documentation Swagger.

  • La culture startup américaine est vraiment étrange. Tout n’a pas besoin de passer à l’échelle à toute vitesse, et tout n’a pas besoin de devenir énorme
    Une entreprise devrait se concentrer davantage sur la durabilité, pas sur le fait de pivoter trois fois en 2 ou 3 ans avant de fermer boutique

    • D’un côté c’est vrai, mais de l’autre, cette focalisation obsessionnelle sur « hypercroissance ou échec » est probablement ce qui a propulsé l’écosystème startup américain là où il est aujourd’hui, et la raison pour laquelle il est si loin devant le reste du monde
      Si vous dites à beaucoup de fondateurs de startups européens que, « dans 5 ans, l’entreprise plafonnera à 15-20 employés, aura un cash-flow stable et vous versera 200 000 à 250 000 dollars par an », ils considéreront cela comme une grande réussite. Aux États-Unis, surtout si vous avez levé du capital-risque, cela peut être vu comme un échec
      J’ai déjà entendu un investisseur en capital-risque de la Silicon Valley dire ouvertement : « Si vous considérez comme un succès de vendre votre entreprise 50 millions de dollars, vous n’avez pas le bon état d’esprit et je ne veux pas travailler avec vous »
      Si l’on se contente de petites réussites et d’une croissance stable sans relever de grands défis ni prendre de gros risques, on n’obtient jamais les grosses récompenses. Pour un individu, c’est peut-être plus sain, mais pour l’économie dans son ensemble, cela peut être mauvais
    • Les petites entreprises rentables — celles avec de petites équipes et des objectifs de long terme, qui peuvent sembler ennuyeuses — ne semblent pas souvent arriver en une de HN, parce qu’elles ne se fixent pas d’objectifs irréalistes
      C’est intéressant de voir cette culture adopter une mentalité du type « move fast and break things », mais elle semble surtout s’appliquer au secteur tech. Il y a aussi le fait qu’un entrepreneur qui a échoué plusieurs fois soit qualifié de « serial entrepreneur » ; il est difficile de considérer comme un succès la vente d’une entreprise non durable
      C’est amusant d’imaginer ce que cela donnerait si quelqu’un qui a échoué dans plusieurs sports se présentait comme un « serial athlete »
    • Le problème, c’est qu’à partir du moment où l’on prend du capital-risque, on est poussé vers l’hypercroissance
      Sans capital-risque, le chemin vers une activité viable est beaucoup plus difficile et plus long, sauf si l’on peut s’autofinancer via du conseil ou quelque chose du genre. Le modèle ici, c’est 37 Signals, mais c’est une exception notable : ce sont eux qui ont créé Rails
      Et même une fois arrivé là, un concurrent financé par du capital-risque peut débarquer avec de meilleurs réseaux et plus d’argent, et vous écraser
    • Je suis en Europe et je travaille dans une entreprise qui rencontre exactement les mêmes difficultés
      Les cycles de vente B2B auprès des grands comptes sont ridiculement longs, et les prix auxquels on peut vendre aux PME ne suffisent pas
      Même quand nous apportons de la valeur et faisons gagner du temps aux clients, expliquer cette valeur reste toujours difficile
      L’herbe est toujours plus verte ailleurs, mais quand on fait du B2B et qu’on répète les mêmes galères pendant des années pour garder la lumière allumée, avec des conversations similaires chaque mois avec des clients différents, à devoir expliquer 10 fois par an pourquoi cela a de la valeur, je comprends que les gens n’aient pas envie de rester coincés là-dedans. Le burn-out peut aussi arriver vite
      Je comprends donc aussi l’envie de trouver une idée d’entreprise dont la valeur est évidente et où les gens crient « prenez mon argent »
    • Plusieurs facteurs expliquent pourquoi les entreprises occidentales préfèrent l’expansion verticale plutôt qu’horizontale
      Le premier est le retour sur investissement. Si l’on fait venir l’argent d’autrui, ces personnes s’attendent évidemment à un rendement, et un investisseur avisé diversifie son portefeuille, donc il sait que beaucoup d’investissements échoueront. Il pousse donc chaque participation à croître le plus possible pour compenser les pertes, en comptant sur un petit nombre d’entreprises aux performances exceptionnelles pour rattraper les échecs
      Cette croissance verticale se voit non seulement dans les startups, mais aussi dans les grandes entreprises. À mon avis, le formalisme, la surréglementation et la bureaucratie y jouent un grand rôle. S’il faut passer par d’innombrables démarches — autorisations, mise en place des comptes fiscaux et de paie, etc. — et encore davantage pour entrer en Bourse, il peut être beaucoup moins cher et moins risqué d’élargir le périmètre d’activité d’une entreprise déjà établie que de créer une nouvelle société séparée

  • Je pense que nous étions concurrents. Je suis le fondateur de ReadMe.com, et nous fournissons de la documentation d’API, des SDK, etc.
    Je ne sais pas exactement pourquoi nous avons réussi, mais j’ai moi aussi connu énormément de faux départs et j’ai itéré petit à petit sur l’idée centrale jusqu’à atteindre un point où les gens manifestaient clairement de l’enthousiasme
    Comme je savais que ce marché était difficile, j’ai consacré beaucoup de temps et d’efforts à des choses qui ne relevaient pas de l’ingénierie, et Hacker News a toujours été bienveillant envers nous, surtout quand nous nous montrions plus francs
    J’ai envie d’en savoir plus, donc je vais essayer de le contacter en privé
    Dans l’ensemble, félicitations pour tous les efforts investis. Lancer une entreprise et croire en soi est incroyablement difficile, et il peut en être fier

    • Si ReadMe a mieux réussi que Konfig, c’est peut-être parce qu’il a commencé 8 ans plus tôt. Konfig était une bonne idée et l’exécution était bonne, mais le timing n’était peut-être tout simplement pas le bon
    • Tant que j’y suis, l’effet de transition CSS de l’écran de connexion de ReadMe reste pour moi l’un des éléments de branding les plus marquants dont je me souvienne. Qui que ce soit qui l’ait imaginé, c’était vraiment excellent

  • Je pense qu’on va voir beaucoup ce genre de résultat dans un avenir proche. Avec l’éclatement de la bulle IA, des histoires similaires vont se répéter

    • J’aurais davantage respecté cet effort si cela avait été formulé ainsi
      « Nous pensions pouvoir utiliser l’IA générative dans un produit SaaS B2B vertical pour résoudre des problèmes auparavant insolubles, et nous avons essayé. Nous avons conçu et proposé plusieurs idées, mais la réaction des utilisateurs n’a pas été suffisamment positive pour nous convaincre que c’était la bonne direction pour bâtir une énorme entreprise. »
      Tel quel, le texte donne comme première impression : « la personne qui a écrit ça est profondément immergée dans une culture de mode passagère et étroite, ce qui provoque un rejet instinctif, et même juste après un échec complet, elle n’arrive pas psychologiquement à s’en détacher »
    • Ouvrir le code en open source et abandonner, c’est le pivot IA ultime. Les nouveaux modèles apprendront de ce que vous avez fait et, un jour, le feront mieux

  • Ce n’est pas la première histoire d’un produit qui ne trouvait pas vraiment son adéquation, a cherché une direction de pivot, a pris l’IA comme réponse et a échoué
    Je l’ai déjà dit, mais cela vaut la peine de le répéter. Quand nous comprendrons ce que l’IA sait bien faire et ce qu’elle ne sait pas faire, nous commencerons à la traiter comme un outil plutôt que comme un objectif, et la génération d’idées de produits se stabilisera

    • Nous le savons déjà. L’IA est douée pour inventer du contenu plausible, et faible pour produire des résultats qui résistent aux faits ou à la vérification
    • Le produit lui-même était correct. J’étais dans une startup qui payait volontiers pour ce produit qui générait des SDK à partir de spécifications OpenAPI, et qui en tirait beaucoup de valeur
      Donc je ne pense pas que le problème ici ait été l’adéquation produit-marché
    • Cela veut-il dire que l’IA ne peut pas sauver une mauvaise idée de produit en automatisant quelque chose ? Du genre : faire plus efficacement quelque chose que personne ne veut, ce n’est pas une entreprise
    • Le concept d’API devrait disparaître, et il faudrait simplement que les IA se parlent entre elles en langage naturel

  • Je ne sais pas trop comment interpréter ça. D’un côté, je salue l’introspection, le fait d’affronter des vérités qui dérangent, et la création d’un ensemble d’outils assez large.
    Mais quand on regarde à l’intérieur, ce sont des outils qui enveloppent des outils. L’outil de classification d’API semble déléguer une bonne partie du travail lourd à OpenAI.
    « Vous êtes un classificateur de tout premier rang mondial. Faites correspondre ces API à l’un de ces groupes. »
    Le reste des fichiers, c’est du code de câblage et des frontières modèle-vue-contrôleur un peu floues. J’ai aussi vu des tests, et je me suis dit que c’était important pour des wrappers d’outils soumis à beaucoup de changements hors de leur contrôle ; mais en pratique, c’était surtout du niveau des tests fonctionnels contextLoads() fournis par défaut par IntelliJ, qui vérifient que les dépendances sont là et que la compilation ne casse pas.
    Il y a une vision, et elle est alignée avec le principe de Pareto, mais en validant l’hypothèse selon laquelle le marché n’a pas envie de maintenir ses propres outils, on a l’impression qu’en interne ils n’ont même pas réussi à résoudre leur propre problème de maintenance.
    S’ils avaient d’abord réussi à résoudre ce problème pour eux-mêmes, ils auraient peut-être pu le résoudre pour les autres ; mais cela ressemble à un dilemme : pour ressentir la douleur et comprendre les utilisateurs finaux, il faut avoir un produit réellement utilisé.

  • Une startup qui échoue n’a pas à en avoir honte. La plupart d’entre nous n’ont même pas le courage d’essayer.
    Il ne faut pas s’attendre à un grand intérêt pour le code. La valeur du code d’une entreprise sans le business ni les personnes qui vont avec est assez négative, sauf s’il contient une arme secrète technique particulière.
    Même s’il y a une partie techniquement impressionnante, les gens voudront probablement seulement comprendre comment cette partie fonctionne, pas utiliser le code lui-même.

    • Je suis le fondateur de Konfig. Je suis d’accord à 100 %. Je ne recommanderais à personne d’essayer de déchiffrer Konfig et de le déployer soi-même.
      Cela dit, un client a réussi à auto-héberger notre plateforme de documentation pendant qu’il cherchait comment gérer les conséquences de l’arrêt de Konfig.
    • Après avoir fait plusieurs startups de moins en moins ratées, voici ce que j’ai appris à la dure.
      Il ne faut pas créer une startup tech si l’on n’a pas soit un plan d’affaires capable de générer rapidement du chiffre d’affaires, soit un énorme financement. En général, il est difficile de lever des fonds si l’on n’a pas au minimum une intuition de la direction que prendra l’activité, et les profils techniques ne comprennent généralement pas assez bien l’aspect business.
      La plupart des entreprises ne sont pas des startups, ce sont simplement des entreprises. Elles ont du chiffre d’affaires et paient des factures. Une startup, c’est une entreprise qui vit avec du temps et de l’argent empruntés, sans chiffre d’affaires ; et surtout si cet argent est le vôtre, il vous faut un plan.
      La plupart des entreprises financées par du capital-risque échouent. Le travail du capital-risque est de faire échouer rapidement les entreprises qui vont échouer, et de faire vivre son propre business grâce à la minorité de sociétés qui n’échouent pas et connaissent une croissance explosive. « Accélération » ou « levée de fonds » ne signifie pas que vous êtes sur la voie du succès ; cela signifie que vous êtes monté sur une case où il faut battre les probabilités, et qu’il ne vous reste pas beaucoup de temps.
      Une entreprise prospère qui génère du chiffre d’affaires n’a pas besoin de capital-risque. Dans ce cas, il faut se demander pourquoi vous leur parlez. Si générer du chiffre d’affaires est difficile, le capital-risque ne réglera pas ce problème.
      Beaucoup de VC sont paresseux et ne s’intéressent à vous qu’une fois que vous avez déjà réussi. Cela crée une dynamique étrange où les entreprises financées tôt échouent, tandis que celles qui n’obtiennent pas de financement réussissent.
      Mon entreprise actuelle fonctionne entièrement en bootstrapping depuis quatre ans. Nous galérons sur le chiffre d’affaires, nous casons le travail dans le temps disponible, et je vis surtout de missions de conseil à côté. L’entreprise a connu ses trois meilleures années consécutives, et nous approchons du point où je pourrai bientôt arrêter le conseil pour me concentrer sur l’activité, mais le chemin a été long.
      Pour l’open source, je publie ce qui n’est pas du code spécifique au business ni de la propriété intellectuelle cœur. Une grande raison est que je n’ai pas envie de reconstruire les mêmes corvées quand je lancerai la prochaine entreprise. J’ai vu à quel point ces choses peuvent ralentir.
      Beaucoup de gens en startup sont obsédés par la propriété intellectuelle, mais en réalité, la majeure partie du logiciel n’a pas une telle valeur. Cela dit, le produire consomme tout de même du temps, de l’argent et de l’énergie.
      C’est pourquoi je publie beaucoup d’outils, de frameworks, etc., dont je serai le principal utilisateur. C’est pour continuer à les utiliser dans les projets suivants.

  • Le dépôt de code en lui-même peut être intéressant, mais il ne semble pas y avoir de licence. Avec une vraie licence open source, ce serait beaucoup plus utile.

    • Environ une heure après ce commentaire, un fichier MIT LICENSE a été ajouté.

  • Le marché des outils pour développeurs est vraiment difficile.
    Presque toutes les décisions d’architecture deviennent : « Quel outil open source puis-je utiliser pour résoudre ce problème ? »
    Personne n’a envie de payer, et ce n’est pas grave.

    • C’est vrai, mais la plupart des développeurs perçoivent très peu les problèmes en dehors de ceux qu’ils rencontrent eux-mêmes, et ces problèmes sont généralement des problèmes d’outillage développeur.
      Du coup, alors qu’il existe d’énormes besoins dans d’autres domaines, beaucoup d’entreprises se mettent à créer des startups d’outils pour développeurs.
      S’il existait, pour des développeurs expérimentés qui veulent lancer quelque chose, un moyen autre que le hasard et le networking de trouver des personnes ayant un problème, une expertise métier et l’envie de créer une entreprise, cela pourrait libérer beaucoup de valeur.
    • Vendre des outils aux développeurs est difficile. Il faut concurrencer une multitude d’outils open source qui s’adaptent et évoluent en permanence, et les bonnes idées sont rapidement absorbées et copiées.
      C’est pourquoi la plupart des outils commerciaux ont une durée de vie limitée en termes d’utilité, et restent généralement dans la catégorie « sympa à avoir ».
      En plus, beaucoup de développeurs sont salariés et n’ont pas de budget personnel pour leurs outils. Le marché se réduit en pratique aux développeurs freelances ou aux managers qui emploient des développeurs.
      Les managers d’équipe examinent ce type de dépense de près et n’ont généralement pas beaucoup de budget. Dans la plupart des entreprises, il n’existe pas de budget individuel d’outillage pour les développeurs.
      Les freelances utilisent aussi le plus souvent les outils de l’entreprise qui les paie, et ce sont généralement des outils gratuits. Les outils payants obligent en plus à gérer les licences des contractuels, ce qui complique l’usage de freelances. Ils ont donc tendance à éviter ce genre d’outils pour garder les choses simples.
    • Plus largement, les outils pour développeurs sont trompeusement difficiles. Il est facile de croire que créer des outils pour développeurs est une formule gagnante pour une entreprise ou une startup. Parce qu’on est soi-même développeur, et qu’on a probablement identifié un problème qu’on a rencontré dans le passé.
      On sait aussi où les développeurs se rassemblent et ce qui fonctionne auprès d’eux, donc tout semble bien se présenter.
      Mais comme cela a été dit, beaucoup de développeurs ne veulent pas payer, et chercheront une solution open source qui fait le travail nécessaire, même si elle est un peu moins confortable. Et comme on s’adresse à des gens dont le métier et la vie consistent à fabriquer du logiciel, la réponse peut aussi être : « je vais juste le construire moi-même ».
    • Ce n’est pas entièrement vrai. Mais je n’ai pas envie de perdre du temps à traiter 50 factures de 10 dollars.
      Il n’existe pas un business qui regroupe plusieurs services sur une seule facture ? Ou faut-il toujours passer par AWS, Azure, GCloud ?