Depuis le lancement de @AsideAI, on n’arrête pas de me demander pourquoi nous avons pivoté. J’en ai eu assez de répéter l’histoire, mais ce processus comptait tellement pour nous que j’ai voulu l’écrire.
TLDR; Aside est un navigateur IA qui réalise du vrai travail sur les sites que vous utilisez déjà. Il peut utiliser vos sessions de navigateur existantes, travailler dans les emails, tableaux de bord, outils internes, documents et feuilles de calcul, et continuer même quand une tâche prend des minutes ou des heures.
Avant YC
Nous sommes entrés chez Y Combinator à notre 7e tentative.
Avant YC, nous construisions un preneur de notes de réunion qui transcrivait les appels plus précisément que Granola. Nous avons forké Chromium pour qu'il ressemble à une application native et avons construit un pipeline à faible latence qui capturait l'audio système directement depuis l'appareil.
Mais la transcription de réunions n'avait pas de barrière à l'entrée. Dans notre précédente entreprise, nous avions vu les équipes commerciales avoir du mal à répondre aux questions techniques. Nous avons donc transformé le produit en assistant de réunion commerciale en temps réel.
Le pitch était simple :
Aider les équipes commerciales à répondre aux questions techniques pour que les questions techniques ne tuent pas les affaires.
C'est ce qui nous a fait entrer chez YC.
Au début, nous étions confiants. Le problème était facile à comprendre. Mais pendant le batch, trois choses ont déraillé.
1. Les clients ne voulaient pas connecter leurs connaissances
Une page d'accueil et un centre d'aide ne fournissaient pas assez de données pour générer des suggestions utiles en temps réel. Nous avions besoin de docs internes, de spécifications produits, de conversations passées et de contexte technique.
Mais même avec des NDA et un POC, les entreprises étaient réticentes à donner à une nouvelle startup l'accès à leurs informations les plus sensibles. Sans ce contexte, l'assistant ne pouvait donner que des réponses superficielles et limitées. Les retours étaient mauvais.
2. Les équipes commerciales ne se souciaient pas du facteur de forme
Notre équipe est douée pour construire des produits soignés et obsédée par l'UX.
Nous avons tout essayé pour rendre les suggestions utiles sans devenir distrayantes, de faire fonctionner Liquid Glass dans Chromium à tester chaque placement d'interface que nous pouvions imaginer. Mais nous n'avons pas trouvé la bonne interface.
Les clients se souciaient aussi bien moins de l'expérience que nous. Leurs retours étaient souvent une version de :
Pouvez-vous juste le rendre moins cher ?
3. L'équipe était épuisée
Un assistant de réunion commerciale dépend presque entièrement des retours clients.
Mais le batch d'automne s'est déroulé pendant Thanksgiving et Noël. Les clients continuaient à partir en vacances, et ce n'était de toute façon pas un problème urgent pour eux.
La boucle de rétroaction était douloureusement lente. Nous avons fini le batch sans traction significative.
Le blues post-YC
De décembre à janvier, nous avons traversé un cas brutal de blues post-YC.
Nous ne voulions plus écrire une seule ligne de code. Nous n'avions plus d'énergie. Le travail n'était plus amusant.
Ce point bas nous a obligés à regarder ce que nous avions manqué.
Nous avons commencé à poser des questions différentes :
- Quand avons-nous été les plus rapides ?
- Quel type de travail nous donnait de l'énergie ?
- Qu'est-ce qui rendait cette équipe unique ?
J'ai regardé notre vélocité de développement et j'ai constaté que nous étions cinq fois plus lents que lorsque nous construisions le preneur de notes de réunion original.
Une chose expliquait la majeure partie de l'écart :
À quelle fréquence utilisions-nous notre propre produit ?
Les retours clients raccourcissent la boucle de rétroaction. Devenir le client la raccourcit encore plus.
Vous utilisez le produit, remarquez ce qui ne va pas, le réparez, et l'utilisez à nouveau.
Nous avons réalisé que nous sommes les plus rapides quand nous construisons des produits pour nous-mêmes.
Dans quoi étions-nous exceptionnellement bons ?
Pendant YC, d'autres fondateurs nous demandaient souvent de l'aide avec des problèmes macOS et Chromium.
Notre CTO voulait construire une application qui se sentait native mais restait facile à étendre. Il détestait Electron, donc nous avons forké Chromium et personnalisé tout, des mises à jour à chaud au pipeline audio en temps réel.
Sur environ 1 500 entreprises des dix précédents batches YC, nous connaissions moins de cinq équipes capables de modifier Chromium à cette profondeur.
Les gens complimentaient aussi sans cesse notre produit et le design de notre page d'accueil. Chaque fois que nous postions notre travail sur X, ça devenait viral. Les camarades de batch demandaient comment nous l'avions construit.
Jun est obsédé par les détails. Il tient profondément à trouver le bon facteur de forme pour chaque problème.
Atteindre son niveau est difficile, mais nous l'avons fait plusieurs fois auparavant.
browser
Pendant le batch, nous avions une blague récurrente :
Si ça échoue, construisons un navigateur appelé bro.
Nous pouvions personnaliser Chromium. Nous pouvions concevoir un bon produit. Peut-être pourrions-nous construire le navigateur qui remplacerait Arc après que BCNY l'a abandonné.
J'avais été un grand fan d'Arc, mais je suis finalement retourné sur Chrome parce que BCNY l'a jeté.
Puis l'assistant commercial a effectivement échoué.
La blague a cessé d'être une blague.
La pièce manquante était le contexte
Il y avait un autre indice.
En construisant l'assistant de réunion, nous rencontrions toujours le même problème : chaque entreprise stockait ses connaissances à un endroit différent.
L'une utilisait Notion. Une autre utilisait GitHub. Une autre gérait l'entreprise via des feuilles de calcul.
Pour chaque client, nous devions construire une autre intégration et un autre pipeline d'indexation.
Puis nous avons demandé :
Et si on utilisait simplement les cookies, sessions et historique du navigateur ?
Les pièces ont commencé à s'assembler.
Aucune de ces prises de conscience ne nous est venue dans l'ordre. C'étaient des fragments. Nous n'avons vu le tableau complet qu'après avoir relié les points.
Pour la plupart des gens, le navigateur est l'application la plus utilisée. C'est là que se déroule déjà la plupart du travail de connaissance.
Il contient aussi plus de contexte sur votre travail que presque tout autre logiciel.
Si nous pouvions utiliser ce contexte, pourrions-nous construire un agent qui travaille réellement pour vous ?
Nous avions quelques hypothèses :
- Si un LLM est une machine à contexte, lui donner plus de contexte pertinent devrait le rendre bien plus capable.
- Si l'agent opère via le navigateur, les utilisateurs n'ont pas besoin de configurer d'innombrables intégrations.
- Si le navigateur supprime le besoin d'intégrations, il pourrait remodeler le marché B2B SaaS construit autour d'elles.
L'équipe s'est animée en discutant de ces idées. Plus important, nous avons réalisé que notre équipe avait exactement les compétences nécessaires pour construire ce produit.
Nous avons arrêté l'assistant commercial et nous nous sommes engagés dans le navigateur. La décision a pris moins de deux semaines.
Construire Aside
Nous avons décidé qu'Aside combinerait trois choses :
- Un navigateur Chromium bien conçu, comme Arc
- Un gestionnaire de mots de passe natif IA conçu pour les agents
- Un agent navigateur de pointe
Ensuite, nous n'avons presque rien dit à personne jusqu'à ce que nous soyons satisfaits.
Nous avons passé cinq mois complètement concentrés.
Cela semble probablement insensé. Ça l'était.
Codex et Claude ne pouvaient pas aider pour beaucoup des parties les plus difficiles. Chromium est une base de code vieille de 20 ans avec plus de 50 Go de source. Les agents de codage ne pouvaient pas faire de modifications profondes de manière fiable.
Nous avons construit le harnais et l'architecture d'agent nous-mêmes parce que nous refusions de livrer de la merde IA.
Le design est aussi l'un des domaines où l'IA aide le moins.
Mais c'était exactement le genre de travail que notre équipe savait faire. Nous étions certains que les gens voudraient le résultat.
Avons-nous ignoré les conseils de YC ?
Oui et non.
Oui, nous n'avons pas fait quelque chose que les gens veulent. Nous avons fait quelque chose que nous voulons. Nous avons à peine parlé aux utilisateurs. Nous n'avons pas livré rapidement.
Non, parce que nous étions les utilisateurs.
Nous avons continué à livrer en interne, à utiliser le produit, à trouver ce qui clochait, et à le réparer.
Notre boucle de rétroaction était plus rapide que les entretiens clients ne pourraient jamais l'être.
Nous savions aussi deux choses déjà :
- Les gens détestent Chrome et cherchent toujours une alternative.
- Ils ne passeront pas à une alternative qui semble inachevée ou qui plante constamment.
Nous avons donc passé cinq mois à bosser dur jusqu'à avoir quelque chose dont nous étions fiers d'utiliser chaque jour.
Le lancement
Après une petite bêta privée, nous avons enfin lancé publiquement.
La vidéo de lancement a dépassé 1,6 million de vues. Les gens ont essayé Aside et nous ont envoyé un flot de retours.
Nous nous attendions à ce que les gens soient intéressés. Nous ne nous attendions pas à ce qu'ils s'en soucient autant.
On pourrait appeler ça de la chance.
Mais nous avons créé cette chance nous-mêmes.
Nous avons regardé honnêtement ce dans quoi notre équipe était bonne. Nous avons choisi un problème qui correspondait à ces forces. Nous l'avons construit sous une forme que très peu d'équipes pouvaient bien réaliser.
Puis nous avons brûlé les vaisseaux derrière nous.
Ce n'est que le début
C'est encore tôt, mais nous sommes plus confiants que jamais.
Et pour tous ceux qui demandent :
N'est-ce pas juste un navigateur ?
Nous avons assez de choses à venir pour que cette question vieillisse très mal.
C'est l'histoire jusqu'à présent.
Intéressé ? Essayez-le.
