Legal teams have a problem nobody talks about much. Contracts pile up in email inboxes, shared drives, and compliance folders. Key dates slip by because they’re buried in page 47. Payment obligations get missed until finance sends an angry email. Addendums quietly change the business terms everyone thought they agreed to. And when it’s time to draft something new, the process starts over: lawyers write clauses, operations adds business context, subject matter experts weigh in, and the whole thing takes weeks.
We fixed that. Our team built a contract management service on AWS that started as a simple RAG system for review and search, then grew into a full drafting and collaboration platform. We kept the team small, moved fast, and let user feedback decide what came next. Here’s how it happened.
The beginning was scrappy. With a handful of people, we couldn’t afford to build something huge. So we went for what I call a VIBE MVP: viable, iterable, built for basics, executable in weeks. The focus was ingestion, normalization, grounded retrieval, and a dashboard that made contracts useful for operations, not just lawyers.
Think about what that means in practice. Contracts come in all shapes: PDFs from vendors, Word docs from partners, scanned images from old deals. Step one was getting them into the system without manual cleanup. We used Amazon S3 as the document store, which is straightforward for any scale. From there, Lambda functions handled preprocessing: OCR for scans, text extraction, chunking into clauses or sections, and normalization to pull out structured data like parties, dates, amounts, and obligations.
That normalization step is crucial, but often overlooked. Raw contract text is messy. Legal language has defined structures, but no two agreements use them the same way. We parsed for key fields, tagged clauses by type (payment, termination, indemnity), and enriched metadata. Then embeddings went to Amazon OpenSearch Serverless for vector storage. Why OpenSearch? It’s serverless, handles hybrid search (semantic plus keyword for legal terms), and integrates cleanly with AWS IAM for tenant isolation if you need multi-team access. Retrieval used Amazon Bedrock’s knowledge bases, which bundle embedding generation, vector search, and prompt augmentation. You’d ask something like “What payments are due next quarter?” and the system would fetch relevant chunks from OpenSearch, ground the Bedrock model (Claude or a legal-tuned variant), and return answers tied back to source clauses. No hallucinations because the context was explicit. Early tests showed it cut search time from hours to minutes.
But the dashboard was the real hero. Nobody wants a chat interface for production work. We built views for dates (renewals, notices, expirations), operations items (deliverables, SLAs), payment schedules with due amounts and vendors, and addendums with diff views showing changes. Streamlit or a simple React app on Amplify made it visual: timelines, risk heatmaps, obligation trackers. AWS CloudWatch tracked usage, and Lambda orchestrated everything serverless. Cost stayed low because Bedrock bills per token, and OpenSearch Serverless scales to zero.
We tested that MVP hard. Uploaded real contracts (anonymized), ran queries operations cared about, watched legal review cycles. Feedback looped back fast. What broke? Edge cases in parsing old docs. What worked? Surfacing hidden risks. We iterated: better chunking for addendums, metadata filters for vendors, export to Excel for finance. That’s when users asked for more. If the system understands contracts this well, can it help us build them? Drafting is where legal workflows waste the most time. Standard clauses get copied from templates, business terms get emailed back and forth, SMEs add context nobody tracks. We expanded the platform without starting over.
Phase two kept the same stack but added generation and collaboration. Bedrock handled the legal LLM side: prompt a model with retrieved similar clauses, business context from SMEs, and output structured sections (recitals, terms, exhibits). We used LlamaIndex for orchestration because it’s cloud-agnostic and excels at connecting data sources to LLMs. It let us layer advanced retrieval (hierarchical chunking, auto-merging) on top of OpenSearch without vendor lock-in. LangChain could work too, but LlamaIndex felt lighter for document-heavy flows. Collaboration came through real-time editing. Think Google Docs but for contracts: section-based drafting where SMEs drop business rules (“Cap indemnity at $1M”), legal adds clause variants, and the LLM suggests completions grounded in your corpus. DynamoDB tracked versions and comments, AppSync pushed updates live. Permissions used Cognito groups: ops view-only, legal edit, SMEs comment.
Testing phase two was intense. We simulated full cycles: ingest old contract, query for risks, draft renewal with addendum, collaborate on changes, export signed version. Hallucinations dropped because prompts always included corpus examples. Users loved the SME input loop; it made non-lawyers feel involved without slowing things down. One ops lead said it cut negotiation emails by half.
Architecture stayed pragmatic. S3 for raw storage, Lambda for ETL (ingest/normalize/embed), OpenSearch for retrieval, Bedrock for inference, DynamoDB for metadata/state, Step Functions for workflows (ingest pipeline, draft approval). Cloud-agnostic choices like LlamaIndex meant we could swap vector stores (Pinecone if needed) or models without rebuilds. Total cost? Under $800/month for moderate use, thanks to serverless.
Why did this work? Small team, user-led evolution, AWS for speed, agnostic tools for flexibility. We didn’t chase shiny agentic AI first. We solved review pains, proved value, then built creation on top. Now the platform handles end-to-end: ingest, search, track, draft, collaborate. Legal moves faster, ops sleeps better, SMEs contribute without friction. Now to be a little transparent, we built this ending 2025 into 2026, if I had to do it again, we would make some minor changes and be a little more cloud agnostic. Time was also a factor, as well as experience for the team supporting after we left. I guess what I am saying is this is an example of a solution that was as simple as we could make it at the time, what I love about now-a-days is that almost everyday a new tool can make it easier and easier to solve challenges for your business. If you’re building something similar, start with the MVP. Get data ingested, searchable and dashboarded. Test with real users, let them ask you to add features. You’ll save months guessing.
What AI pains are you solving next? Share in the comments or tag @cesarmorenoai on X. Subscribe at cesarmoreno.ai for more no-fluff tech builds.