DEV Community: David Hamilton

Local-first bookmark managers are back. Two ideals most of them quietly skip.

David Hamilton — Fri, 10 Jul 2026 16:12:38 +0000

Two of the most loved read-later apps on the internet shut down inside eight months of each other. Omnivore went first, acquihired by ElevenLabs and switched off on November 15, 2024. Then Pocket, after Mozilla let it wither for years, shut on July 8, 2025 and took roughly 35 million libraries with it.

Neither died because the technology failed. They died because the business around them stopped making sense to somebody in a meeting.

So a whole category of bookmark tools came back with a single promise. Run it yourself. Self-hosted, Docker-composed, SQLite on a disk you can hold. Nobody can take this away from you.

I build a bookmark tool, so I have skin in this. And I think the people building the self-hosted wave are right about the problem and slightly wrong about the fix. Local-first won the argument. It has not yet won the job.

What local-first actually means

The phrase is not marketing. It comes from a 2019 essay by Ink & Switch, and it is specific enough to argue with. Local-first software keeps the primary copy of your data on your own device. The network is an enhancement, not a dependency.

The manifesto lays out seven ideals a local-first app should hit:

Fast, because reads and writes never wait on a server
Multi-device, so your stuff follows you
Offline, meaning full function with the wifi off
Collaboration, so other people can still work with you
Longevity, meaning the software outlives the company
Privacy, because the data never has to leave your machine
User control, the right to take your data and go

Seven. Read that list again, because almost every conversation about local-first bookmarks only ever discusses three of them.

Grade a self-hosted bookmark app honestly

Take a typical self-hosted bookmark manager (Karakeep, Linkwarden, both genuinely excellent) and grade it against the seven ideals it is implicitly claiming.

Ideal	Typical self-hosted app	Honest grade
Fast	Local database, no round trip	Excellent
Offline	Works with the network unplugged	Excellent
Privacy	Data never leaves your box	Excellent
User control	Your disk, your file	Excellent
Multi-device	Needs a server, a domain, a VPN, or all three	Depends on your patience
Collaboration	Rarely a goal, often absent	Weak
Longevity	Survives the vendor. Does not survive you.	The quiet failure

Four straight wins. Those are real, and they are why the category deserves its comeback. The bottom row is where it gets uncomfortable.

The longevity everyone cites and nobody tests

"The software works in ten years even if the vendor is gone." Fine. Does it work in ten years if you are gone? Not dead. Just busy.

A self-hosted bookmark manager you stopped patching, whose Docker image is three majors behind, whose backup cron job silently broke in March, is not safer than Pocket was. It is a shutdown with extra steps. Pocket at least emailed you. Your unmaintained container will not.

Self-hosting does not delete the risk of losing your library. It moves the risk from a company with a status page and a paid ops team to a person who has a day job. For the folks who already run a NAS and have actually restored from a backup, not just configured one, that trade is clearly correct, and they know who they are. For everybody else, "I own the data" quietly means "I am now the single point of failure."

The saves a local-first app cannot reach

There is a second gap, and it is bigger than the first.

Open your phone and think about where you actually save things now. You are not copying URLs into a self-hosted web app. You are tapping the bookmark icon on a post in X, hitting save on a Reddit thread, tapping save on a LinkedIn article. That is where saving happens now, inside the platform, one tap, twenty times a week.

Local-first bookmark managers cannot see any of it. There is no export button on your X bookmarks. Reddit shows you roughly your last thousand saves and no more. And these saves are pointers, not copies, so when the original post is deleted your bookmark quietly rots.

So the sovereign, private, offline library you built contains the twelve links you were motivated enough to file by hand. The four hundred things you actually saved are still trapped in three apps that do not care about them.

Escapable and machine-readable beat local and cloud

I think local-versus-cloud is the wrong axis to organize your choice around. Two other properties predict whether a library survives and stays useful, and they cut across both camps.

Escapable. Can you get everything out today, in a format another tool will read, without asking permission? Not "is there an export feature buried in settings." Have you run it? A cloud app with a one-click complete export is more escapable than a self-hosted app whose data sits in a schema only it understands. Pocket's failure was not that it was cloud. It was that 35 million people had never tested the exit.

Machine-readable. Can something other than the app's own search box read your library? For the last twenty years this did not matter much. It matters enormously now, because the thing you most want to do with a decade of saved links is ask an AI about them. A library your agent cannot reach is an archive, not a tool. This is what MCP exists to solve, a standard way for an AI agent to read a data source directly.

A private SQLite file nothing can read is sovereignty with nothing to show for it. You own it completely and it does nothing for you.

Where I land

I build ContextBolt Bookmarks, so let me be straight rather than clever. It is not local-first. Pro syncs your saves to encrypted cloud storage. If you want the seven ideals in full, run Karakeep. I mean that. It is a good piece of software and the people building it are serious.

It optimizes for the two gaps above instead. It captures automatically from X, Reddit, and LinkedIn, which is where saving actually happens and which no local-first tool reaches. It AI-tags every save with a topic so you find things by meaning rather than remembering a keyword. And Pro ($6/month) gives your library a personal MCP endpoint, so Claude, Cursor, and Windsurf can query your saves mid-conversation. The free Basic tier holds 150 bookmarks with the same tagging and semantic search.

That is a trade, and I would rather name it than pretend it away. If vendor independence is the thing you care about most in the world, this is the wrong tool and you should not buy it.

What I would push back on is the idea that self-hosting settles the question. It answers one risk loudly and leaves the other two untouched. The library still has to be findable, and it still has to be readable by the machine you now ask everything.

Local-first got the diagnosis right. The prescription is still being written.

If you want the longer version, with the full seven-ideal scorecard and the self-hosted graveyard nobody talks about, I wrote it up here: local-first bookmark managers.

What Competitor Monitoring Looks Like When It Judges the Change for You

David Hamilton — Mon, 06 Jul 2026 14:29:38 +0000

Most competitor monitoring tools have the same flaw. They tell you something changed, then hand the thinking back to you.

You get a red-highlighted diff in your inbox. A rival's pricing page moved. Great. Was it a real price change, or did they swap a testimonial and bump the copyright year? You open the tab, squint at the two versions, work out that it was nothing, and close it again. Do that for five competitors across pricing, homepage, changelog, and sitemap, and the tool that was supposed to save you time is now a second inbox you dread.

The data was never the hard part. Judging it was. And judging it is exactly the part a raw diff refuses to do.

Here is the workflow I moved to instead, and why it stuck.

The idea in one line

Move the monitoring into the AI agent you already work in, and let the agent do the judging.

That is what competitor monitoring with AI actually means once you strip the hype off it. Not "a dashboard with a chatbot bolted on." An assistant that watches the competition, decides what is signal and what is noise, and tells you in plain language what a change means.

What changes when the tool judges

A change detector can only point. It says "this pixel is different." An AI monitor reads the change and calls it. Cosmetic churn dies silently. A real move arrives with four things:

what changed
what it means
a link to the page
a suggested response

That last one is the part a dashboard structurally cannot reach. A dashboard does not have your files, your voice, or your product. An agent does. So it does not stop at "Acme raised their Pro tier from $29 to $39." It can go on to "here is the pricing-page tweak that presses that gap, want it in review." The alert becomes a first draft.

I have started calling that last step the counter-move, because "alert" undersells it. The whole reason to watch a competitor is to do something about what you see. Every other tool stops one step short of the only step that matters.

What is actually worth watching

Not everything. Five surfaces carry almost all the real signal for a software competitor:

Pricing pages. The highest-signal page there is, and the worst one to point a dumb detector at (currency toggles, A/B tests, and rotating promo banners all trip a raw diff).
Homepage. Positioning shifts. A headline moving from "for solo founders" to "built for teams" is a strategy telegraph.
Changelog / releases. What they are shipping, and how fast.
Sitemap. Unannounced pages show up here before they show up anywhere else. This is how you see a launch coming.
Search footprint. The terms they are starting to rank for tell you where they are aiming next.

The judging is what makes watching five surfaces across five competitors survivable. Without it, you drown.

Why inside the agent, specifically

Because the monitoring and the reaction stop being two separate jobs. The thing that spots the move is the thing that drafts the response, in the same conversation. No exporting a diff, no pasting it into a doc, no writing the counter-move from scratch an hour later when the urgency has drained out of it.

It does not replace an enterprise competitive-intelligence platform if you have a sales team and an analyst to run a battlecard program. It replaces the gap most founders actually live in, which is "I know I should watch my competitors and I never do, because every tool I tried became noise."

How I set it up

I use ContextBolt Radar. You name up to five competitor domains once. It checks their pricing, homepage, changelog, sitemap, and search footprint every night, judges each change, and emails one briefing every Monday. There is no dashboard. When nothing meaningful happened, it stays quiet, which turns out to be most weeks and is the point. Any time you are curious you just ask your agent "what did my competitors do this week." It runs inside Claude, Codex, or Cursor, and it is $39 a month.

The takeaway

Competitor monitoring was never a detection problem. Detection is easy and mostly free. The expensive part is judgment, and the only useful part is the response. Put both of those where you already do your thinking, and watching the competition stops being a chore you skip.

If you want the longer version, with the two-kinds-of-monitoring map and the honest limits, I wrote it up here: competitor monitoring with AI.

What Is an SEO MCP Server? (And Why I Stopped Opening a Dashboard)

David Hamilton — Tue, 30 Jun 2026 15:18:15 +0000

For two years my SEO workflow was the same loop: think of a question, open a browser tab, log into a dashboard, click around, export a CSV, paste it somewhere my AI assistant could read it, then ask the actual question. The dashboard was the bottleneck, not the data.

So I moved the data to where I already work. These days I ask Claude a keyword question and it answers from live SEO data directly, no tab, no export. The thing that made that possible is an SEO MCP server.

Here is what that actually means.

MCP in one paragraph

MCP (the Model Context Protocol) is an open standard that lets an AI assistant call external tools in a structured way. If you have used a "connector" in Claude or Cursor, that is MCP underneath. An MCP server exposes a set of tools, the model decides when to call them, and the result comes back as context the model can reason over. It is the difference between pasting a spreadsheet into a chat and letting the assistant fetch the numbers itself.

So what is an SEO MCP server?

It is an MCP server whose tools are SEO operations instead of, say, file reads or calendar events. A good one gives the model things like:

keyword research and difficulty scoring
SERP results and ranking data for a query
domain and competitor overviews
backlink data (referring domains, gap analysis)
Google Search Console data for your own site
AI visibility, how often your brand shows up in ChatGPT and Google's AI answers

The model calls those tools mid-conversation. You stay in one window and ask follow-ups in plain language: "compare the difficulty of these five terms," "which of my pages is closest to page one," "what does the top result for this query have that I don't." The assistant runs the lookups and reasons over the results together, which is the part a dashboard cannot do because a dashboard does not know what you asked last.

Why this beats the dashboard for day-to-day work

Three reasons it stuck for me:

No context switching. The question and the answer happen in the same place I was already thinking.
Composability. Because the model can chain tool calls, "find my striking-distance pages, then pull the SERP for each, then tell me which is most winnable" is one request, not forty clicks.
It writes as it analyzes. The assistant that just pulled the data is the one drafting the brief, the meta description, or the internal-link plan off the back of it.

It does not replace a full audit suite for enterprise teams. For a solo founder or a small team that lives inside an AI assistant anyway, it removes the most annoying step in the loop.

How I set it up

I use ContextBolt SEO. It is a hosted SEO MCP server: you add one connector to Claude, Cursor, or Codex, and the SEO tools show up. The data is DataForSEO under the hood (the same provider behind a lot of SEO products), so it is real keyword, SERP, and backlink data, not a model guessing. Search Console connects read-only, and it keeps a small memory layer so your past lookups are still there next session. It is $35 a month, which is what pushed me off the bigger suites for this particular workflow.

If you want to try the concept without paying, you can wire up the public DataForSEO MCP yourself and point your assistant at it, that is the DIY version of the same idea. I went with the hosted one because I did not want to babysit credits and config.

The takeaway

An SEO MCP server is not a new kind of SEO tool. It is the same data, delivered to the place where you already ask questions. Once the analyst lives inside the assistant, "open the dashboard" stops being step one, and that turns out to be most of the value.

If you want the longer version with the exact tools and prompts, I wrote it up here: SEO MCP server.

The MCP Servers I Actually Use With Claude in 2026

David Hamilton — Sat, 30 May 2026 20:28:20 +0000

The MCP ecosystem went from a handful of servers to thousands in under a year. Most of them are demos you connect once and forget. A few have quietly become part of how I work every day.

This is the short list that earned a permanent spot in my Claude setup as a solo founder, grouped by what I am actually trying to get done. No affiliate links, no rankings for the sake of it. Just the ones I would reconnect first on a new machine.

The two every setup needs

Filesystem (the official server) lets Claude read and write local files. Boring, essential, and the first thing I connect anywhere.

GitHub brings issues, PRs, and code search into the chat. If you write code, it is the highest-leverage connection after filesystem.

Marketing and growth

This is where MCP stopped being a novelty for me and started saving real hours.

The Google Search Console MCP pulls my live query and impression data into Claude, so I can ask "which pages slipped this week" and get an answer without opening the GSC dashboard.

The Google Analytics MCP server does the same for GA4: sessions, events, and conversions, all queryable in plain English.

If you run sales, the HubSpot MCP server lets Claude read and update contacts, deals, and companies. That turns "draft a follow-up for everyone in the pipeline who went quiet" into a single prompt.

Connecting all three means one question can span search data, analytics, and CRM, and Claude stitches it together. That is the part that still feels like magic.

Automation glue

The n8n MCP server is the one I reach for when a workflow needs to run on a schedule instead of whenever I happen to be in a chat. Weekly digests, smart routing, alerts. n8n already connects to almost everything, and MCP lets Claude drive it.

Knowledge and memory

Claude forgets everything between chats. These servers fix that.

Obsidian and Notion servers expose your notes so Claude can search them and write back.

ContextBolt (full disclosure: I built this one) gives Claude semantic recall over the things I save from X, Reddit, and LinkedIn. I save a thread, and three weeks later I can ask "what was that take on pricing I saved" and get it back with the source. It exists because I kept saving things and never finding them again.

How to pick

Two rules that have served me well:

Connect for a job, not for a demo. A server you use once is clutter.
Read the setup notes before you wire up auth. Half of these put a token in a config file or a URL, and the gotchas vary by server.

That second rule is why I keep a running directory of the best MCP servers with per-server setup steps, auth notes, and the gotchas I hit, sorted by category. It started as my own notes. Now it is a public MCP server directory you can browse by job instead of scrolling one giant list.

If you are just getting started, connect filesystem, then add one server for the job in front of you. Build from there.

I deleted the chat feature from my own AI product. Here's what I built instead.

David Hamilton — Wed, 06 May 2026 22:09:56 +0000

I deleted the chat feature from my AI product.
The irony writes itself. A small Chrome extension whose entire purpose is bringing AI to your saved content. The first thing I cut was the AI-shaped feature.
It was the easiest call I've made on this build.
Three reasons. Each one obvious in hindsight.
API costs. A back-and-forth chat conversation eats £1-2 a month in tokens per active user. My Pro tier is £4 a month. The maths doesn't work the day you launch. It only gets worse with scale.
Product bloat. A chat box is the kind of thing you build because every other AI product has one. It looks like the AI feature. It isn't.
V2. If users actually want to chat with their bookmarks, they'll tell me. I'd rather build it then than guess now.
The product is called ContextBolt. It captures your bookmarks from X, Reddit, and LinkedIn. It auto-tags each one with Claude. And then it does something most products in 2026 still don't.
It exposes itself to Claude.
Pro users get a personal MCP endpoint. They paste one URL into Claude Desktop. From that moment on, Claude can search their entire bookmark library mid-conversation. You ask Claude something. Claude reads your saved content. The answer arrives with the context already in it.
The dashboard I built first turned out to be the legacy interface. The MCP endpoint is the actual product.
That's the irony resolved. The chat box was never the AI part. The integration was the AI part. I just couldn't see it until I deleted what I thought it was.
Here's the part I find harder to explain.
I'm one person. I have a day job. I get about ten hours a week on this thing, mostly evenings and weekends. The amount of code in this product is not the amount of code one person could write in ten hours a week.
I didn't write most of it.
Claude did.
I use Claude Code. I describe what I want in plain English. Claude writes the service worker. Claude writes the Cloudflare Worker. Claude writes the React dashboard. Claude writes the SQL migrations. I read what comes back, push back where the taste is off, and ship it.
Two days ago Google approved the extension on the Chrome Web Store. I downloaded my own production build. Within an hour I'd found four bugs in real-world testing. The LinkedIn dashboard didn't refresh on save. The X popup showed a scraped count instead of a deduplicated one. The auto-scroll stalled at twenty bookmarks. The licence-key save flow failed silently.
I described each symptom out loud. Claude found the wrong file (a content script that was dead code, while the loaded one had no listener). Claude wrote each patch. We shipped five extension versions and two worker deploys that evening. I never opened a debugger.
That is what working with Claude actually looks like in 2026. It is not autocomplete. It is a colleague who reads the whole codebase faster than you can blink, fixes the thing, and writes the commit message while it's at it.
The infrastructure is the other surprise.
The whole product runs on Cloudflare. Pages for the website. Workers for the API. D1 for the database. KV for the rate limits. Vectorize for the semantic search. There is no AWS bill. There is no Vercel bill. There is no managed database bill.
Including Claude API spend, the entire stack costs me under £5 a month at current usage. I keep waiting for that to be a lie. So far it isn't.
The marketing flywheel is the same recursive shape.
Thirty-three blog posts on the site. Sixty-six programmatic SEO pages. Every post drafted with Claude. Every meta description checked by Claude. Every internal link suggested by Claude. The site's scheduled tasks run with Claude reading my Search Console and writing the next thing to fix.
I review. I edit. I ship.
The asymmetric stack is the only reason a one-person, ten-hour-a-week build can keep up with funded teams. Claude does the parts that scale linearly with effort. Writing. Debugging. Testing. Drafting. I do the parts that don't. Taste. Decisions. Picking what to ship. Picking what to delete.
I keep coming back to that last one.
The chat box was never the AI part. It was the legacy UI we used while we figured out what the AI part actually was. The AI part is the integration. The AI part is your existing tools getting access to context they didn't have before.
Most AI products in two years will look like ContextBolt. A small piece of software that does one thing well and exposes itself to whatever model the user already pays for. The product team doesn't have to ship the chat box. The user already has one.
That's why deleting the chat was easy. Once you see it, you can't unsee it.
ContextBolt is live on the Chrome Web Store today. The site is at contextbolt.com. If you save more than you read, you'll feel it the first time Claude finds something for you that you'd already given up on.
I'd love to know what you'd connect it to.