Seit dem Start von @AsideAI fragen mich die Leute ständig, warum wir einen Richtungswechsel vollzogen haben. Ich wurde es leid, die Geschichte immer wieder zu erzählen, aber der Prozess war uns so wichtig, dass ich ihn aufschreiben wollte.
TLDR; Aside ist ein KI-Browser, der echte Arbeit auf den Websites erledigt, die du bereits nutzt. Er kann deine bestehenden Browser-Sitzungen verwenden, in E-Mails, Dashboards, internen Tools, Dokumenten und Tabellenkalkulationen arbeiten und weitermachen, wenn eine Aufgabe Minuten oder Stunden dauert.
Vor YC
Wir kamen bei Y Combinator rein – beim 7. Versuch.
Vor YC bauten wir einen Meeting-Notizen-Tool, das Anrufe genauer transkribierte als Granola. Wir haben Chromium geforkt, damit es sich wie eine native App anfühlt, und eine latenzarme Pipeline gebaut, die Systemaudio direkt vom Gerät erfasst.
Aber Meeting-Transkription hatte keinen Schutzmechanismus. In unserem vorherigen Unternehmen hatten wir erlebt, wie Verkaufsteams mit technischen Fragen zu kämpfen hatten. Also verwandelten wir das Produkt in einen Echtzeit-Assistenten für Verkaufsgespräche.
Der Pitch war einfach:
Hilf Verkaufsteams, technische Fragen zu beantworten, damit technische Fragen keine Deals killen.
Damit kamen wir in YC rein.
Anfangs waren wir zuversichtlich. Das Problem war leicht zu verstehen. Aber während des Batches gingen drei Dinge schief.
1. Kunden wollten ihr Wissen nicht teilen
Eine Landingpage und ein Helpcenter lieferten nicht genug Daten, um nützliche Echtzeit-Vorschläge zu generieren. Wir brauchten interne Dokumente, Produktspezifikationen, vergangene Gespräche und technischen Kontext.
Aber selbst mit NDAs und einem Proof-of-Concept zögerten Unternehmen, einem neuen Startup Zugang zu ihren sensibelsten Informationen zu geben. Ohne diesen Kontext konnte der Assistent nur oberflächliche, begrenzte Antworten geben. Das Feedback war schlecht.
2. Verkaufsteams war das Format egal
Unser Team ist gut darin, ausgefeilte Produkte zu bauen und sich um die Benutzererfahrung zu kümmern.
Wir haben alles versucht, um die Vorschläge nützlich zu machen, ohne abzulenken – von der Integration von Liquid Glass in Chromium bis hin zum Testen jeder erdenklichen UI-Platzierung. Aber wir fanden die richtige Oberfläche nicht.
Kunden legten auch viel weniger Wert auf die Erfahrung als wir. Ihr Feedback war oft in etwa:
Kannst du es einfach billiger machen?
3. Das Team war erschöpft
Ein Assistent für Verkaufsgespräche ist fast vollständig auf Kundenfeedback angewiesen.
Aber der Fall-Batch fand über Thanksgiving und Weihnachten statt. Kunden waren ständig im Urlaub, und für sie war das sowieso kein brennendes Problem.
Die Feedback-Schleife war quälend langsam. Wir beendeten den Batch ohne nennenswerten Fortschritt.
Die Post-YC-Blues
Von Dezember bis Januar durchlitten wir eine brutale Phase der Post-YC-Blues.
Wir wollten keine einzige Zeile Code mehr schreiben. Wir hatten keine Energie. Die Arbeit machte keinen Spaß mehr.
Dieser Tiefpunkt zwang uns, uns anzuschauen, was wir übersehen hatten.
Wir begannen, andere Fragen zu stellen:
- Wann waren wir am schnellsten gewesen?
- Welche Art von Arbeit gab uns Energie?
- Was war einzigartig an diesem Team?
Ich schaute mir unsere Entwicklungsgeschwindigkeit an und stellte fest, dass wir fünfmal langsamer arbeiteten als beim Bau des ursprünglichen Meeting-Notizen-Tools.
Eine Sache erklärte den größten Teil der Lücke:
Wie oft haben wir unser eigenes Produkt genutzt?
Kundenfeedback verkürzt die Feedback-Schleife. Selbst zum Kunden zu werden, verkürzt sie noch mehr.
Du nutzt das Produkt, bemerkst, was kaputt ist, reparierst es und nutzt es wieder.
Uns wurde klar, dass wir am schnellsten sind, wenn wir Produkte für uns selbst bauen.
Worin waren wir ungewöhnlich gut?
Während YC baten uns andere Gründer oft um Hilfe bei macOS- und Chromium-Problemen.
Unser CTO wollte eine App bauen, die sich nativ anfühlt, aber trotzdem einfach erweiterbar ist. Er hasste Electron, also forkten wir Chromium und passten alles an, von Hot Updates bis zur Echtzeit-Audio-Pipeline.
Von etwa 1.500 Unternehmen in den vorherigen zehn YC-Batches kannten wir weniger als fünf Teams, die Chromium in dieser Tiefe modifizieren konnten.
Die Leute lobten auch immer wieder unser Produkt- und Landingpage-Design. Immer wenn wir unsere Arbeit auf X veröffentlichten, wurde sie viral. Batchmates fragten, wie wir es gebaut hatten.
Jun ist besessen von Details. Ihm liegt viel daran, die richtige Form für jedes Problem zu finden.
Seine Messlatte zu erreichen ist schwer, aber wir haben es schon oft geschafft.
browser
Während des Batches hatten wir einen Insider-Witz:
Wenn das hier scheitert, bauen wir einen Browser namens bro.
Wir konnten Chromium anpassen. Wir konnten ein gutes Produkt designen. Vielleicht könnten wir den Browser bauen, der Arc ersetzt, nachdem BCNY sich davon abgewandt hat.
Ich war ein riesiger Arc-Fan, bin aber letztendlich zu Chrome zurückgekehrt, weil BCNY es weggeworfen hat.
Dann scheiterte der Verkaufsassistent tatsächlich.
Der Witz hörte auf, ein Witz zu sein.
Das fehlende Puzzleteil war der Kontext
Es gab noch einen weiteren Hinweis.
Während wir den Meeting-Assistenten bauten, stießen wir immer wieder auf dasselbe Problem: Jedes Unternehmen speicherte sein Wissen woanders.
Eines nutzte Notion. Ein anderes GitHub. Ein drittes führte das Unternehmen über Tabellenkalkulationen.
Für jeden Kunden mussten wir eine weitere Integration und eine weitere Indizierungs-Pipeline bauen.
Dann fragten wir:
Was, wenn wir einfach die Cookies, Sitzungen und den Verlauf des Browsers nutzen?
Die Puzzleteile fügten sich zusammen.
Keine dieser Erkenntnisse kam uns in der richtigen Reihenfolge. Es waren Bruchstücke. Wir sahen das Gesamtbild erst, als wir die Punkte verbanden.
Für die meisten Menschen ist der Browser die am häufigsten genutzte App. Hier findet der Großteil der Wissensarbeit statt.
Er enthält auch mehr Kontext über deine Arbeit als fast jede andere Software.
Wenn wir diesen Kontext nutzen könnten, könnten wir dann einen Agenten bauen, der tatsächlich in deinem Namen arbeitet?
Wir hatten ein paar Hypothesen:
- Wenn ein LLM eine Kontextmaschine ist, sollte ihm mehr relevanter Kontext ihn weitaus leistungsfähiger machen.
- Wenn der Agent über den Browser operiert, müssen Benutzer keine endlosen Integrationen konfigurieren.
- Wenn der Browser die Notwendigkeit von Integrationen beseitigt, könnte er den darauf aufbauenden B2B-SaaS-Markt neu gestalten.
Das Team wurde lebendig, als wir diese Ideen diskutierten. Noch wichtiger: Wir erkannten, dass unser Team genau die Fähigkeiten hatte, die für den Bau dieses Produkts nötig waren.
Wir stellten den Verkaufsassistenten ein und verpflichteten uns dem Browser. Die Entscheidung dauerte weniger als zwei Wochen.
Aside bauen
Wir entschieden, dass Aside drei Dinge kombinieren würde:
- Einen gut gestalteten Chromium-Browser, wie Arc
- Einen KI-nativen Passwort-Manager, der für Agenten entwickelt wurde
- Einen hochmodernen Browser-Agenten
Dann erzählten wir es fast niemandem, bis wir zufrieden waren.
Wir verbrachten fünf Monate komplett fokussiert.
Das klingt wahrscheinlich verrückt. War es auch.
Codex und Claude konnten bei vielen der schwierigsten Teile nicht helfen. Chromium ist eine 20 Jahre alte Codebasis mit mehr als 50 GB Quellcode. Coding-Agenten konnten keine zuverlässigen tiefgreifenden Änderungen daran vornehmen.
Wir bauten das Gerüst und die Agenten-Architektur selbst, weil wir uns weigerten, KI-Schrott auszuliefern.
Design ist auch immer noch einer der Bereiche, in denen KI am wenigsten hilft.
Aber das war genau die Art von Arbeit, die unser Team zu erledigen wusste. Wir waren sicher, dass die Leute das Ergebnis wollen würden.
Haben wir YCs Rat ignoriert?
Ja und nein.
Ja, wir haben nicht etwas gebaut, was die Leute wollen. Wir haben etwas gebaut, was wir wollen. Wir haben kaum mit Nutzern gesprochen. Wir haben nicht schnell ausgeliefert.
Nein, weil wir die Nutzer waren.
Wir haben intern kontinuierlich ausgeliefert, das Produkt genutzt, gefunden, was sich falsch anfühlte, und es repariert.
Unsere Feedback-Schleife war schneller, als Kundeninterviews es je sein könnten.
Wir wussten auch bereits zwei Dinge:
- Die Leute hassen Chrome und suchen immer nach einer Alternative.
- Sie werden nicht zu einer Alternative wechseln, die sich unfertig anfühlt oder ständig abstürzt.
Also verbrachten wir fünf Monate damit, zu arbeiten, bis wir etwas hatten, auf das wir stolz waren, es täglich zu nutzen.
Der Launch
Nach einer kleinen privaten Beta starteten wir endlich öffentlich.
Das Launch-Video hatte über 1,6 Millionen Aufrufe. Die Leute probierten Aside aus und überschütteten uns mit Feedback.
Wir erwarteten, dass die Leute interessiert sein würden. Wir erwarteten nicht, dass es ihnen so viel bedeuten würde.
Man könnte das Glück nennen.
Aber wir haben uns dieses Glück selbst gemacht.
Wir haben ehrlich darauf geschaut, worin unser Team gut ist. Wir haben ein Problem gewählt, das zu diesen Stärken passt. Wir haben es in einer Form gebaut, die nur sehr wenige Teams gut umsetzen könnten.
Dann haben wir die Brücken hinter uns abgebrochen.
Das ist erst der Anfang
Es ist noch früh, aber wir sind zuversichtlicher als je zuvor.
Und an alle, die fragen:
Ist das nicht einfach nur ein Browser?
Wir haben genug in der Pipeline, um diese Frage sehr alt aussehen zu lassen.
Das ist die Geschichte bisher.
Interessiert? Probier es aus.
