Building the new tab for work

I started eesel with a friend as a side project. In under two years, we incorporated a company, raised money, and hired great people. eesel became a Product Hunt Product of the Year finalist, one of FastCompany’s best productivity apps, and helped thousands of people at companies like Atlassian, Google, Facebook, and Revolut.

The idea

At Intercom I collaborated with lots of people every day — and that meant lots of shared documents: GitHub issues, project briefs in Google Docs, Amplitude dashboards, Slides reports. Getting back to those documents was a pain, and I could tell I wasn’t alone. A friend of mine, a PM at Intercom, felt the same, so we started exploring solutions together.

Why API hubs failed

For a long time our explorations centred on the status quo: API hubs, which connect your apps so you can find all your documents in one place. We’d tried them before and never stuck with them — and our teammates’ experience matched. We saw three reasons:

1. Hard to maintain: building and maintaining dozens of integrations takes huge effort — effort not spent on the experience, bug fixes, or performance, so these apps often lacked quality.
2. Limited: no hub can support every tool, and they’re always playing catch-up with new ones. If the solution isn’t exhaustive, users never form the habit.
3. Scary: connecting tools means granting intrusive permissions, sometimes to every doc in the org. We hesitated at that step ourselves, and sometimes gave up when a hub felt too shady.

Building yet another API hub wasn’t exciting, and our hopes of solving the problem stayed low for a long time.

Eureka

I remember the scene well. We were at the whiteboard again, running through the same API problems and the same ways to overcome them, when my brain made a weird connection — probably from my early days learning semantic HTML: the web is an API. It’s a set of standards designed to let software like browsers integrate with websites. What if, instead of integrating with dozens of APIs, we integrated with just one — the web?

After weeks of stagnation, the idea felt instantly exciting. We decided to start simple: filter the browser history to surface only work-relevant pages. That was almost enough to begin.

Validating our direction

Exciting as it was, we needed to test a couple of assumptions first.

First, our solution would only work for documents opened in the browser. If re-accessing offline files (like a Word doc) mattered, we’d fail.

Second, it would only work for documents you’d opened before. If finding never-seen documents mattered, we’d fail again.

Luckily, we had plenty of opportunities to test both in our daily work, and after a few weeks we had two clear answers:

1. Re-accessing documents is far more of a problem in the browser. Offline files are increasingly rare, and even then they’re easier to find — people usually have one or two main native tools (Figma for designers, Visual Studio for engineers) whose files are reachable from the start screen. The real pain is the flood of links shared across tools that are secondary to your job.
2. Needing something you’ve never seen is rare. Usually the pain is finding something you know exists — and you know it exists because you’ve already opened it.

That was finally enough to start prototyping.

The prototype

We quickly built a simple browser-history filter for work. We descoped plenty of ideas and left many questions unexplored, but one thing we had to get right from the start: habit formation.

Asking people to form new habits around documents they open dozens of times a day is hard, so we built on an existing habit instead: the new tab.

The first version simply showed links from a few domains we knew were work-related. After a few days of “internal use” (really just the two of us), it was already so valuable that we started a closed beta. My co-founder had left Intercom by then, so I recruited beta users there. We quickly discovered we’d accidentally built a virality engine with the new tab: within days, people who saw eesel in my new tab while I presented in meetings started asking what the app was.

In a few weeks the beta grew organically past 100 users — and they were engaged, opening documents in eesel every day, with strong retention from day one. The feedback was overwhelmingly positive and fuelled our motivation to take eesel further.

The product

The natural next step was to open the beta wider, via a Product Hunt launch. But first, a few things needed work.

We brought on an engineer to turn the prototype into a robust, production-ready app — one of my best friends, and one of the best engineers I’ve ever worked with. In a few weeks he rewrote the app entirely, fixed tons of bugs, and added a robust design system and a new onboarding.

We also had to prepare the marketing. eesel (“Obair” at the time) didn’t even have a real name. I led most of this work, a challenge since I’d never really done marketing before. We landed on a name, a logo, a visual style, a tagline, and a basic narrative for the “why” behind eesel, and I used it all to build our first landing page:

We launched on Product Hunt in April 2020. With huge support from our existing user base, we finished Product of the Day and grew to 1.5k users.

The strong engagement and retention from the beta held, the feedback stayed overwhelmingly positive — and that’s when investors started reaching out.

The company

It took us a few months to fully commit to eesel. We tried to raise in autumn 2020, closed our round in early 2021, and the three of us went full-time.

The product worked well, but rather than monetise or chase user growth, our plan was to find a team-collaboration use case. We figured an app like eesel would be hard to monetise if we targeted individuals, and that keeping it free would let the new tab’s virality drive bottom-up adoption inside teams. We also saw adjacent collaboration jobs eesel could help with — especially building a shared source of truth for team projects, with all the relevant links always up to date.

So we focused on building “eesel Folders”:

A Folder is a shareable list of links. We wanted it to need almost no manual work: pages would be sorted into the right folders by default rules, with a simple rule builder for manual overrides:

After months of iteration, Folders never found the usage we hoped for. About 10% of our users adopted them — but only for individual use, almost never sharing. We identified several blockers over time. One was that people simply forgot to create Folders for new projects, so we built “Folder suggestions” to detect interesting new keywords in the browser history and propose Folders for them:

It was very well received, but it still didn’t unlock the collaboration usage we were hoping for.

The end

At the end of 2022, we decided to stop investing in the team use case. We assumed that keeping eesel free would drive bottom-up team adoption. We were wrong: eesel grew, but slowly — at least until we invested in marketing. I think we should have started that effort earlier; hitting milestones like our first 5k and 10k users would probably have built momentum for organic growth.

The second issue: our no-API approach was great for individuals (no setup, no sign-up, no permissions) but too limiting for teams. The key collaboration question was which pages of someone’s history to make available to the team — and we definitely didn’t want to share everything. Our only answer was shared Folders, an indirect way to do the job: create a folder, add pages, then invite the team — a lot of steps not directly tied to sharing. Worse, Folders have what I call an asymmetrical effort-to-benefit ratio: I can be the perfect user, create every folder, add the right pages, and invite everyone, but if my teammates don’t do the same, I get nothing back.

Could we have caught this earlier? The marketing gap needed experience we didn’t have — we should have sought more advice. On the product side, we should have explored higher-level directions sooner (should we have compromised on “no API” for the team use case?). We were also fooled by the blockers we found and the small improvements we shipped in response: each let more people use Folders, but none deeply moved the collaboration usage. We should instead have dug into how critical a “shared source of truth” really was for teams. We didn’t have the tools for that at the time, but since reading the excellent Monetizing Innovation, I think early willingness-to-pay conversations would have shown us how painful the problem really was.

I left eesel in April 2023. The company isn’t entirely over, but it’s starting a very different chapter, away from our original vision.

In two years we grew eesel to 11.5k active users, delivered real value to many of them, and met and hired amazing people — but we failed to build a sustainable business. It remains an incredible learning experience, full of very high highs and very low lows.