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/