From raw court decisions to an AI research workbench: a complete legal-tech product built by a small team

The challenge

Legal research in the client's market runs through the official public legal information system: a government-operated database of court decisions and statutes. It is authoritative and free, but it was built for lookup, not for research. Keyword search returns long lists of PDFs. Reading, comparing, and extracting the relevant passages from dozens of decisions is manual work that consumes a large share of every practitioner's billable day.

The client's thesis: lawyers do not need another chat window, they need a research environment - one where AI-powered search over the full body of case law, the documents themselves, and the lawyer's own notes and extracts live in one workspace, organized per case, shared across a team.

Nothing like it existed for this market. Building it meant solving three hard problems in sequence: getting tens of thousands of court decisions out of a government system built for humans, making them semantically searchable with citations a lawyer can trust, and wrapping that in a product legal professionals would actually work in all day.

What we built

The work ran in three phases, each producing something independently testable.

Phase 1: the data foundation. An ingestion pipeline that pulls court decisions from the public legal information system's API in paginated batches, downloads each decision's PDF, extracts the full text, computes token metrics, and stores documents in PostgreSQL with their complete metadata - court, decision date, case numbers, legal areas, norms - alongside the original PDFs in S3. Every document is tracked through its processing states, so the pipeline can resume, skip, and update incrementally.

Phase 2: retrieval a lawyer can trust. Court decisions are long, and legal arguments span pages. We split each decision into 800-token chunks with 200 tokens of overlap so no argument is cut mid-thought, then contextually enriched every chunk - an LLM labels each fragment with what it is about within the whole decision - before embedding. Enrichment and embedding ran through OpenAI's Batch API in roughly two-million-token submissions, cutting embedding costs to a fraction of real-time pricing. The chunks live in OpenSearch as a vector index.

Search itself is a funnel: a query is embedded, OpenSearch returns around 100 candidate documents, a multilingual reranking model (Cohere) re-scores them against the query, and the top 20 reach the user. On top of that sits an agentic deep search built with LangGraph: the system drafts a research plan from the legal question, generates multiple search angles, runs them all, summarizes the most relevant decisions, and synthesizes a comprehensive answer - every claim tied to the underlying documents.

Phase 3: the product. A multi-tenant web application organized around how lawyers actually work: cases. Each case is a three-panel research environment:

• A case library holding sources, text snippets (with exact page and offset references back into the original document), hierarchical notes, and the full search history
• An AI research chat in the center, backed by an agent with over a dozen specialized tools - it can search the case-law database, fetch and read documents from the case, create and edit notes, and maintain a research plan with tracked progress
• A workbench for reading decisions, drafting analyses in a rich editor, and exporting to DOCX and PDF

Users choose what the AI sees: a context manager lets them pin specific documents, searches, notes, and snippets into a conversation, and the system compiles the full text of everything selected into the model's context. Teams share cases with role-based access, invitations, and per-team data isolation. The interface ships fully bilingual, with translation coverage enforced in code.

A small browser extension closes the loop with the public system: it injects a button next to every result on the official database's search page, jumping straight from the government website into the client's research environment with that decision loaded.

Technology choices

• Next.js 15 with React 19 and TypeScript in strict mode - the web application and its backend-for-frontend in one codebase, no any tolerated
• A separate Python FastAPI service for the heavy lifting: search, reranking, and the LangGraph research agent, streaming results to the browser via server-sent events
• PostgreSQL with Prisma, split into separate schemas: the read-only ingested case-law corpus on one side, user-generated content (cases, notes, snippets, conversations) on the other - 29 data models, every schema change a versioned migration
• OpenSearch as the vector store, OpenAI models for embeddings, planning, and synthesis, Cohere for multilingual reranking
• AWS throughout: S3 for documents, managed Postgres and OpenSearch, containerized services

The architectural decision that carried the most weight: documents are the unit of trust. Chunks exist for retrieval, but everything the user sees - results, citations, snippets - resolves back to whole decisions with their court metadata intact. In a product for lawyers, an answer without a verifiable source is worse than no answer.

Why a small team works

AI-era product development inverts the old staffing logic. The constraint is no longer typing speed, it is decision quality: which retrieval strategy, which unit of trust, which workflow to build first. A small team with full ownership of the stack - pipeline to product - makes those decisions in conversations, not committees, and ships them the same week. Three months of repository history show the pattern: focused phases, working software at the end of each, and no coordination overhead eating the margin.