Background
Founders increasingly rely on ChatGPT to understand term sheets before their first call with their law firm. The problem: generic AI tools cite foreign law, outdated guidance, or unsupported market practice. Founders end up in kickoff meetings without proper grounding in Indian law, asking their lawyers to untangle incorrect information.
The tool
A legal research tool for Indian PE/VC term sheet negotiations, grounded in Companies Act 2013 and FEMA legislation. Founders can browse key clauses like liquidation preference, anti-dilution and drag-along, or query specific negotiating positions and get structured, India-specific answers covering founder and investor counsel perspectives, market practice, and red flags. The playbook handles the foundation and the lawyer handles everything above it.
How it was built
I built this over a series of focused sessions on Claude. No engineering background, no budget. I worked in blocks timed around usage limits, starting in the morning, then again in the afternoon, then in the evening.
The work ran in two parallel threads: one for the knowledge base, researching, curating, and encoding how Indian term sheet clauses are actually negotiated; and one for the front end, building an interface where the information is easy to find and read. Debugging happened by taking screenshots and dropping them into Claude chat.
But the technical choices matter more than the timeline. Here is what shaped the architecture:
Stack: Next.js + OpenAI Embeddings + Structured Knowledge Base
Frontend: Next.js and React with TypeScript. This runs on Vercel with zero DevOps overhead.
Backend: Next.js API routes. API calls to OpenAI stay server-side, so no client-side API keys are exposed in the browser.
Knowledge Base: 33 Indian PE/VC clause chunks structured as TypeScript objects. Each chunk has title, keywords, legal flags, risk level, founder/investor positions, and market practice — plus a precomputed vector embedding for semantic retrieval.
LLM: OpenAI's gpt-4o-mini, called only at generation time. Retrieval itself runs against precomputed embeddings, so the model never has to search — it only writes up what's already been found.
Technical Architecture: Why These Choices Matter
A RAG system has three stages: retrieval, ranking, and generation. Most of the design effort here went into the first stage, because a legal research tool is only as trustworthy as what it decides is relevant to a lawyer's question.
Structured data, retrieved semantically
The knowledge base is a TypeScript object array. Each clause chunk has explicit fields: title, keywords, legalFlag, marketStandard, risk level (critical/high/medium/low). Every one of those fields exists so a lawyer can see exactly why a clause surfaced — nothing about the underlying data is opaque.
What sits on top of that structured data is a semantic search layer. Every clause chunk is converted to text and run through OpenAI's embedding model offline, once, whenever the knowledge base changes — not on every request. Those vectors are committed to the repository and loaded at query time, so a live query never waits on re-embedding the whole corpus, only on embedding the lawyer's own question.
Why keyword matching alone isn't enough
Matching a query to a clause purely by shared words is fast and easy to audit. Every match traces back to a specific keyword, so a lawyer can see exactly why a clause was surfaced. The limitation shows up when a question uses different words than the clause itself.
A founder asking "what happens if I get fired before my shares vest" is really asking about Good Leaver / Bad Leaver provisions, but that question shares almost no vocabulary with how the clause is written. A word-matching search would miss it, even though the knowledge base has a clear answer. The gap sits in the phrasing, not in the underlying research.
Semantic search closes that gap by comparing the meaning of the query to the meaning of each clause, rather than the exact wording. Keyword matching still plays a role alongside it, adding weight when a query uses precise legal terminology such as "drag-along" or "1x non-participating," so exact terms carry the credit they deserve. Together, the two approaches let the tool understand what a founder is actually asking while staying anchored to the legal terms lawyers expect to see.
Next.js for fast deployment
The backend is a Next.js API route: a single endpoint that takes a query and mode (founder or investor), retrieves the relevant clauses, and returns a JSON response with structured advice. Vercel deploys this with sub-100ms cold start. The only network round-trips at request time are embedding the lawyer's query and generating the final answer — the corpus itself is never re-processed live.
Barrier to adoption drops when tools do not make you wait. If the tool took several seconds per query, junior associates would use ChatGPT instead. Speed forces good architecture.
Role-based system prompts
The LLM gets two different system prompts depending on mode, both anchored to the same identity — a senior corporate lawyer at a Tier 1 law firm:
Founder counsel mode: "You are a senior corporate lawyer at a Tier 1 law firm acting as FOUNDER COUNSEL for a Seed or Series A funding round in India. Your job is to protect the founders' interests..."
Investor counsel mode: "You are a senior corporate lawyer at a Tier 1 law firm acting as INVESTOR COUNSEL for a Seed or Series A funding round in India. Your job is to protect the investor's interests..."
The same clause chunk returns different negotiating advice depending on perspective. A liquidation preference is flagged as "critical risk" in founder counsel mode and "acceptable baseline" in investor counsel mode. This trains founders to understand both perspectives before they walk into their law firm's office, which is exactly what good preparation requires.
Why RAG (And Not Just General AI)
Ask ChatGPT "Is a put option enforceable in Indian term sheets?" and it draws on training data from UK case law, US contract law, and generic fintech guidance. The answer is plausible but wrong. Indian law on this point is governed by the pricing guidelines under Rule 21(2)(c) of the NDI Rules 2019. A put option providing an absolute guaranteed exit price higher than FMV at the time of exercise violates those guidelines. A capped-IRR structure is permissible provided the payout at exercise does not exceed FMV at that point. The valuation must be certified by a SEBI-registered Merchant Banker or a Chartered Accountant.
Generic tools guess. RAG systems retrieve and acknowledge when they do not know.
The Playbook works differently. When queried, it:
- Embeds the query and compares it against every clause chunk's precomputed vector to find what's actually relevant, even if the wording doesn't match.
- Passes only the retrieved chunks — ranked by combined semantic and keyword relevance — as context to the LLM.
- The LLM generates an answer grounded strictly in those chunks, with citations to Indian law.
- If no chunk clears the relevance bar, the system says so instead of hallucinating an answer from general knowledge.
That honest boundary matters. A tool that acknowledges its limits is more useful to a practitioner than one that confidently answers questions outside its scope.
Limitations: What This Architecture Trades Off
This design prioritises grounded accuracy over breadth. The knowledge base is hand-curated, which means:
Strength: High quality for what is covered. Every clause is vetted against Indian law and market practice. When the system has an answer, it is accurate and grounded — and semantic search means it recognises a relevant question even when it's phrased in plain, non-legal language.
Weakness: Gaps exist. If a clause type is not in the database, say a novel instrument introduced post-June 2026 or a highly specialised tax structure, the system returns "not covered." There's also a quieter risk: because embeddings are precomputed and committed rather than generated live, any edit to the knowledge base has to be followed by regenerating those embeddings, or the new or changed clause simply won't surface in search — with no visible error to flag that it happened. Scaling would require either manual curation by domain experts, which is sustainable but slow, or a hybrid approach where core clauses are maintained manually and ancillary content is auto-ingested with more automated safeguards around that regeneration step. That is considerably more complex to build.
For now, the tool is intentionally narrow: term sheet clauses only, not SHA/SSA/CPA mechanics, not M&A precedent, not regulatory compliance checklists. Narrowness prevents hallucination. Breadth without depth is where RAG systems fail.
What comes next
The constraints here were deliberate. No budget, no dedicated engineering team. The knowledge base is limited to what I could research and encode alone.
A version built on a firm's institutional knowledge would look different: more clauses, more depth on multi-investor scenarios, integration with SHA templates and precedent documentation, automated safeguards around embedding regeneration, and usage analytics to identify gaps and friction points.
Founders do not need AI to replace lawyers. They need AI to handle the foundation, understand the structure, and ground themselves in Indian law before they call their lawyer, so the conversation focuses on strategy and negotiation.