Like most developers with a growing stack of unread physical books, I suffer from a bad case of choice paralysis. Your bookshelf looks at you, you look back at it, and you end up scrolling on your phone instead of reading.
To solve this, I built TBRly—a lightweight web application that allows users to snap a photo of their physical bookshelf, instantly parse the titles, and drop them into a "Deathmatch Arena" where a native AI pipeline forces a choice based on your current vibe.
But this isn't a post about marketing a book tool. It’s a post about why I stripped out the abstraction layers and built an AI engine natively.
The Architecture Pitfall: The Framework Trap
When I started mapping out the backend, the default path seemed obvious: grab an AI orchestration framework, chain a few prompts together, and deploy.
But as a software engineer who values performance and predictability, I ran into immediate friction. Standard frameworks add significant middleware overhead, hide the raw payload structures, and make debugging non-deterministic API behaviors a black box.
For a consumer utility application where latency and snappy rendering matter, I didn't want heavy dependencies. I wanted raw, blazing-fast speed and total control over the context window.
So, I built native abstractions directly over the Google GenAI SDK.
Inside the Core Engine
TBRly relies on two critical technical pillars to take a messy physical reality and turn it into an actionable decision:
1. Vision parsing without heavy OCR pipelines
Instead of running an expensive, multi-stage pipeline that extracts raw bounding boxes, matches text fragments, and pipes strings to a separate model, TBRly passes the user’s phone image directly to a multimodal model.
By utilizing strict structured JSON outputs, the model receives the raw pixel buffer and returns a clean, validated array of objects containing only title and author. If the image is blurry, it flags it immediately without wasting downstream compute cycles.
2. The Vibe Prompting Architecture
Standard category matching (e.g., "Sci-Fi" vs "History") is boring. TBRly introduces a feature called Vibe Prompting.
Instead of searching indexed metadata tags, users can input abstract text strings like “Give me a cozy, rainy-day psychological mystery” or “A fast-paced, mind-bending cyber thriller.”
The backend dynamically wraps this intent into an isolated context block, injects the user's parsed bookshelf list, and runs an internal selection matrix natively to output the final matched book and a single, punchy justification string.
The Stack
- Frontend: Next.js (optimized edge execution for fast client rendering)
- Backend: FastAPI (async routing to handle asynchronous API streaming seamlessly)
- AI Layer: Native Gemini integration via Google GenAI SDK (zero third-party wrapper lag)
Lessons from the Trenches
Building in public alone means running into immediate structural hurdles. Here is what this project taught me so far:
- Data Gravity is Real: When handling user images and state, keeping the compute payload close to the model endpoint is the difference between a 4-second loading spinner and a sub-second response.
- Lean is Resilient: Bypassing massive middleware wrappers forced me to explicitly write my own error-handling logic for rate limits and context safety filters. The result? A highly deterministic codebase that doesn't break when a wrapper package updates its minor version.
The platform is live, 90% free, and currently navigating its early alpha stages. TBRly App
If you are an engineer who loves reading or someone who wants to tear apart my architectural choices, I’d love your feedback. How are you handling native LLM abstractions in your production side-projects? Let's discuss below!
Top comments (0)