Last week, I gave Claude access to my reading life.
Over the last couple of months, I’ve been building QuietReads, a purpose-built app for tracking my reading journey. The app is a virtual bookshelf with an AI assistant called Eko that helps me with recommendations, analysis, and acts as a sort of journalling partner as I read a book. I can add notes to a book, gather my thoughts and explore themes around reading. In short, it’s an app that I built because I was frustrated with performative social networks like GoodReads. QuietReads is a focused app that is built around my reading journey.
Over the last couple of days, I built an MCP server for QuietReads. MCP (Model Context Protocol) is an open standard for connecting applications to external data sources and tools. It was designed with AI assistants in mind, but at its core it provides a data-and-tool-focused approach to integration.
Any application that supports MCP can get authenticated access to a user’s bookshelf and notes via QuietReads’ MCP server. In practical terms, it means Claude (my AI assistant of choice), can now query what I’m currently reading, browse my to-read list, or pull up the notes about a particular book.
I wanted this because my reading life is useful context for how I write, work, and think. When I’m working through a problem with Claude, having my bookshelf and reading notes available allows me to bring together separate, but important parts of my knowledge.
While building the integration, I started thinking about the broader relationship between purpose-built applications and general-purpose AI tools.
Building a Single Purpose App
Before QuietReads existed, I tried using Claude directly as a reading companion. I set up projects, created dedicated chats, and worked with Claude to understand or explore books. While Claude is immensely powerful, this workflow always felt clunky.
Every conversation started from scratch or required careful prompt setup to establish context. There was no accumulated understanding, no sense of a reading journey unfolding over months. And, it was very likely that I would get distracted with whatever else was going on in my work-life when I opened Claude to ask about or to explore a book.
So I built QuietReads.
And building the app made me realize that with AI Assistants, it has become so much easier to build custom, single-purpose, and hyper-personalized apps.
QuietReads knows that I tend to read multiple books at once. It knows I’m currently working through Postman’s Technopoly alongside Elizabeth Bear’s Ancestral Night, bouncing between a critique of technology and a space opera. My conversations with Eko exploring Postman’s work, or exploring literary themes in Kiran Desai’s The Loneliness of Sonia and Sunny enriched my experience of reading those books. Eko also learns my preferences, has access to my library and can make excellent recommendations.
That kind of contextual depth is hard to recreate in a general-purpose tool, no matter how powerful the underlying model.
General Purpose vs. Single Purpose Apps
I do not have the resources nor the intention for QuietReads to compete with a general purpose app like Claude. I don’t have billions of dollars to build a foundation model, nor the engineering team Anthropic has assembled to build a compelling product. I pay a couple of hundred dollars a month for my Claude subscription because it is a powerful tool with amazing and rapidly improving capabilities.
It can search the web, write and execute code, do detailed analysis across domains, and act autonomously on multi-step workflows. These are things my humble book assistant will never do.
QuietReads is deliberately narrow. It knows about books. Claude is deliberately broad. It knows about everything, but making it an expert in any particular field takes a lot of work.
I connected them because I wanted Claude to have access to QuietReads’ context. Building this integration made me think carefully about both tools, and the place for domain-specific apps in a world with AI Assistants with amazing capabilities.
Claude and Eko Have a Conversation..
Here’s a scenario I keep thinking about. Claude, acting as an agent, runs a daily sweep of book review sites, new releases, and author backlists. It knows from QuietReads that I recently finished Yudhanjaya Wijeratne’s The Salvage Crew and have Pilgrim Machines on my to-read list. And it knows that I loved Nathan Fillion’s narration of Salvage Crew. It finds out when the audio-book version of Pilgrim Machines is coming out.
Claude then passes that information to Eko, along with context about my current reading patterns. Eko, which understands my preferences at a deeper level (that I like hard science fiction that engages with AI consciousness, that I’m on a streak of post-colonial literature, that I tend to alternate between dense non-fiction and page-turners), decides whether it should bump up Pilgrim Machines on my to-read list along with sending me a notification that the audiobook is now available on Spotify. Maybe it also adds some notes, perhaps a synopsis of the previous book, to help me get going.
Claude did what it’s good at: broad information gathering and synthesis across the open web. Eko did what it’s good at: applying deep, personal context to a decision.
This may seem like a trivial example, but the pattern – of applying powerful, but general capabilities, to specific workflows – makes sense.
Are we really in the SaaS-o-calypse?
Replace QuietReads with an HR application that has encoded fifteen years of onboarding workflows, benefits administration edge cases, and compliance with jurisdiction-specific labor laws. The code of that application manifests decades of institutional knowledge that a general-purpose AI agent may not be able to reproduce at an accurate enough level.
Now connect that HR app to a general-purpose agent via an integration layer like MCP. The agent can assist in workflows like performance reviews, résumé screening, or enforcing consistency in job descriptions. The gap between building an MCP server for a personal reading app and exposing a multi-tenant enterprise platform with access control, data residency, and audit requirements is real, and I don’t want to minimize it. But the architectural direction is the same.
The same pattern applies to accounting systems (decades of regulatory logic), project management tools (accumulated workflow optimization), healthcare platforms (compliance frameworks built through years of audit and iteration). These applications embed hard-won domain knowledge and assume liability when something goes wrong. That knowledge doesn’t become useless because a new technology appears.
Are we misplacing AI risk?
Last week saw a panicked sell-off of SaaS shares. SaaS valuations have compressed sharply: the industry’s average forward price-to-earnings ratio dropped from roughly 39x to 21x in four months, the steepest decline since the dot-com bust. HubSpot has lost more than half its market cap. ServiceNow has shed a quarter of its value in early 2026 alone.
The fear is straightforward: if AI agents can help build and automate customized workflows, why pay per-seat licenses for software that wraps those workflows in a UI?
While there has been a lot written about the future of software (Ben Thompson has a great take here), my take is that the threat to SaaS companies is real, but it’s a threat to their delivery mechanism, not to their accumulated knowledge.
The UI may become less important, but the data, the domain logic, the workflow intelligence remain critical. The companies that recognize this distinction early, that invest in becoming excellent context providers rather than clinging to their role as the place where work gets done, could be the ones that thrive.
To put it another way, if you make yourself indispensable, it doesn’t really matter how users interact with your services. They will still pay you. The hard question is whether your product’s value lives in the domain knowledge it encodes or in the UI it wraps around commodity workflows.
Product Strategy in the AI Era
If I were a SaaS product manager right now, I would think very carefully about how to integrate AI capabilities in my core experience. Every SaaS company is doing this, and the result is a dozen mediocre, context-limited AI assistants competing with general-purpose models that are improving on what feels like a weekly cadence.
The alternative could be to invest in a clearly documented, well-structured set of data and tools that general-purpose agents can consume (and pay for). Think of your application as an MCP or API-first context provider. The product decisions become: which data and tools do you expose, which do you keep behind your own experience, and where does your application’s judgment remain essential?
Your monetization shifts from “how many humans log into our UI” to “how much value does our context and domain logic create when consumed by agents acting on behalf of those humans.”
This could be a meaningful and challenging pivot. Per-seat pricing assumes humans are the primary consumers of your product. When agents become the primary interface, pricing needs to reflect the value of context provided, not the number of logins.
Feeding the Machine..
Building QuietReads and then connecting it to Claude made me wonder whether the future of software is a collaboration between narrow, domain-focused applications and powerful general-purpose AI agents. Purpose-built apps hold context. Agents provide reach and reasoning. The connection layer (MCP today, whatever comes next) is what makes them more than the sum of their parts.
For domain specific applications to survive and grow, they must make their context available, clearly, reliably, and with the domain intelligence intact with a reasonable monetization layer. The ones that try to be everything, to build their own agents, their own chat interfaces, their own general-purpose capabilities, will find themselves outpaced by tools built for exactly that purpose.
Eko doesn’t need to be Claude. Claude doesn’t need to be Eko. They need to talk to each other.