What we built
We built an MVP of a software product for law firms with roughly 10 to 50 people. The product focused on a recurring knowledge problem. Staff needed legal document search across past cases and the firm’s existing archive without relying on one partner’s memory or a long manual process.
The work progressed through multiple product iterations. Each version separated the attractive idea of a broad legal document assistant from the more immediate operational constraint. The document systems already used by law firms made it difficult to retrieve useful material quickly. We therefore concentrated the MVP on document retrieval and access to prior work rather than presenting it as an autonomous legal adviser.
The knowledge gap inside a law firm
Partners with long tenure could often remember a relevant case, document, or argument and suggest it from memory with useful accuracy. That informal index did not scale to other employees. Junior lawyers and other team members did not have the same history with the firm’s matters, even when files were organized into folders and extensively documented.
Manual retrieval was still time-consuming. A person needed to know which matter might contain a precedent, browse folders, open several documents, and judge whether each result was relevant. The difficulty was therefore not simply a lack of documentation. It was the gap between storing knowledge and making that knowledge searchable for someone who did not already know where to look.
How the MVP addressed retrieval
The MVP was designed around a private document collection: earlier cases, internal documents, and reusable fragments of work. We explored document parsing, tags, and semantic search. Grouping related content let a query surface material even when it did not repeat the exact wording used in the source document.
Search results needed to remain connected to their original documents. In legal work, a plausible answer without a traceable source is less useful than a narrower result that a person can inspect. The product direction therefore treated retrieval as the core capability and drafting support as a downstream use of retrieved context, not as a replacement for professional review.
The iterations also exposed practical product questions. We examined how much context to show, how to distinguish closely related matters, and how to help employees without a partner’s historical knowledge. These decisions mattered more to the user experience than presenting a long list of algorithms or frameworks.
Why development was postponed
The MVP established a working product direction, but further development was postponed. At the time, the technology remained expensive relative to the prevailing alternative. Law firms could assign much of the document-search work to interns completing legal practice, often at little or no direct labour cost.
That comparison changed the commercial case. The product was not competing only with inefficient legal software; it was competing with a low-cost organizational workaround. Even if better retrieval could reduce manual effort, the available evidence did not justify claiming that the system would deliver a lower total cost for the target firms.
Postponing development was therefore a product decision, not a claim that the underlying problem had disappeared. The research showed a concrete need, while the economics at that stage did not support continuing toward a larger rollout.
Supported outcome and limits
The supported outcome is an iterated MVP and a clearer definition of the target segment’s most valuable problem. More employees needed practical access to knowledge stored across past cases and documents. The project also identified the existing legal-software search experience and the economics of manual intern-led retrieval as central adoption constraints.
This case study does not claim a production deployment, active use across law firms, measured retrieval accuracy, reduced legal-work time, or financial savings. It also does not claim that generated text was legally correct. Those outcomes were not supplied as verified evidence.
For organizations facing a similar retrieval problem, the relevant starting point is the document collection, access rules, representative search questions, and the cost of the current workflow. See our approach to document intelligence and RAG.