Claude Code in the Wild: From 800 Scattered Files to a Queryable System

Guest Speaker

Meet Marina

Marina Ghilchik

GTM Practitioner and Bootprint Alum

Marina Ghilchik works across the GTM space and has been part of the Bootprint network since going through the original Clay Bootcamp. She built this document intelligence pipeline from scratch with no engineering background, using Claude Code to debug her way through expired OAuth tokens, duplicate vector IDs, and a pagination cap that was silently dropping her mail. She has since deployed the same architecture a second time, on someone else's machine, on Windows.

Connect on LinkedIn

Session Overview

What was covered

📚

Document Intelligence Pipeline

A four-stage system that ingests, summarises, retrieves, and queries 800+ documents automatically, built as a non-engineer using Claude Code.

🔒

Privacy-First Architecture

Local embeddings, read-only OAuth scopes, and nothing leaving your machine at index time. Every design decision tied to a real privacy constraint.

🤖

Smart Model Routing

Haiku for bulk extraction, Sonnet where reasoning is needed, Vision for scans. An order of magnitude cheaper than sending everything to the frontier model.

💬

Two Query Interfaces

Terminal REPL for deep cross-document pattern queries. Claude Project for conversational lookups. Pick the interface that matches how hard the question is.

The Build

The four-stage pipeline

Ingest → Summarise → Retrieve → Ask

Ingest

Connect and pull

Read-only Gmail API watches five defined senders. Each run pulls emails plus every attachment, renames them to YYYY-MM-DD_Sender_Subject, and files them to a structured Google Drive folder.

Idempotent by message ID, so nothing gets processed twice
One-day query overlap on incremental runs to catch re-reads
Scheduled via launchd; one-click Mac button for manual re-sync

Summarise

Extract and track

Every document goes through the Claude API with a fixed structured schema: summary, category, and obligations by party. The output batch-appends to a Google Sheets tracker with source links back to Drive and Gmail.

Haiku for the bulk pass, Sonnet where reasoning is needed
Vision model for scans and images
Schema stability matters; free-text summaries don't aggregate

Retrieve

Index the full text

Text is extracted from PDFs, Word docs, and spreadsheets, chunked with overlap, then embedded locally using all-MiniLM-L6-v2. Around 2,177 chunks land in a persistent ChromaDB vector store. No document text leaves the machine at index time.

Retrieves top-k = 12 chunks per query, then synthesises
Chunk metadata stored with the vector for filter queries by sender, date, or tag

Ask

Two ways to query

For deep pattern work: a terminal REPL and CLI runs Python scripts against the full vector index. For quick conversational lookups: a Claude Project reads the Google Sheets tracker directly in plain English.

Example query: "Give me all instances from the past six months where they contradicted themselves on childcare"
Returns a list. Take it to the browser Claude to work through it.

Full stack

LanguagePython 3

LLMClaude API (Sonnet, Haiku, Vision)

Vector storeChromaDB, persistent, cosine

Embeddingsall-MiniLM-L6-v2, 384-dim, local

Extractionpdfplumber, python-docx, openpyxl

Integrationsgoogle-api-python-client

AuthOAuth 2.0, token per service

Schedulinglaunchd (macOS), Task Scheduler (Windows)

Swap the sender list and the system prompt and the same four layers become a GTM correspondence engine, a customer-signal tracker, or a due-diligence pipeline. Marina has already deployed it a second time, on someone else's machine, on Windows.

Mental Models

How Marina thinks about building this stuff

Buy before you build

Marina checked NotebookLM (caps at 50 sources), Obsidian (PDF-blind, Markdown-native), and DevonThink (a search vault, not a pipeline) before writing a line of code. She built because nothing fit the requirements. Not because she wanted to code.

Scope, not policy

Use gmail.readonly. The OAuth token physically cannot send, reply, or delete. That constraint is enforced at the API level, not by application logic. If you're handling sensitive data, lock down the scope first.

Two front doors, one system

The tracker in a Claude Project handles conversational questions. The terminal handles deep cross-document pattern queries. Pick the interface based on how hard the question is. You don't need one system that does everything well.

Start with the problem, not the code

Tell Claude the problem and what you want. Then figure out how to build it together. That's how Marina built something this complex without a formal engineering background. The debugging was real, but the starting point was always a clear question.

From the Session

Questions Marina answered

What is a vector library, and why does it matter for pattern recognition in large documents?

Vectors transform text into mathematical representations in a shared space. Related concepts cluster together. When you ask "find all contradictions on the topic of childcare," the system retrieves chunks that are semantically close to that question, across thousands of documents, not just keyword matches. The tracker holds summaries. The vector index holds the full text. You need the second one for anything that requires cross-referencing.

How do you actually query for contradictions? How does that work in practice?

Two interfaces. In the terminal, you run a Python script against the vector database. You ask something like: "Give me all instances from the past six months where they contradicted themselves on childcare." It returns a list. Then you take that output to the Claude browser interface to work through it. The Google Sheets tracker is good for lookups like "when did they say X." The terminal is where the pattern work happens.

Why not just use NotebookLM?

The corpus is too large. NotebookLM caps at roughly 50 sources. 800+ files doesn't fit, not even close. The constraint wasn't a preference, it was a hard requirement. Same for Obsidian, which is Markdown-native and can't really search inside PDFs or scans. DevonThink was the closest fit but it's a search vault, not a pipeline. No scheduled ingestion, no summarisation, nothing to build on.

Why not put the code on GitHub?

Because the data is private and the stakes are too high to trust the visibility settings every time. For anyone handling sensitive corporate data, Marina's recommendation is clear: prompt Claude carefully, or keep it off GitHub entirely. If you do use GitHub, check your permissions before you push.

Tools

What went into the build

Claude API

Sonnet, Haiku, Vision

Used

ChromaDB

Local vector store

Used

Python 3

Core language

Used

Gmail API

Read-only ingestion

Used

Google Drive API

Structured file storage

Used

Google Sheets API

Document tracker

Used

pdfplumber

PDF text extraction

Used

python-docx

Word doc extraction

Used

openpyxl

Spreadsheet extraction

Used

all-MiniLM-L6-v2

Local embeddings, 384-dim

Used

launchd

macOS scheduling

Used

Claude Code

Built the full pipeline

Used

NotebookLM

Capped at 50 sources

Evaluated

Obsidian

Markdown-native, PDF-blind

Evaluated

DevonThink

Search vault, not a pipeline

Evaluated

From 800 scattered files to a queryable system

Build like Marina. Learn Claude Code in a week.

Meet Marina

Marina Ghilchik

Every question started from zero

What was covered

Document Intelligence Pipeline

Privacy-First Architecture

Smart Model Routing

Two Query Interfaces

The four-stage pipeline

Connect and pull

Extract and track

Index the full text

Two ways to query

Full stack

How Marina thinks about building this stuff

Buy before you build

Scope, not policy

Two front doors, one system

Start with the problem, not the code

Questions Marina answered

What went into the build

Everything from the session

Want to build something like this yourself?

Questions about Bootprint?