I built a bookmark manager without building a bookmark database

I've always been a heavy user of browser bookmarks.

I divide them into areas like work, personal stuff, travel, and so on. But my work bookmarks were the ones that eventually became a problem.

I'm a developer, and on a normal day I can easily need 20 or more different resources. I had them organized, but finding one still meant opening a folder and scrolling through a long vertical list.

It worked. I just didn't like using it.

I kept thinking that navigating my bookmarks would be much easier if it felt more like navigating files in Finder.

So about a year ago, I started learning how browser extensions could communicate with the browser's bookmark API. At the same time, I wanted an excuse to learn Next.js.

I wasn't trying to start a business. I was building something for myself.
Eventually, that became Bookmash.

I never wanted another bookmark database

One decision was there from the beginning: the browser would remain the source of truth.

The browser API already gave me access to the bookmark structure I needed. I didn't see a reason to import all that data into another database and create a second bookmark library.

So Bookmash works as a layer on top of your existing bookmarks. The extension communicates with the browser API, while the dashboard gives you a different way to interact with what's already there.

If you're using Chrome, you're working with your Chrome bookmarks. If you're using Firefox, you're working with your Firefox bookmarks.

There's no separate Bookmash database containing a copy of them, and nothing to import or migrate before you can start using it.

At first, though, I mostly wanted a better interface.
Then I started adding things the browser didn't give me.

Collections changed what Bookmash was.

Collections were probably the first feature that made me feel like I was building more than a different bookmark UI.

Browser bookmark trees have a structure dictated by the browser. The main folders are treated differently: one fills the bookmarks bar until you run out of space, while another sits collapsed behind a menu.

I wanted to stop thinking about that division.

With Collections, I could bring together folders from anywhere in the native bookmark tree and organize them independently inside Bookmash, without changing their original structure.

For me, that was the point: the browser could keep organizing bookmarks the way it needed to, while I could have a global view organized around the way I actually used them.

Then another problem appeared.

I had too many "favorites" in my favorites

There were a handful of bookmarks I used constantly.

The obvious solution was to put them at the beginning of my bookmarks bar. But the more I put there, the less space remained for everything else — especially when I was working just on my MacBook screen instead of an external monitor.

I tried making a folder specifically for those favorites and keeping it at the beginning of the bar.

That saved space, but now opening a favorite meant opening a dropdown first, and adding new ones was more cumbersome than I wanted.

So I built MyMash.

With MyMash, I can mark any bookmark as a favorite and have it immediately available there, without moving it from its original folder. The same bookmark can live in its usual place in the browser tree and appear in MyMash at the same time.

It's basically my hot set: the bookmarks I want immediately available, regardless of where they live in the browser tree.

This became a pattern while building Bookmash: I'd use it myself, notice some friction, and build the thing I wished was there.

Browser extensions were harder than I expected

The architecture itself was never an accident.

I knew from the beginning that I wanted to use the browser API and keep the browser as the source of truth.

What I underestimated was how much work that decision would create.

Some update flows were particularly tricky. Development could also be slow simply because changing something in the extension meant rebuilding it and loading it locally again to test it.

And then there were the browser differences.

I primarily use Chrome, but I wanted Bookmash to be available to Firefox users too. I actually started working on Edge compatibility as well, before deciding that maintaining three browsers as a solo developer wasn't a particularly good idea.

So I focused on Chrome and Firefox.

I expected most bugs to behave roughly the same way in both. They didn't.

Chrome and Firefox handle some folder structures and updates differently enough that bugs can show up in completely different ways.

And once the extensions became public, another kind of waiting entered the development cycle: store reviews and approvals.

When you're used to deploying a web app whenever you want, that's quite a change.

The technical part wasn't actually the hardest

This surprised me.

I'm a Senior Frontend Engineer, and this was the first time I'd built a complete product of my own. The technical side was both intimidating and exciting, and I expected it to be the difficult part.

Some of it certainly was, especially the communication with the extensions. But things like integrating Stripe or an email provider turned out to be problems I could research, learn and solve.

UI and UX were harder.

I worked as a web designer before becoming a developer, which definitely helped. But designing your own product is different.

I redesigned parts of Bookmash more times than I'd like to admit.

I didn't want it to feel anonymous. Especially now, when it's very easy to end up with an interface that looks like many other interfaces, I wanted Bookmash to have a personality of its own.

Finding that personality took much longer than implementing many of the features.

And then I discovered an even harder problem.

Building something is easier than finding people to use it

I've never had a large social following.

I post quite a lot on LinkedIn, but mostly about frontend development, technical topics and developer soft skills. I didn't already have an audience waiting for a bookmark manager.

So after spending all that time figuring out how to build Bookmash, I suddenly had to figure out how to get it in front of people.

The first payment was an amazing moment.

But even before that, simply reaching the point where I could use Bookmash myself as a real product felt significant.

So did building a public demo and finally being able to show someone what the product does without asking them to install anything first.

And that demo exists partly because of something else I learned.

I waited too long to ask what other people thought

At some point, I started sharing Bookmash and asking people for feedback.

One of the places I shared it was Reddit, and the comments there quickly exposed things I'd taken for granted.

The product looked different then.

There was no full demo, only a small interactive section. The pricing was lifetime-only. And some of the language I was using made perfect sense to me but wasn't nearly as clear to other people.

People wanted to understand the product before paying for it. That pushed me toward building the demo.

Lifetime-only pricing required more trust upfront than I'd realized, so I added monthly and yearly options.

And some people weren't sure whether Bookmash was taking their bookmarks and storing them in its own database.

To me, the answer was obvious. Of course it wasn't. The whole architecture had been built around that decision.

But they couldn't know that.

I'd spent so long inside the product that I was treating information I knew as information everyone knew.

That feedback changed Bookmash.

I'm more proud of the product now than I was before those conversations, because it feels more solid — not just technically, but in the way it's presented to someone discovering it for the first time.

If I started again, I'd build in public much earlier

Right now, what I want most is more feedback.

Bookmash started with my own needs. I know it solves those.

What I don't know yet is how closely those needs match other people's, where they differ, and which of those differences are worth turning into new features.

That's the interesting part now.

If I were starting another product tomorrow, I wouldn't wait until I'd built so much before showing it to people.

I'd build in public much earlier.

Not because other people should decide what the product is, but because there's a huge difference between building something that feels obvious to you and watching someone encounter it without all the context you have in your head.

A year ago, I just wanted a Finder-like way to navigate the bookmarks I was already using every day.

Now Bookmash is live on Chrome and Firefox, with Collections, MyMash, search, a public demo, authentication, payments, and a lot of things I definitely wasn't thinking about when I started learning the browser API.

And my bookmarks are still exactly where I wanted them to be: in my browser.