3 Million Pages In. 5,000 Out. Built in a Day, Runs on $50 a Month.
The funnel is the whole trick. The index that made it work got built a month earlier, for no reason other than I was tired of not finding things.
How I Turned 3 Million Pages Into a Deposition Search Tool in a Day
TL;DR: Three million pages of case material went into a set of indexes. Those indexes pulled out the 5,000 pages that actually mattered for one deposition. I built a search app over those 5,000 pages in a day with Codex. To be clear about what this is not: nothing here searches three million pages live. That’s Google-level engineering and I did not build it in Codex. The funnel is the whole trick.
The moment the old way breaks
You know the feeling. You’re in a deposition. The witness says something that contradicts testimony from two years ago, and you know it. You can feel it. You just can’t find it.
I’ve been working with a client on a major case for over a year. Over 50,000 documents. North of three million pages. Depositions, trial transcripts, declarations, exhibit lists, text messages, emails, judgments, property records, financial statements, photos, audio, video. Hundreds of witnesses and experts have testified or been listed to testify across multiple years, and the list of people who might still be called keeps moving.
Nobody holds that in their head. Neither does a paralegal with a binder.
What the client asked for
Two things.
First: instant search across the transcripts that mattered for one upcoming deposition. Type a word or a phrase, get back what was asked, how it was answered, and which document and date it came from. Sub-second. Fast enough to use live, mid-question.
Second: everything a given witness has ever said, summarized. Topics they touched. Places where their story shifted.
A year ago I’d have told this client the first one was a vendor project and the second one probably wasn’t worth attempting.
The pre-work nobody talks about
A month earlier I’d built an agent in Codex that read every document in the corpus and pulled out every person named and every key topic, then wrote all of it into a SQL database sitting on my laptop. A few hours to run. I didn’t build it for this project. I built it because I was tired of not being able to find things.
That’s the part people skip when they tell these stories.
So when it came time to pull the specific documents, I didn’t go hunting. I ran a query. Thirty seconds to identify and copy every relevant file into a new folder. An associate doing that same pull by hand would have spent countless hours on it.
Three million pages in. About 5,000 pages out. Those 5,000 were what the app would actually search, and that reduction is why any of the rest of this was possible.
The index is the thing. Everything after it was fast because of it.
Building it
I described what I needed to Codex, running GPT-5.6 Sol on max reasoning. Encryption at rest and in transit. Multi-factor authentication. Results with page numbers, source text highlighted inside the original document, one click through to the underlying file.
Prototype to working, tested app in under a day.
Running locally on my MacBook Pro, searches came back in about a tenth of a second across those 5,000 pages. But the client needed remote access, and that part was non-negotiable, so running it on my laptop was never going to be the answer. Cloud took several more hours. Most of that wasn’t building, it was tuning: sizing the servers and the database against how fast the search came back and what it cost to run, then testing, then resizing, then testing again until the numbers stopped fighting each other. I will say the speed of the current models made that loop tolerable in a way it wouldn’t have been last year. I landed on sub-second response times, which was the number that actually mattered. A second is fast enough to keep your rhythm in a deposition. Three seconds isn’t.
Search “holiday” and you get every passage about holidays. Search “Thanksgiving” and you get those same passages back, because semantic search understands the two are related.
Here are some screen shots I built from a demo system to be able to highlight to clients how this can work. The first three shots show the interface and how you can narrow search results by witness or document type. The final image shows the results when searching for “holiday” - you can see how the results and document highlights.
What it costs
I already had a Vercel subscription (from other client apps I’ve deployed). The data sits in Supabase. If I billed the client for this deployment it would run about $50 a month, including the API cost of the searches themselves.
Now put that next to what you’re paying today. Mainstream e-discovery platforms charge somewhere between $11 and $30 per gigabyte per month just to host data, before seat fees and processing.
Don’t fire your e-discovery vendor over this. Those platforms handle chain of custody, production, privilege logs, defensible workflows. This app does none of that and was never meant to.
The point is narrower and more useful. The distance between “buy the platform” and “build the specific thing you need” collapsed, and most firms are still pricing their options against the old distance.
The question you should have asked four paragraphs ago
If you’re a lawyer, something has been bothering you since I said the word “cloud.” Good. Ask it out loud.
Start with what actually went into the app, because that decision came before any of the security work. Transcripts. That’s it. Not the full case file, not medical records, nothing outside the set of documents the client needed to search. Scoping that narrowly was deliberate. The smallest set of documents that answers the question is also the smallest set you have to defend later.
ABA Formal Opinion 512 is direct on the rest of it: your duty to vet a vendor’s security and confidentiality terms applies to AI tools exactly the way it applies to any other outside service. Rule 1.6 does not relax because the technology is impressive.
Before a single document moved:
We only used commercial AI services on paid business terms. I read the data processing agreements, including breach notification and what happens if a vendor is served with process.
Encrypted at rest and in transit, multi-factor authentication on every account.
No client content is used for model training anywhere in the stack.
The other question: what did it miss?
The app returns ten passages. How do you know there weren’t eleven?
You don’t, unless you check. I ran it against passages I already knew were in the corpus and confirmed it surfaced every one. I also kept exact keyword search running alongside semantic search, so a literal term never disappears into a paraphrase.
Same discipline on the witness summary tool. That one flags inconsistencies across testimony, and flagging is not finding. Every item it surfaced was read by a human against the source document before it went anywhere near a deposition outline. A tool that’s 95% accurate at finding prior inconsistent statements is dangerous the moment you start treating it as 100%.
The claim I’m not making
There’s a version of this article where I tell you the tools got so good that anyone can build anything now. I’ve read that article. I’ve probably drafted it.
It isn’t quite true.
Look at what actually carried this. A year of familiarity with the case. A document index I’d already built. Prior experience deploying secure apps for clients. Knowing which security requirements to specify in the first place, which is something you learn by getting it wrong once.
Codex wrote the code, and the code was the easy part.
What changed is which skill is scarce. Knowing how to build software used to be the bottleneck. Now the bottleneck is knowing what to build, and knowing your subject well enough to catch the output when it’s wrong. That’s good news for lawyers.
What to do Monday morning
Pick one document set you search over and over. Index it before you try to build anything on top of it. The index is the asset.
Ask your e-discovery vendor what you pay per gigabyte per month. Write the number down. You’ll need it for every conversation after this one.
Find one internal workflow where speed matters more than polish and build the rough version yourself. Deposition prep qualifies. Anything headed to a court does not.
One last thing
If you enjoyed this article, please share it with others.
Want help with something like this? Reach out at steve@intelligencebyintent.com.
I drafted this article on Sunday, and Magnus was extremely needy after his morning walk. Here’s the two of us on the couch, not building anything.
