Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.
Nine engineering books somebody swears by, a couple of long essays that get linked in every third design review, and sixty-odd internal blog posts and postmortems that nobody rereads.
I wanted a tool where you paste a design proposal, an ADR, a postmortem draft, and it comes back with: here is what is actually being proposed, here is the pattern underneath it, and here are the three places on the shelf where we, or someone smarter, already ran into this exact shape.
The obvious build is a vector database, an embedding pipeline, a chunker, a reranker, and a weekend.
I built it with none of those, in Go, on Gemini's free tier, and the retrieval side of it costs nothing to run.
You create a "store", upload documents into it, and Google chunks them, embeds them, and indexes them.
Then you attach that store to a normal generateContent call as a tool, and the model searches it by itself, mid-answer, and hands you back the chunks it used as groundingMetadata.
Storage is free. Query-time embeddings are free. You pay once at indexing time, at embedding prices, and then the chunks the model pulls in are billed as ordinary context tokens on the call you were already making.
On the free tier the store caps at 1 GB. My entire shelf, every book and every post converted to markdown, is 5.3 MB.
One Go binary. SQLite via modernc.org/sqlite, so no cgo. A REST client for Gemini with no SDK, because I wanted to log the exact request and response bodies verbatim, and SDKs love to hide those.
Before any of the clever parts, the corpus has to exist as text, and this cost me an evening.
The first tool I reached for was markitdown. It gave me headings, sort of, and it also gave me this:
Every word in the PDF glued to its neighbour. The embedding model does not know what "Theubiquityoffrustrating" is, and neither does the retrieval.
pdftotext fixed the spacing and threw away every heading, so a 300-page book became one undifferentiated scroll.
The one that won was pymupdf4llm. It looks at font sizes to decide what is a heading, keeps bold and italics, and its text extraction handled the spacing correctly on the same PDF.
Headings matter more than they look like they should here, because File Search chunks on whitespace with a token budget. A chunk that starts at a heading is a chunk that means something on its own. A chunk that starts mid-sentence in a wall of text is noise with an embedding attached.
I put the conversion behind make process-data so nobody on the team has to rediscover this. EPUBs, PDFs, and a sync of our blog repos, all into one postprocesseddata/ tree of markdown.
A File Search store lives inside the Google Cloud project behind the API key that created it.