Forem: Henry van den Broek

Rewriting LinkaGoGo - my 25 year old Online Bookmark Manager

Henry van den Broek — Mon, 27 Apr 2026 16:11:00 +0000

I've been running LinkaGoGo since 2001. Here's what it took to rebuild it from scratch with AI.

About a year ago, I tried using AI coding assistants. The results were disappointing — occasionally there'd be a magic moment, but most of the time the code didn't work and required extensive debugging. I walked away and wrote it off as hype.

Then, this February, two things made me reconsider. My sister mentioned her company was exploring AI to automatically resolve JIRA tickets. And a blog post described building real applications in vanilla HTML/CSS/JavaScript — no frameworks — with AI assistance. Something had changed. I decided to find out what.

A Brief History: 25 Years of Bookmarks

LinkaGoGo went live in May 2001 — before "social bookmarking" was a phrase, before del.icio.us existed, when storing bookmarks online so you could reach them from any computer felt genuinely futuristic.

Over the years, the codebase accumulated layers. Features were bolted on. The UI got tweaks but never a rethink. The underlying Java servlets worked, but it was the kind of code you're afraid to touch because you've forgotten why half of it exists. By 2026, I had more than 6,000 bookmarks across 300+ folders and a loyal user base — but the product was showing its age badly.

I'd attempted rewrites before. REST APIs in XML, then JSON. Different frontend frameworks. I even built my own reactive framework, Reken, to make a rewrite easier — got a working prototype I used for years — but never made it public because it couldn't match the scope of the original. AI hadn't helped much there either; it struggled with a framework it had barely seen.

The Rebuild: Claude as Co-Developer

The turning point came during a walk, where I got the idea: what if I ditched all the old code and started from scratch — keeping only the database and its schema?

I installed Claude Code in an empty directory, added a markdown file describing the schema and UI paradigm (semantic HTML5, JavaScript, CSS — no frameworks), and started iterating. We landed on Python FastAPI for the backend, fronted by nginx. Within a week, 80% of LinkaGoGo was rebuilt with a responsive, modern UI. Within two weeks, I felt confident enough to ship it.

What came out the other side:

A completely new UI — clean, fast, single-page app with light and dark mode, multiple views (folder tree, timeline, rating-sorted), and a customizable dashboard. The classic interface still runs for longtime users who prefer it.
Advanced search — operators like url:, visited:30d, created:1095d+, sort:visit_count_desc. The kind of power-user syntax that makes managing 5,000 bookmarks tractable. Claude helped design the query parser, write the MySQL queries, and catch edge cases I'd have missed.
Browser extensions — manifest versions, content scripts, background workers, cross-browser quirks. Claude handled the boilerplate and, more importantly, helped think through the UX.
AI integration via MCP — LinkaGoGo now has a Model Context Protocol server that lets you manage bookmarks by talking to Claude, ChatGPT, or any MCP-compatible client. Say "find all my AI bookmarks I haven't visited in six months" and it just works. The irony of building an AI feature with AI, for an AI to use, is not lost on me.
Email-to-bookmark, dead link detection, duplicate finder, reminder system, shared public folders — feature after feature, built faster and with fewer bugs than I'd have managed alone.

What Actually Changed

A year ago, AI coding felt like autocomplete on steroids — useful for individual lines, but not for the kind of thinking that goes into architecture.

What I experience now is closer to having a senior developer available at any hour: someone who remembers everything in the session, can context-switch between your database schema, your frontend JavaScript, your nginx config, and your marketing copy without losing the thread, and will push back when your approach has a problem without lecturing you.

The single biggest productivity unlock wasn't any specific feature. It was being able to think out loud. I could say "I'm not sure whether to handle this in the backend or the frontend — here are the tradeoffs" and get a response that genuinely extended my thinking rather than just agreeing with me.

That wasn't my experience a year ago. Something changed — in the models, in the tooling, or in how I learned to work with them. Probably all three.

The Product, Today

LinkaGoGo in 2026 is faster, cleaner, and more capable than anything I could have built alone in a reasonable timeframe. It's also the same service that has been running continuously since 2001 — the oldest registered users have 25 years of bookmarks intact.

www.linkagogo.com — the rebuilt app, 7-day free trial
www.linkagogo.com/screenshots — new UI screenshots
www.linkagogo.com/mcp-setup] — MCP integration for AI clients
The old UI is still at www.linkagogo.com/go/Home

The lesson I keep coming back to: the tools got better, but so did I. Learning to work with an AI collaborator — what context to give it, when to trust it, when to push back, how to break problems down — is a skill. I didn't have it a year ago. I do now.

That skill is probably worth more than any single feature I shipped.

Originally published at https://blog.henryvandenbroek.com/rewrite-linkagogo-my-25-year-old-online-bookmark-manager/

Why Bookmark Managers Keep Dying — and How to Pick One That Won't

Henry van den Broek — Fri, 24 Apr 2026 04:00:00 +0000

There's a graveyard of bookmark services that were, at one point, the obvious choice. Delicious. Google Bookmarks. Pocket. Each one attracted millions of users, earned trust, and then disappeared.

If you've ever lost a bookmark collection to a shutdown, you know the feeling. It's not catastrophic — it's not like losing family photos. But it's a slow, annoying erosion of something you built over years. All those links you carefully saved, tagged, and organized — gone because someone else's business model didn't work out.

The graveyard

Delicious (2003-2017) — The original social bookmarking service. Acquired by Yahoo in 2005, neglected, sold to AVOS in 2011, sold again to Pinboard in 2017, then shut down. Fourteen years of slow death by acquisition.

Google Bookmarks (2005-2023) — Google's standalone bookmark service, separate from Chrome bookmarks. Quietly discontinued in 2023 with minimal notice. If Google won't maintain a bookmark service, what does that tell you?

Pocket (2007-2025) — Started as Read It Later, rebranded to Pocket, acquired by Mozilla in 2017. Mozilla shut it down in 2025 as part of cost-cutting. Eight years of Mozilla ownership, then gone.

Diigo — Still technically alive, but development stalled years ago. The interface looks like 2012 because it is. Users report bugs that never get fixed.

Pinboard — A one-person operation that attracted a loyal following with its "social bookmarking for introverts" pitch. The sole developer moved on to other interests. The service still runs, but feature development stopped long ago.

Why they die

The pattern is remarkably consistent.

Free services can't sustain themselves. Delicious was free. Google Bookmarks was free. Pocket had a free tier that most users never upgraded from. When the money runs out or priorities shift, free users have no leverage. You're not a customer — you're a metric.

VC-funded companies need to 10x. Venture capital demands exponential growth. A bookmark manager is a utility — people use it steadily, not virally. When a VC-backed bookmark service can't hit hockey-stick growth targets, the founders pivot to something else or the company gets acqui-hired for the team, not the product.

Acquisitions kill products. Yahoo bought Delicious for the team and the user base, not because they cared about bookmarks. Mozilla bought Pocket to bundle it with Firefox, not to run a standalone service. When the acquirer's priorities change, the acquired product is the first thing cut.

Solo developers burn out. Running a web service is relentless. Servers need monitoring, spam needs blocking, support emails need answering, browsers keep changing APIs. A single developer can sustain this for years, but not forever.

What makes a bookmark manager survive?

Turn the failure patterns inside out and you get a blueprint for survival:

Paid from day one. When users pay, the business has customers instead of metrics. Revenue aligns incentives — the company survives by keeping users happy, not by chasing growth or selling data. This is boring. Boring is the point.

Small and sustainable. A bookmark manager doesn't need fifty engineers. It needs a small team that can maintain the service profitably without external funding. No VC means no pressure to pivot, no pressure to sell, no pressure to "grow or die."

Standard export formats. Even the most trustworthy service should let you leave. Netscape HTML and XBEL are open bookmark formats that every browser and most bookmark tools can import. If a service doesn't support full export in a standard format, your bookmarks are hostages.

A track record. Anyone can launch a bookmark manager. The question is whether they'll still be running it in five years. Or ten. Or twenty.

LinkaGoGo's story

LinkaGoGo has been online since 2001. Twenty-five years.

It's not a startup. It's not VC-funded. It's not a side project that might get abandoned when something shinier comes along. It's a small, self-funded business that charges money for a service and uses that money to keep the service running. That's the entire business model.

Plans start at $4.95/year. Not $4.95/month — per year. The pricing is designed to be low enough that you never think about canceling, and high enough that the service can sustain itself without ads, data mining, or VC subsidies.

LinkaGoGo exports in both Netscape HTML and XBEL formats. If you ever want to leave, your bookmarks come with you. No lock-in, no data ransom, no "please contact support to request an export."

This isn't a pitch for why LinkaGoGo is the best bookmark manager in every dimension. It's a pitch for why it will still be here next year, and the year after that. In an industry where services keep dying, longevity is a feature.

How to evaluate any bookmark manager

Before trusting a service with your bookmark collection, ask these questions:

Does it export? If not, walk away. Your data should be portable in a standard format (HTML or XBEL) at all times.
Is it profitable? A free service with no clear revenue model will eventually shut down or start selling your data. Check if it charges money and whether those charges seem sustainable.
Is it a side project? Solo-developer projects can be excellent, but they carry risk. If the developer loses interest, the service decays. Look for signs of active maintenance.
Who owns it? If a VC firm owns it, the service exists to generate returns for investors, not to serve you. If a large company owns it, the service exists until the next cost-cutting round.
How long has it been running? Longevity isn't a guarantee of future survival, but it's the best signal we have. A service that has been running for ten years has already survived the phases where most services die.

The boring conclusion

The best bookmark manager is the one that will still exist when you need it. Features matter, but they matter less than survival. A dead service with great features is worse than a live service with good ones.

Pick a bookmark manager that charges money, exports your data, and has been around long enough to prove it can last. Then stop worrying about it and go back to saving bookmarks.

Try LinkaGoGo free for 7 days — online since 2001, plans from $4.95/year, full export in HTML and XBEL.

Originally published at linkagogo.com/blog/why-bookmark-managers-keep-dying

Hello from LinkaGoGo — indie dev, cyclist, camper vanner

Henry van den Broek — Fri, 24 Apr 2026 00:05:56 +0000

Hi Dev.to! I'm Henry, an indie developer based in MA. I've been building LinkaGoGo (https://www.linkagogo.com) — an online bookmark manager that's been running since 2001 — and a few other projects like Reken (https://reken.dev).

I'll be sharing posts about building indie products, bookmark management, and the IndieWeb. First real post coming soon.

When I'm not coding I'm on a bike or travelling in my self-built camper van.