For years, the economics of software pushed toward scale. Building something meant building it for many people, because the upfront cost was high and the marginal cost was low. You wouldn't 3D print a fork when you could buy one cheaper.

But what if you need a fork with a specific bend? One that fits your hand, your drawer, your weird way of eating?

I built a small system for tracking book recommendations. It connects Claude to a Google Sheet through a Model Context Protocol server, so I can get recommendations and manage my reading list conversationally—from my phone, my desktop, wherever. It took about three hours. It works for exactly one person: me.

That's the point.

My problem with book recommendations is personal in a way that Goodreads can't solve.

Some books just sit wrong. You're fifty pages in and something feels off, but you can't say what. Maybe the author's worldview is leaking through in ways you don't have the context to name yet. By the time you figure out why it's bothering you, you've already spent the hours.

And non-fiction is worse. Half the praise on book jackets is paid PR. Separating signal from marketing is real work. Not to mention separating well researched, peer-reviewed work from experts from even the most elaborate grifts. This work is the entire premise of the podcast If Books Could Kill.

What I wanted: a way to have an ongoing conversation about what to read, informed by everything I've liked and disliked and why. Something that remembers. Something I can pull up in a bookshop when I'm staring at a cover I don't recognize.

No app does this. So I built one that does.

Three ways to do this

Start by just talking to Claude. Tell it what you liked and why. Send it a photo of a book cover in a shop and ask if it's for you. This works better than you'd expect, and it's a good way to figure out if the whole approach is useful before building anything.

If it is, you'll hit the limits. Claude has great memory now, but finding past recommendations and tracking them over time is a pain. There's no good way to browse what you've saved. And you can't say "add this to my shelf" and have it actually do something structured—fetch the cover, generate a bookshop link, slot it into a list you can reference later.

So you build an MCP server. Now Claude can read and write to a real database. The conversation becomes an interface to an actual system. I can ask for recommendations from my phone and it knows what I've read. I can add a book and it pulls in the metadata automatically. The data lives somewhere I can see and edit.

You could go further. Wrap the whole thing in a proper app—accounts, auth, a custom chat interface. But now you're maintaining a product. Fixing bugs. For a tool only you use, that's probably not worth it.

I stopped at level two. Enough structure to be useful, not enough to become a hassle.

The repo

I've open-sourced the MCP server here. It handles a handful of operations: add a book, update its status, list what's on the shelf, look up covers. Nothing fancy. It should be reusable out of the box, but setting up GCP and the Google Sheet took some figuring out and needs to be set up for it. You can fork it and adapt it, or just feed it to Claude as a starting point for your own version.

I've also built a very simple frontend that turns the Google Sheet into a simple page. This is great for browsing when I want to pick something new to read. This way I never really need to open the Google Sheet. I used a simple Apps Script (Extensions → Apps Script) written by Claude to create a JSON of the Google Sheet and routed the request via a Cloudflare Worker to get it to work.

You don't need to ship

As I've worked with startups, I've watched the same pattern over and over: people overbuild. They get attached to their ideas. They treat code as precious. Instead of looking at problems and tinkering, they put value on the artifact—the idea, the repo, the thing they made.

That instinct made a bit more sense when code was expensive. You wouldn't throw away something that took weeks to build. Even if starting over was the best choice.

But tools like Claude Code are changing that. I built this in an afternoon. If it stops being useful, I'll delete it and build something else. The code isn't the point. The problem it solves is the point.