Since launching @AsideAI, people have kept asking why we pivoted. I got tired of retelling the story, but the process meant enough to us that I wanted to write it down.
TLDR; Aside is an AI browser that completes real work across the websites you already use. It can use your existing browser sessions, work inside email, dashboards, internal tools, docs, and spreadsheets, and keep going when a task takes minutes or hours.
Before YC
We got into Y Combinator on our #7 try.
Before YC, we were building a meeting notetaker that transcribed calls more accurately than Granola. We forked Chromium to make it feel like a native app and built a low-latency pipeline that captured system audio directly from the device.
But meeting transcription had no moat. At our previous company, we had seen sales teams struggle to answer technical questions. So we turned the product into a real-time sales meeting assistant.
The pitch was simple:
Help sales teams answer technical questions so technical questions don't kill deals.
That got us into YC.
At first, we were confident. The problem was easy to understand. But during the batch, three things broke.
1. Customers would not connect their knowledge
A landing page and help center did not provide enough data to generate useful real-time suggestions. We needed internal docs, product specifications, past conversations, and technical context.
But even with NDAs and a POC, companies were reluctant to give a new startup access to their most sensitive information. Without that context, the assistant could only give shallow, limited answers. The feedback was bad.
2. Sales teams did not care about the form factor
Our team is good at building polished products and obsessing over UX.
We tried everything to make the suggestions useful without becoming distracting, from making Liquid Glass work inside Chromium to testing every UI placement we could think of. But, we couldn't find the right interface.
Customers also cared far less about the experience than we did. Their feedback was often some version of:
Can you just make it cheaper?
3. The team was exhausted
A sales meeting assistant depends almost entirely on customer feedback.
But the Fall batch ran through Thanksgiving and Christmas. Customers kept going on vacation, and this was not a hair-on-fire problem for them anyway.
The feedback loop was painfully slow. We finished the batch without meaningful traction.
The post-YC blues
From December through January, we went through a brutal case of the post-YC blues.
We did not want to write another line of code. We had no energy. The work was no longer fun.
That low point forced us to look at what we had missed.
We started asking different questions:
- When had we moved fastest?
- What kind of work gave us energy?
- What was unique about this team?
I looked at our development velocity and found that we were moving five times slower than when we had been building the original meeting notetaker.
One thing explained most of the gap:
How often did we use our own product?
Customer feedback shortens the feedback loop. Becoming the customer shortens it even more.
You use the product, notice what is broken, fix it, and use it again.
We realized that we move fastest when we build products for ourselves.
What were we unusually good at?
During YC, other founders often asked us for help with macOS and Chromium problems.
Our CTO wanted to build an app that felt native but was still easy to extend. He hated Electron, so we forked Chromium and customized everything from hot updates to the real-time audio pipeline.
Of roughly 1,500 companies across the previous ten YC batches, we knew of fewer than five teams capable of modifying Chromium at this depth.
People also kept complimenting our product and landing page design. Whenever we posted our work on X, it went viral. Batchmates asked how we had built it.
Jun is obsessed with details. He cares deeply about finding the right form factor for each problem.
Meeting his bar is hard, but we have done it many times before.
browser
During the batch, we had a running joke:
If this fails, let's build a browser called bro.
We could customize Chromium. We could design a good product. Maybe we could build the browser that replaced Arc after BCNY moved on from it.
I had been a huge Arc fan, but eventually went back to Chrome because BCNY throw it away.
Then the sales assistant actually failed.
The joke stopped being a joke.
The missing piece was context
There was another clue.
While building the meeting assistant, we kept running into the same problem: every company stored its knowledge somewhere different.
One used Notion. Another used GitHub. Another ran the company through spreadsheets.
For every customer, we had to build another integration and another indexing pipeline.
Then we asked:
What if we just used the browser's cookies, sessions, and history?
The pieces started fitting together.
None of these realizations came to us in order. They were fragments. We only saw the full picture after connecting the dots.
For most people, the browser is their most-used app. It is where most knowledge work already happens.
It also contains more context about your work than almost any other piece of software.
If we could use that context, could we build an agent that actually worked on your behalf?
We had a few hypotheses:
- If an LLM is a context machine, giving it more relevant context should make it far more capable.
- If the agent operates through the browser, users do not need to configure endless integrations.
- If the browser removes the need for integrations, it could reshape the B2B SaaS market built around them.
The team came alive while discussing these ideas. More importantly, we realized that our team had the exact skills needed to build this product.
We shut down the sales assistant and committed to the browser. The decision took less than two weeks.
Building Aside
We decided Aside would combine three things:
- A well-crafted Chromium browser, like Arc
- An AI-native password manager built for agents
- A state-of-the-art browser agent
Then we told almost no one until we were satisfied.
We spent five months fully locked in.
That probably sounds insane. It was.
Codex and Claude could not help with many of the hardest parts. Chromium is a 20-year-old codebase with more than 50GB of source. Coding agents could not reliably make deep changes to it.
We built the harness and agent architecture ourselves because we refused to ship AI slop.
Design is also still one of the areas where AI helps the least.
But this was exactly the kind of work our team knew how to do. We were certain people would want the result.
Did we ignore YC's advice?
Yes and no.
Yes, We did not make something people want. We made something we want. We barely talked to users. We did not ship quickly.
No, because we were the users.
We kept shipping internally, using the product, finding what felt wrong, and fixing it.
Our feedback loop was faster than customer interviews could ever be.
We also knew two things already:
- People hate Chrome and are always looking for an alternative.
- They will not switch to an alternative that feels unfinished or constantly breaks.
So we spent five months grinding until we had something we were proud to use every day.
The launch
After a small private beta, we finally launched publicly.
The launch video passed 1.6M views. People tried Aside and sent us a flood of feedback.
We expected people to be interested. We did not expect them to care this much.
You could call that luck.
But we made that luck ourselves.
We looked honestly at what our team was good at. We chose a problem that fit those strengths. We built it in a form that very few teams could pull off well.
Then we burned the boats behind us.
This is just the beginning
It is still early, but we are more confident than we have ever been.
And for everyone asking:
Isn't this just a browser?
We have enough coming to make that question age very badly.
That is the story so far.
Interested? Give it a shot.
