I added observability to my AI book app. It found two slow paths my own logs missed.

Sai Varsha Katikireddy — Fri, 06 Nov 2026 02:33:01 +0000

I built BookDNA, an AI book recommender that finds books by trope, setting, and tone, and checks every pick against Open Library so nothing is made up. I’d already spent a lot of time on speed: I timed every stage, tested 10 variants, and cut the time to the first result from about 30 seconds to 3.

So I thought I knew where the time went. Then I added tracing with OpenTelemetry and SigNoz, and within minutes it showed me two things I’d missed.

What I set up

I used OpenTelemetry’s zero-code instrumentation for FastAPI and httpx, sent traces to SigNoz Cloud, and added a few custom spans by hand: one for each Open Library lookup, each Claude call, and each recommendation shelf.

Two decisions mattered most:

No prompts in my traces. Common LLM auto-instrumentation records prompts and responses by default. I only record the model, token counts, and the finish reason, never the text or my API key.
One trace per search. A single search makes three separate requests from the browser. I generate one trace ID per search in the frontend and send it on all three, so SigNoz shows the whole search as one timeline. (SigNoz shows a “Missing Span” at the top, because the browser never sends its own span. That’s expected.)

Finding 1: my homepage could take 26 seconds

The “For You” shelf on my homepage blends a reader’s recent searches into personal picks. I had never timed it. The trace showed the request took about 26 seconds, and one Claude call took 23 of them. It’s an older code path: it waits for 18 books before returning anything, while my search page already streams results as they’re ready.

Finding 2: a 13-second gap in every search

My first shelf arrives in about 5 seconds, which is what my speed work was about. But the trace showed a quiet gap of about 13 seconds before the other three shelves arrived. They all come from one coordinated Claude call (so the shelves don’t repeat each other), and the validation checks under each shelf were fast. The real wait was Claude writing about 24 books with reasons.

My timing logs measured the first shelf. The trace showed the whole experience.

What tripped me up

I kept a friction log while setting it up. A few highlights:

Keeping the ingestion key in a .env file isn’t covered in the docs. The instrumentation reads settings before my app loads its .env file, so I start the server with dotenv run.
On Windows, opentelemetry-instrument returns the prompt immediately while the server keeps running in the background. Confusing the first time.
The setup command wanted about 20 instrumentation packages. I only needed FastAPI and httpx, so I pinned those.

What’s next

Streaming the For You shelves one at a time, the way search already works, then comparing the before-and-after traces in SigNoz.

I built this with Claude Code, making the decisions and reviewing every change.

Code: https://github.com/ksaivarsha/bookdna

I turned my book recommender into an AI app in a day. Here are the two bugs that taught me the most.

Sai Varsha Katikireddy — Wed, 14 Oct 2026 23:33:41 +0000

I read a lot of fantasy, especially romantasy, and I’ve always wanted to ask an AI for something specific, like “enemies to lovers in a fae court,” and get back real books, not made-up titles.

So I built BookDNA: it reads a book’s “DNA” (its tropes, setting, and tone), recommends books that match, and checks every single suggestion against Open Library, so it never recommends a book that doesn’t exist.

This week I turned it into an MCP server using mcp-use and deployed it on Manufact Cloud. Now any AI chat that supports MCP can use it.

What I built

Four tools an AI can call: search_book, get_book_dna, recommend, and recommend_by_tropes. The recommend tools return a small app that appears right inside the chat: a parchment shelf of book covers, each with a one-line reason it was picked.

My favorite moment: I tested it in Manufact’s Inspector chat using a GPT model, not Claude, and it worked perfectly. One server, any AI. That’s the promise of MCP, and seeing it happen was really satisfying.

Bug 1: only one cover showed up

My first shelf showed one cover and four broken images. Every book had a valid cover link, so the data wasn’t the problem.

It turned out that older Open Library covers redirect to a different server on archive.org. MCP App widgets run with a strict security policy that lists which sites they’re allowed to load images from, and I’d only allowed Open Library. The redirected images were silently blocked. The one cover that loaded was newer and didn’t redirect.

The fix was to allow archive.org too. I also added a fallback: if a cover ever fails, the card shows a parchment “title page” with the title and author instead of a broken image.

Lesson: if your widget loads images, allow every site in the redirect chain, not just the first one.

Bug 2: everyone shared one rate limit

The server is public, so I added rate limits to protect my AI budget, including a per-user limit. Testing it against the live deployment showed something I didn’t expect: the platform’s proxy rewrites the header that identifies the user, and the address I was reading belonged to the proxy, not the user. So every user was sharing one limit.

One small change fixed it, but I only found it because I tested against the real deployment instead of trusting my local setup.

Lesson: test anything that depends on request headers against your real deployment.

How I built it

I built this with Claude Code. I made the decisions, reviewed every change, and tested it myself, and I kept a “friction log” of everything that confused me along the way. A few items are already in this post.

Try it

GitHub: github.com/ksaivarsha/bookdna
MCP server: https://calm-wave-h30fs.run.mcp-use.com/mcp

If you build MCP Apps, I’d love to hear what tripped you up.

DEV Community: Sai Varsha Katikireddy

I added observability to my AI book app. It found two slow paths my own logs missed.

I turned my book recommender into an AI app in a day. Here are the two bugs that taught me the most.