PdgCeo Blog

Passage d’un enregistreur à distance interne à 9 000 €/mois

Bugfender est un outil qui aide les développeurs à déboguer leurs applications mobiles en collectant les journaux des appareils mobiles de leurs utilisateurs. Il s’agissait au départ d’un outil interne, mais Jordi et son cofondateur ont vu un grand potentiel et ont décidé d’en faire une activité secondaire. Ils ont maintenant 165 clients payants, ce qui représente un RMM de + 9 100 €/mois. Découvrez comment ils ont construit et développé Bugfender et les erreurs qu’ils ont commises.

Bonjour Jordi ! Quel est ton parcours, et sur quoi travailles-tu actuellement ?

Salut ! Je m’appelle Jordi Giménez. Il était une fois, j’ai étudié l’informatique à Barcelone, ce qui m’a conduit à des emplois dans le back-end web, le front-end web, la sécurité informatique, etc. Plus récemment, mon chemin m’a conduit au développement iOS et Android. J’adore Barcelone, et j’ai eu la chance d’y cofonder deux entreprises, Mobile Jazz et Bugfender.

Outre Mobile Jazz et Bugfender, nous menons également des expériences telles que Localname, un service permettant de donner à votre machine de développement locale une URL accessible depuis Internet, et DevCraft, un bulletin d’information destiné au développeur curieux. Nous les testons tous les deux et ils pourraient ou non devenir « quelque chose » à terme.

Bugfender est un outil qui aide les développeurs à déboguer leurs applications mobiles en collectant les journaux des appareils mobiles de leurs utilisateurs, où qu’ils soient dans le monde. Nous récupérons les journaux et les rassemblons dans une interface claire, où vous pouvez filtrer et visualiser les données par utilisateur, par période, par marque et modèle d’appareil mobile, etc. Certains lecteurs connaissent peut-être les outils de signalement des accidents ; Bugfender va plus loin en permettant un accès à distance aux fonctions de journalisation des appareils des utilisateurs.

Nous avons démarré la société avec seulement 3 employés, mais aujourd’hui nous sommes une équipe de 9 personnes. Bugfender est aujourd’hui installé sur plus de 9000 applications et fonctionne sur plus de 46 millions d’appareils. Nous sommes passés de zéro à 11 000 dollars de revenus mensuels récurrents (MRR) en 4 ans, sans aucun investissement extérieur.

Je fais un peu de tout dans l’entreprise : de la gestion de projet au développement back-end et iOS, en passant par les ventes, le support client, la mise en place de campagnes publicitaires en ligne et la rédaction de contenu pour notre blog. Chaque jour est un peu différent.

Comme vous pouvez le constater, tout ce que nous faisons est amorcé. En tant que fondateurs, nous sommes les seuls investisseurs ; notre investissement consiste en notre temps, et non en une tonne d’argent. Cela a un impact sur la façon dont nous gérons l’entreprise : Après quatre ans, notre équipe ne compte plus que neuf personnes, dont certaines à temps partiel, et nous faisons très attention à nos budgets. Par exemple, lorsque nous mettons en place une campagne publicitaire, notre objectif est de créer un produit utile pour lequel les gens sont prêts à payer. Nos publicités sont parfois un peu déroutantes pour les clients potentiels, car de nos jours, beaucoup de choses sont « gratuites » dans le sens où elles ne coûtent rien. Mais même avec ces produits SaaS « gratuits », les consommateurs doivent savoir qu’ils paient toujours d’une manière cachée, par exemple en étant ciblés par des publicités et en voyant leurs données vendues au plus offrant.

En revanche, nous recherchons des clients honnêtes qui apprécient ce que nous offrons et sont prêts à payer pour cela. Heureusement, il y a suffisamment de ces personnes pour que nous soyons sur le point d’atteindre le seuil de rentabilité. Nous aurions déjà pu atteindre le seuil de rentabilité si nous avions cessé d’investir dans l’entreprise, mais nous avons choisi de continuer à investir au-dessus de nos revenus, même si cela affecte légèrement nos finances pour l’instant. Nous sommes très ouverts avec nos chiffres, vous pouvez les consulter en temps réel ici.

Un autre fait amusant est que l’entreprise est totalement délocalisée. Je suis basé à Barcelone, mais notre équipe est répartie dans toute l’Europe. Nous travaillons à distance et organisons des retraites ou des « workations » de temps en temps. Très tôt, nous avons compris que se rencontrer en face-à-face était essentiel pour la productivité et la cohésion de l’équipe. De plus, c’est vraiment amusant.

Les 3 fondateurs de BugFenders

Quelle est votre histoire et comment avez-vous eu l’idée ?

J’ai personnellement commencé le développement mobile en 2011. À l’époque, je développais ma toute première application mobile pour Android : une application pour vérifier le solde de ma carte SIM prépayée. C’était une expérience pour moi, et je voulais juste apprendre à connaître Android. Mon opérateur de téléphonie mobile n’avait pas d’application et cela m’ennuyait de devoir vérifier sans cesse sur son site web que mon crédit n’était pas épuisé.

J’ai donc créé une application qui utilise le « web scraping » pour récupérer mon solde sur le site web. (Le « web scraping » utilise une application pour se connecter à un navigateur web comme un véritable utilisateur, cliquer sur les boutons appropriés pour atteindre l’écran contenant les informations que vous souhaitez, puis extraire ou « scrapper » les informations pour votre usage).

Cela a très bien fonctionné pour moi. Comme l’opérateur n’avait pas d’application, j’ai décidé de la rendre publique, au cas où elle serait utile à quelqu’un d’autre. Il s’est avéré que c’était le cas. En quelques mois, elle a recueilli plus de 20 000 utilisateurs, ce qui représentait un pourcentage élevé des clients de l’opérateur à l’époque.

Widget

Mais le problème avec le web scraping est que, contrairement aux humains, les applications peuvent être déstabilisées par des changements de routine dans la formulation ou la structure des informations présentées. Par exemple, à l’époque, mon application était utilisée à la fois par des utilisateurs de cartes prépayées et des utilisateurs de cartes contractuelles, de sorte que le site Web était légèrement différent pour chaque type d’utilisateur en fonction du produit – suffisamment différent pour casser mon application.

Pour résoudre ce problème, j’ai décidé de créer un petit service Web auquel mon application pourrait envoyer les données s’il s’avérait que le contenu ne correspondait pas à ses attentes. De cette façon, je pouvais voir ce que mon application voyait et corriger les erreurs potentielles. C’était la toute première version de Bugfender. Mais à l’époque, elle n’avait aucun impact sur moi, c’était juste une solution que j’avais trouvée à un problème spécifique auquel je faisais face à ce moment-là.

Peu de temps après, j’ai rencontré Stefan dans le cadre d’une mission de conseil en applications mobiles. Ensemble, nous avons fondé Mobile Jazz, une agence de conseil en logiciels. Chez Mobile Jazz, nous aidons nos clients à travailler sur leurs idées, puis nous nous chargeons des spécifications et de la conception pour transformer les idées en applications web et mobiles vivantes.

C’est dans le cadre de Mobile Jazz que l’idée de Bugfender est née en 2015. Alors qu’il travaillait sur le projet d’un client, un collègue, Aleix, a de nouveau rencontré le même problème. Il avait une situation où notre application mobile interagissait avec un serveur hors de notre contrôle et l’un de nos bêta-testeurs se plaignait que l’application ne fonctionnait pas pour lui. Mais elle fonctionnait pour nous ! Comme nous ne pouvions pas voir son téléphone ni le serveur, nous étions laissés dans l’ignorance totale. Et encore une fois, Aleix a proposé la même solution : construire un outil pour envoyer tous les logs vers un serveur. Aleix était si enthousiaste à l’idée qu’il l’a bricolé à la hâte pendant le week-end et nous l’a montré fièrement le lundi suivant.

Tableau de bord

J’étais choqué. Confrontés au même problème, nous avions tous deux trouvé la même solution. Cela m’a confirmé que nous étions sur une piste. C’était forcément quelque chose !

Comment avez-vous construit Bugfender ?

Immédiatement après avoir vu la démo d’Aleix, je lui ai parlé. Je me souviens que j’étais très excité car j’avais le même problème et j’avais écrit exactement la même solution 4 ans plus tôt et je voulais travailler avec lui sur ce projet. Stefan l’a également aimée, alors nous avons convenu de construire tous les trois une meilleure version et de l’utiliser comme outil interne pour Mobile Jazz.

À l’époque, il n’avait même pas encore de nom, c’était juste une expérience. Nous l’avons appelé « enregistreur à distance » parce qu’il envoie les journaux à distance.

Lorsqu’Aleix a construit la toute première version, le code ajouté aux applications mobiles était une simple classe que nous avons bricolée et qui envoyait les journaux au serveur. Il ne s’agissait en aucun cas d’un véritable kit de développement logiciel (SDK), mais simplement d’un morceau de code que nous avons copié-collé dans le code de projets individuels. Le serveur était complètement stupide – il stockait simplement tout ce qui lui était envoyé. Dans l’ensemble, il n’y avait probablement pas plus de 200 lignes de code.

La première version que nous avons construite avec Go était une expérience (une expérience dans une expérience !) qui écrivait les journaux dans une base de données MySQL.

Mais, même si elle était grossière, elle nous aidait déjà ! Maintenant, si un client avait un problème, nous pourrions faire une version spéciale de l’application avec ce « logger à distance » intégré. Il enverrait alors les journaux et nous pourrions voir ce qui se passe. Hourra !

Nous avons rapidement compris qu’il serait préférable d’inclure le code du « logger à distance » dans toutes les versions de l’application et d’activer/désactiver la journalisation à distance lorsque nous savions qu’il y avait un problème avec un appareil. C’était la première évolution que nous avons faite.

Ensuite, l’évolution s’est poursuivie. Au départ, l’outil n’était qu’un moyen de fournir un meilleur service à nos clients de Mobile Jazz, mais nous avons rapidement constaté que d’autres fabricants d’applications se heurtaient au même problème. Dans le développement mobile, il y a toujours ce problème : lorsqu’un utilisateur rencontre un problème, il est presque impossible de le reproduire, contrairement au web ou au bureau. Dans ces technologies, vous pouvez toujours vérifier les journaux sur le serveur ou l’ordinateur de bureau. Ce n’est pas le cas avec le mobile.

Dans le domaine de la téléphonie mobile, il arrive que les applications fonctionnent sans serveur, qu’elles interagissent avec des serveurs qui ne sont pas sous votre contrôle ou qu’elles interagissent avec des périphériques Bluetooth ou Wifi, de sorte que vous n’avez aucun moyen de savoir ce qui se passe. Un autre problème est celui de la « fragmentation des appareils ». Il existe tellement de téléphones mobiles différents sur le marché que vous auriez littéralement besoin de milliers d’entre eux pour tester correctement votre application. Même avec exactement la même configuration et les mêmes conditions, il se peut que quelque chose qui fonctionne pour vous ne fonctionne pas pour quelqu’un qui a un téléphone mobile différent.

Après 5 mois d’utilisation de Bugfender en interne, il était clair pour nous que nous étions confrontés à un problème universel pour lequel d’autres entreprises seraient prêtes à payer. Nous avons donc entrepris de faire de Bugfender un produit. Tout d’abord, nous avons créé un site web et y avons ajouté un formulaire de « demande d’invitation ». Au début, nous ne faisions rien payer et nous devions aller dans la base de données et créer les comptes à la main. Nous n’avions même pas de formulaire d’inscription approprié. Ce n’était pas une tâche ennuyeuse car très peu de personnes demandaient un accès. Nous avons essayé de promouvoir notre outil dans les forums de développeurs et sur Twitter, mais nous avons obtenu très peu de réponses.

ladingpage

Cependant, le fait de travailler avec de vrais utilisateurs nous a aidés. Nous avons commencé à recevoir les premiers retours impartiaux, critiques et demandes de fonctionnalités.

Il nous a fallu environ 4 mois pour ajouter le processus de paiement, car nous étions heureux de continuer à intégrer les commentaires et d’améliorer notre outil avant de commencer à facturer. Nous n’avons pas beaucoup réfléchi à la tarification, car notre objectif était d’abord de savoir si les gens étaient prêts à payer quelque chose, quel que soit le montant. Nous nous sommes donc rendus sur le site d’un concurrent et avons établi notre tarification de manière similaire.

Une fois le processus de paiement prêt, il nous a fallu encore 6 mois pour obtenir notre premier utilisateur payant. Ces périodes ont été un peu difficiles, mais nous étions pleins d’enthousiasme. Quand le moment est arrivé, nous avons fêté ça. Un utilisateur payant signifiait que nous n’étions pas complètement stupides, que nous construisions quelque chose que quelqu’un voulait, même s’il ne payait que 19€/mois.

Historique

Une fois que vous commencez à faire payer, les choses deviennent plus sérieuses. Devons-nous nous constituer en société ? Les gens ont commencé à poser des questions auxquelles nous devons répondre : Quelle est notre politique de confidentialité ? Nos conditions de service ? Avons-nous crypté leurs données ? (Bien sûr, nous le faisons.)

Nous avons également eu beaucoup de doutes en cours de route : avions-nous trouvé la bonne adéquation « produit-marché » ? Il était assez clair pour nous que l’argent n’allait pas simplement affluer. C’était un produit de niche. Il a vraiment « gratté une démangeaison » pour les développeurs, mais nous nous demandions encore si Bugfender répondait vraiment à un problème majeur ou non. Pouvions-nous convaincre suffisamment de personnes de prendre leur carte de crédit et de l’investir ?

Incorporer une société, ajouter des métriques dans le logiciel pour limiter les fonctionnalités en fonction des plans, ajouter le processus de paiement et de facturation… (OMG si vous êtes quelqu’un d’influent dans l’Union européenne et que vous lisez ceci, calculer la bonne TVA pour une facture est ridiculement complexe !!!) Était-il judicieux de déployer tous ces efforts, peut-être sans rien obtenir en retour… jamais ?

Nous avons eu des hauts et des bas dans le processus de lancement et dans les mois qui ont suivi. L’obtention de notre premier utilisateur payant a été un moment de célébration. Même s’il s’agissait de peu d’argent, cela a apporté une validation. Un autre moment passionnant a été la candidature à une subvention de l’UE, qui a été sélectionnée parmi des centaines de candidats. Nous avons reçu 100 000 euros pour le développement de notre produit, ce qui signifie que nous n’aurions plus besoin de le développer avec notre propre argent. Je me souviens qu’avec les autres fondateurs, je parlais d’abandonner le navire quelques semaines auparavant.

Twitter

Ce qui nous a également encouragés à continuer, c’est le retour d’information direct de nos utilisateurs via le chat. Le chat a eu un grand impact sur l’adoption car nous pouvions parler aux utilisateurs potentiels et répondre à leurs préoccupations. Nous avons pu aider nos utilisateurs existants, ce qui a permis de les fidéliser. C’était également une opportunité inestimable pour nous, car nous pouvions apprendre directement des personnes qui utilisaient le produit. Cela nous a aidés à créer un site Web qui répond aux questions réelles des utilisateurs.

Quelles ont été vos stratégies de marketing pour développer votre entreprise ?

Notre croissance a été très organique depuis le début. Nous savions que nous pouvions construire le produit sans problème, mais nous n’avions aucune connaissance en matière de marketing. Le plus difficile a été d’atteindre les bonnes personnes pour leur faire connaître notre produit.

Après avoir obtenu la subvention de l’UE, nous avons eu un mentor (bonjour Agustín !) qui a insisté sur le fait que nous devions faire du marketing de contenu. Mais qu’est-ce que c’était ? Nous n’en savions pas grand-chose. Il nous a fait faire un exercice : il nous a demandé de faire une recherche de mots-clés et nous a donné quelques conseils. Nous avons ensuite choisi les 20 mots clés qui, selon nous, auraient le plus d’impact sur notre croissance et nous nous sommes mis au travail sur ces mots. Notre objectif était d’apparaître sur la première page de Google après 6 mois pour au moins 10 de ces mots-clés.

C’est plus facile à dire qu’à faire – améliorer le référencement demande beaucoup de travail ! Les trois fondateurs de Bugfender étaient des ingénieurs. À ce moment-là, c’était toute notre équipe. Les ingénieurs ne sont pas très portés sur l’écriture, et cela demandait de l’écriture, beaucoup d’écriture. Donc, c’était un exploit doublement difficile pour un ingénieur. Mais nous nous sommes mis au travail et nous avons réussi. Non seulement nous sommes apparus sur la première page de bon nombre de nos recherches par mots clés, mais nous avons même atteint la première place pour certaines d’entre elles. Cela a grandement contribué à notre croissance car, pour la première fois, nous avons eu une quantité significative de trafic organique sur notre site.

Nous avons également essayé d’autres choses qui n’ont pas fonctionné. D’autres mentors nous ont recommandé AdWords, les publicités Facebook, LinkedIn et Twitter. Toutes ces options nous paraissaient sensées, alors nous les avons essayées. Nous avons consacré beaucoup de temps et d’argent à tout mettre en place, à payer facture après facture, à tester et à pivoter. Bien que nous ayons obtenu plus de visiteurs, nous dépensions toujours beaucoup plus que ce que nous gagnions en nouveaux utilisateurs et, en fin de compte, en achats. Je dirais que cela valait la peine d’essayer, mais je recommande aux entreprises qui démarrent d’essayer d’autres choses d’abord et d’être très prudentes avec les dépenses publicitaires. Lorsque vous utilisez des publicités, vous êtes en concurrence avec de grandes entreprises disposant d’énormes budgets marketing. Je réserverais cette stratégie aux entreprises financées par du capital-risque qui ont une faible barrière à l’acquisition de clients, comme des produits gratuits.

Nous avons eu une bonne expérience avec le reciblage Facebook. Nous montrons des publicités aux personnes qui ont exprimé un certain intérêt pour Bugfender en visitant notre site web à un moment donné. Cette stratégie s’est avérée beaucoup plus fructueuse, puisque nous ciblons des individus plutôt que de grands groupes, avec une chance beaucoup plus grande de les transformer en clients.

Nous pensions également que nos clients seraient si enthousiastes à l’idée d’utiliser Bugfender qu’ils le partageraient. Nous avons construit tout un système de parrainage avec des codes promotionnels et des invitations, similaire à la stratégie utilisée par Dropbox, qui est bien connue. Nous avions tort, les gens avaient mieux à faire. Ils étaient heureux d’utiliser notre produit, mais convaincre leurs amis de l’utiliser était une autre paire de manches.

Nous avons également essayé de participer aux réseaux sociaux : Twitter, Facebook et LinkedIn, mais nous avons constaté qu’ils sont déjà trop remplis de messages marketing. Avoir une interaction significative prend énormément de temps et, au final, tout le monde essaie les mêmes trucs, il est donc très difficile de se démarquer. Cependant, nous avons récemment constaté que le fait d’être plus actif sur Twitter nous a aidés, probablement parce que les développeurs y sont plus présents.

Nous avons également essayé les tests A/B pour améliorer le contenu de notre site web. Même si, en théorie, cela semble bien, il faut plusieurs milliers de visiteurs sur votre site web pour obtenir des résultats significatifs. Et souvent, ces tests ne sont pas concluants, simplement parce qu’il n’y a pas beaucoup de différence entre les choses que vous avez essayées, ou parce que l’impact sur votre taux de conversion est si minime qu’il n’a pas d’importance. 

Donc, pour l’instant, nous savons que le marketing de contenu est notre cheval de bataille et nous continuons à y travailler. Mais nous n’avons pas cessé d’essayer de nouvelles choses et nous continuerons à essaye  ; nous ne nous arrêterons probablement jamais, car les temps changent et les entreprises évoluent. Peut-être que certaines choses que nous avons essayées dans le passé pourraient éventuellement fonctionner à l’avenir.

Quels ont été les plus grands défis que vous avez rencontrés et les obstacles que vous avez surmontés ?

J’ai déjà mentionné certains des hauts et des bas émotionnels. Le plus grand défi jusqu’à présent a été le manque d’argent. Nous gérons tout avec notre temps et notre argent, et cela devient de plus en plus difficile. Pendant les périodes creuses, on peut vraiment commencer à se demander si cela vaut la peine de continuer. Nous sommes sur le point d’atteindre le seuil de rentabilité, donc l’investissement est rentabilisé lentement, mais il fonctionne ! 

Nous sommes maintenant dans une situation de rentabilité, ce qui signifie que nous pouvons payer nos dépenses, mais nous ne pouvons pas nous permettre de nous verser un salaire. Pourtant, nous n’avons pas besoin de continuer à mettre de l’argent, ce qui est bien, mais nous devons travailler gratuitement. J’espère que nous atteindrons bientôt ce que l’on appelle la « rentabilité du ramen », où nous pourrons être payés, même si ce n’est qu’un petit peu, ce qui ne fera peut-être pas une grande différence mais nous aidera certainement à nous remonter le moral.

Nous avons surmonté cette limitation pour l’instant en partageant notre temps entre Bugfender et le travail de consultant (pour Mobile Jazz). Ce n’est pas idéal mais cela fonctionne, même si cela a été extrêmement difficile.

Quels sont vos plus grands inconvénients ?

Bonne question 🙂 Il est très difficile de parler des inconvénients, d’abord parce que nous ne voulons pas les voir, ensuite parce qu’à mon avis, beaucoup d’avantages et d’inconvénients sont les deux faces d’une même pièce. Ainsi, ils vous définissent, mais ils ne déterminent pas votre destin. Laissez-moi vous expliquer :

On pourrait dire que le fait d’être « bootstrapped » est une faiblesse, par exemple. Pourtant, je continue de penser que c’est un avantage si nous parvenons à rendre l’entreprise rentable – et selon toute vraisemblance, nous y parviendrons. Le manque de ressources abondantes nous a rendus sages (ou nous a aidés à « rester affamés » comme dirait Steve Jobs), et nous sommes capables de faire fonctionner l’entreprise avec peu de revenus chaque mois. Le fait d’être bootstrapped nous a donc rendus frugaux et c’est une excellente chose ! Nous sommes malheureusement trop habitués à voir des entreprises faire faillite parce qu’elles ont épuisé tous leurs fonds.

Une autre caractéristique de Bugfender est qu’il s’agit d’un produit payant. Nous avons une version gratuite pour les tests, mais les « bonnes choses » sont réservées aux clients payants. Encore une fois, c’est une faiblesse, car si demain un Google/Facebook/Twitter vient et fait une version gratuite de quelque chose de similaire à Bugfender… nous pourrions avoir du mal. Encore une fois, l’inconvénient est très clair, mais quel est l’avantage ? Vous connaissez le dicton « Si vous ne payez pas, vous n’êtes pas le client ; vous êtes le produit vendu » ? Nous avons une idée précise de qui sont nos clients et nous leur assurons la confidentialité. C’est quelque chose qu’aucun produit gratuit ne peut fournir.

De plus, j’ai mentionné que notre marché cible était les développeurs mobiles. Cela signifie essentiellement que nous travaillons dans un écosystème contrôlé par Apple et Google. Il y a certainement beaucoup d’argent à la clé, mais le risque de dépendre de la règle de ces deux sociétés n’est pas marginal. Je dirais que c’est vrai pour toute personne travaillant sur une application ou sur un produit pour applications. La seule solution à ce problème est de garder ce risque à l’esprit et de se diversifier dès que possible.

Au cours du processus de construction et de développement de Bugfender, quelles ont été les pires erreurs que vous avez commise ?

Sur un plan personnel, je sais que je suis trop pessimiste. Je dois faire attention à la façon dont je formule les choses ou dont j’exprime mes sentiments avec l’équipe, car je pourrais nuire à leur moral. Heureusement, j’ai fait équipe avec les bonnes personnes et nous nous soutenons mutuellement lorsque les choses sont déséquilibrées. Cela a très bien fonctionné jusqu’à présent.

En tant qu’équipe, j’ai mentionné que tous ceux qui travaillent sur Bugfender travaillent également sur Mobile Jazz, principalement pour des raisons économiques. Nous aurions peut-être pu prendre plus tôt la décision d’engager quelqu’un de complètement externe, qui travaillerait à plein temps sur Bugfender. Je pense que lemultitâches nous a fait rater de bonnes opportunités

De plus, en tant que société, je pense que nous n’avons pas encore suffisamment expérimenté la tarification. Nous avons une tarification basée sur certaines hypothèses mais nous n’avons pas beaucoup testé. Par exemple, nous avons actuellement un plan gratuit qui, selon nous, permet aux gens d’essayer Bugfender sans crainte. Cependant, comment le fait de changer le plan gratuit pour un plan d’essai fonctionnerait-il ? Nous ne le savons pas.

Sur le plan technologique, nous avons également commis des erreurs. Travailler en Go semblait très attrayant au début, car nous étions désireux d’apprendre de nouvelles technologies, mais Go n’était pas mature à ce moment-là et nous en avons payé le prix. De plus, aujourd’hui encore, nous avons du mal à trouver des développeurs expérimentés.

Le choix des bibliothèques a également posé problème. Nous avons choisi martini comme framework web et il s’est avéré extrêmement peu performant ; même son auteur est passé à un nouveau projet appelé gin. L’abandon de Martini au profit de la bibliothèque HTTP native a permis d’améliorer les performances d’environ 10 fois, ce qui nous a permis d’économiser (ou, au cours des mois précédents, de perdre) des milliers de dollars, littéralement. Pour l’accès aux bases de données, nous utilisions gorm (version 1). Mais gorm a été en grande partie réécrit au cours des mois suivants, ce qui a donné lieu à une API incompatible avec la version que nous utilisons ; cela signifie principalement que nous devons réécrire notre code et effectuer une migration complète des données… nous allons probablement abandonner gorm et nous en tenir à sqlx, qui est une bibliothèque largement utilisée et qui nous donne un meilleur contrôle sur les performances. Je suppose que tout ceci est le reflet de l’évolution du langage à mesure que la communauté des développeurs mûrit.

Nous avons écrit un article de blog sur Go et le choix des bibliothèques, en énumérant tous les avantages et les inconvénients – peut-être que cela pourrait aider d’autres personnes à faire de meilleurs choix la prochaine fois.

De même, nous avons naturellement dû faire évoluer le système primitif basé sur MySQL. Les bases de données relationnelles ne sont pas adaptées aux charges de travail lourdes en écriture, comme le stockage des journaux. Nous avons évolué vers une configuration plus complexe avec MySQL uniquement pour certaines données, puis en utilisant Kafka et Elasticsearch principalement pour le stockage des journaux, avec l’aide de Redis pour la mise en cache des données les plus couramment consultées.

Si vous aviez la possibilité de faire les choses différemment, que changeriez-vous ?

J’engagerais une personne chargée du marketing dès le début. Nous avons complètement sous-estimé la quantité d’efforts que notre marketing allait nécessiter. Nous pensions que quelques publicités et quelques articles de blog suffiraient à faire connaître notre entreprise. Si j’avais la possibilité de revenir en arrière, je chercherais quelqu’un qui travaille dans le domaine du marketing dans notre secteur et je l’engagerais immédiatement, dès que l’argent le permettrait.

Après un certain temps, on y voit plus clair. Bien sûr, si nous avions su que le placement d’annonces ne fonctionnait pas, nous aurions dépensé beaucoup moins de temps et d’argent à essayer de les mettre en place. Trouver la bonne stratégie de marketing a été particulièrement chronophage, mais c’est un processus par lequel il faut passer.

J’aurais aimé passer plus de temps à parler à des clients potentiels. Après 3 ans d’activité, je trouve toujours des gens qui ne « comprennent » pas ce que nous faisons. Cela ne signifie pas qu’ils sont stupides, mais que je ne peux pas l’expliquer correctement (c’est donc moi qui suis stupide). J’essaie de parler beaucoup avec les clients et les clients potentiels, mais je pense toujours que plus de temps aurait permis d’obtenir de meilleurs résultats.

Avant de lancer Bugfender, nous avons également essayé un autre produit. Il s’appelait « PlayThis » et il s’agissait d’une liste de lecture collaborative pour choisir la musique que vous jouez dans une fête. Notre plan d’affaires était de le rendre gratuit ou bon marché pour les fêtes privées (par exemple, à la maison) et de le vendre aux bars. Nous avons construit le produit pendant quelques mois jusqu’à ce que nous ayons une version fonctionnelle sur l’app store. Savez-vous qui est allé visiter les bars pendant ce temps ? Personne ! Savez-vous combien de copies du logiciel nous avons vendues ? Aucun, jamais. Cela nous a appris une leçon précieuse : nous devons parler aux clients avant de construire quoi que ce soit.

Parce que je sais qu’il s’agit d’une courbe d’apprentissage importante et d’une erreur courante parmi les fondateurs, je tiens à insister : n’écrivez pas une seule ligne de code avant d’avoir quelqu’un qui soit prêt à payer pour cela.

C’est encore mieux si vous pouvez obtenir que quelqu’un paie à l’avance (ou au moins s’engage à acheter). En plus de financer votre projet, cela garantira qu’il dispose des éléments nécessaires et qu’il apporte une solution (au moins à une personne).

Et l’inverse est vrai : peu importe que votre technologie soit étonnante ou que votre idée soit bonne. Si personne ne la connaît, personne ne l’achètera. Une fois que vous aurez parlé à vos premiers clients potentiels, vous comprendrez qu’ils ont peut-être besoin de quelque chose de complètement différent de ce que vous aviez en tête, ou que ce que vous pensiez être une opportunité de marché inexplorée, s’avère n’intéresser personne.

Sur le plan technologique, j’aurais choisi une pile technologique bien connue dès le début. Cela n’aurait pas été aussi amusant, mais cela aurait permis d’accélérer le projet et nous aurions économisé de l’argent. Cela fait un moment que nous devons renforcer notre matériel à cause de logiciels peu performants, ce qui nous coûte des milliers de dollars chaque mois. En outre, nous gérons une charge de travail particulière, puisque nous écrivons des téraoctets de journaux chaque mois, mais en même temps, nous devons les rendre facilement disponibles pour qu’un utilisateur puisse les vérifier. Trouver un bon équilibre dans ces optimisations est complexe, surtout si vous n’êtes pas très à l’aise ou expérimenté avec la pile technologique.

En dehors des erreurs, quelles sont les autres sources d’apprentissage que vous recommanderiez aux entrepreneurs qui débutent ?

Tout le monde n’aime pas les mêmes médias, je vais donc recommander plusieurs choses qui ont fonctionné pour moi. J’aime la lecture, donc je recommande Le Mom Test. C’est un livre court et doux qui m’a beaucoup aidé dans le département « parler aux clients ». Je pense que tout entrepreneur devrait le lire avant de se lancer.

De même, le livre Start Small, Stay Small, le livre Lean Startup et le blog Signal v. Noise parlent de bootstrapping, c’est-à-dire de construire le projet avec son propre temps et son propre argent et de ne pas chercher à obtenir l’aide d’investisseurs, ou très peu. Tous les projets ne peuvent pas être construits de cette façon, mais beaucoup de gens ne connaissent pas cette alternative au financement par capital-risque. Je vous recommande donc d’en apprendre un peu plus et de voir ce qui convient le mieux à votre idée.

J’aime le podcast Smart Passive Income pour trouver des idées, la plupart d’entre elles étant également amorcées. C’est un format qui me donne beaucoup d’énergie. Le podcast Rework est une belle collection d’histoires de différents entrepreneurs pour en apprendre beaucoup sur l’entrepreneuriat. Je fréquente aussi régulièrement les forums Indie Hackers et Hacker News.

En ce qui concerne le marketing, j’ai également dû apprendre beaucoup de choses car je n’avais aucune connaissance dans ce domaine lorsque j’ai commencé. J’ai adoré le livre Traction : A Startup Guide to Getting Customers et j’écoute régulièrement le podcast de Neil Patel (il a aussi un blog et une newsletter).

Où peut-on aller pour en savoir plus ?

Vous devriez absolument consulter le site Web de Bugfender. Pour en savoir plus sur notre parcours, vous pouvez consulter Three Years of Bugfender : 9.5M Users, une récapitulation que nous avons faite pour notre troisième anniversaire, et Four Lessons Learned From Bootstrapping Products, quelques réflexions sur nos apprentissages.

Mon cofondateur Stefan Klumpp a également été interviewé dans Indie Hackers il y a six mois, où vous pouvez obtenir plus de détails sur nos débuts, notre financement et notre feuille de route.

Si vous voulez me contacter, je suis disponible sur Twitter à @bugfenderapp et @gimix3.

Encore plus de témoignages

Quitter mon emploi pour gagner 5k $/mois – projets perso

Fin 2018, Fabrizio et Franceso ont quitté leurs emplois à temps plein pour créer Superlinear et commencer à lancer des apps. Ils se concentrent actuellement sur leur SaaS récemment lancé, Mailbrew, qui permet aux utilisateurs de créer des condensés d’e-mails sur les choses qu’ils aiment. Mailbrew réalise actuellement un chiffre d’affaires de 2 000 dollars par mois.

Lire Plus »

Collecter 15 000 dollars pour une nouvelle marque de vêtements

Après avoir obtenu son diplôme, Paul est devenu le fondateur de SPUDS, une entreprise de vêtements de performance pour hommes basée dans la région de Californie. L’idée lui est venue lorsqu’il cherchait de nouveaux vêtements d’entraînement, mais n’était pas satisfait de tout ce qui existait sur le marché. Après de nombreux prototypes et tissus, ils se sont lancés sur Kickstarter et ont pu récolter 15 000 dollars.

Lire Plus »

D’un projet parallèle à une levée de fonds de 450 000 dollars.

Luke avait une idée : un outil qui aiderait les managers à communiquer avec les employés. Ce n’est que deux ans plus tard qu’il a commencé à y travailler. Il l’a gardé longtemps comme un projet secondaire, tout en le faisant croître jusqu’à + 10k$/mois. Récemment, Friday a levé 450 000 dollars dans le but de développer l’entreprise et de doubler son équipe.

Lire Plus »