An AI-powered contract intelligence platform that summarizes contracts, extracts key clauses, and lets teams query documents conversationally. I worked as an AI Engineer on the team that built the underlying AI and backend systems.
Building affordable AI contract intelligence for teams enterprise tools have priced out.
OnTract brings enterprise-grade contract analysis to small and mid-sized businesses at a price they can afford. As an AI Engineer on a team of 7, I built the systems that read and understand legal documents, from ingestion through the retrieval pipeline powering conversational search, cutting the manual work of contract review.
Problem
Enterprise contract intelligence tools price out the businesses that need them most.
Tools that summarize agreements, extract clauses, and flag renewal dates are built and priced for enterprise legal teams. Smaller businesses face the same dense, error-prone contracts but can't justify the cost, so they review everything by hand. We built OnTract to close that gap: the same AI-powered analysis, at a price a smaller team can afford.
Approach
Three systems worked together to turn raw contract text into structured, queryable knowledge.
01
AI-powered contract summarization
Reading a full contract to find a few key terms is slow.
AI workflows running as Supabase Edge Functions use GPT-4o to summarize each contract and extract key clauses (renewal dates, payment terms, obligations) on ingestion. Every clause links back to its source excerpt, so a summary is always something to verify against the original text.
02
Conversational, context-aware document search
A single keyword search rarely captures what someone actually needs from a contract.
LangChain adds semantic search and conversational memory over the LLM, supporting multi-turn chat over ingested contracts. Text is embedded in ChromaDB, and every interaction is traced through LangSmith. Each answer surfaces the excerpt it's grounded in, so chat stays checkable against the source instead of merely plausible-sounding.
03
A scalable backend for contract data
AI outputs are only useful if they're stored and retrievable at scale.
Supabase's managed Postgres, storage, and edge functions handle document storage and metadata, with migrations and seed data keeping every teammate's environment reproducible.
Technical Challenges
Building a RAG pipeline is the easy part: making it trustworthy enough for legal documents is the hard part.
Most of the engineering effort went into grounding summaries in the actual document and making failures debuggable.
Engineering Challenges
Retrieval vs. clause boundaries. Fixed-size chunks often split a clause from its own key figure. Chunking on clause and section boundaries instead keeps each embedded chunk semantically complete.
Debugging non-deterministic output. A wrong answer could come from retrieval, the prompt, or the model. Tracing every call through LangSmith (question, retrieved chunks, final prompt) makes the failure point traceable instead of a guess.
Cost as a design constraint. Every call has a real dollar cost, and margins matter more for an affordability-first product. Reusing embeddings already stored in ChromaDB keeps per-query cost close to just the LLM call.
Trust for a legal document. A fluent but wrong clause is worse than none at all. Every summary and chat answer surfaces the source excerpt it was drawn from, so verifying a claim means checking one passage instead of re-reading the whole contract.
langsmith · trace
01question→user's natural-language question about the contract
02retrieved_chunks→top-k clause-bounded chunks pulled from ChromaDB
04response→answer grounded in, and cited to, the source excerpt
Known Limitations
Heavily scanned PDFs without clean OCR produce weaker summaries, and very long contracts push against context and retrieval limits more than a heavier enterprise stack would. Pre-launch evaluation relied on manual spot-checks rather than a repeatable eval set, and pipeline latency was never formally measured, both known gaps.
System Architecture
A modular stack where AI, payments, and observability layer on top of a Supabase core.
A Next.js frontend pairs with Supabase for auth, Postgres, storage, and edge functions, the same edge functions that run the AI processing pipeline, keeping AI workloads close to the data without a separate backend service.
Only Supabase is required to run the app at all; AI processing, billing, tracing, and email are optional, env-gated integrations on top. For vector storage, the team chose ChromaDB over managed options like Pinecone to avoid recurring hosting costs while validating demand, with a planned migration to Pinecone once usage justifies it.
Core services (solid connectors) are required for the app to run at all. Integrations (dashed connectors) branch off the edge functions layer and only activate once their API keys are configured.
Core Stack
Next.js: frontend application and routing
Supabase (Postgres, Auth, Storage): the system of record and access control
Edge Functions: serverless compute for AI processing and email jobs
Optional Integrations
OpenAI + LangChain + ChromaDB: document summarization, clause extraction, and conversational chat over vector embeddings stored in ChromaDB
LangSmith: tracing and observability for every LLM call
Stripe: subscription billing across Starter and Pro tiers
Resend: transactional email for team and client invitations
Outcome
A shipped, lower-cost alternative to enterprise contract intelligence tools.
The result is a live platform giving smaller businesses enterprise-style summarization, clause extraction, and conversational search at a fraction of the cost. Because the retrieval layer isn't hard-coded to one vector store, swapping in Pinecone later is a targeted change rather than a rebuild.
Lessons Learned
Match infrastructure cost to the stage of the business as much as the scale of the technology.
Cost-conscious choices should stay reversible. ChromaDB was right for an affordability-first product, but only because the retrieval layer wasn't hard-coded to it, leaving room to swap in Pinecone later.
Optional-by-default architecture lowers onboarding friction. Requiring only Supabase to run the core app meant a new teammate could get it running locally in minutes instead of after configuring five external services just to see a login screen.
Observability pays for itself the first time something breaks. Tracing every call through LangSmith felt like overhead until a teammate could point to the exact retrieved chunk behind a wrong answer instead of re-running the same prompt five times.
What's Next
Where the AI systems go from here as usage grows.
Migrate ChromaDB to Pinecone once usage justifies the cost, trading a higher fixed price for managed scaling and faster retrieval at volume.
Replace manual spot-checks with a repeatable evaluation set (contracts with known-correct answers) to catch regressions in summarization and retrieval quality systematically.
Instrument latency across the pipeline to see where time actually goes (ingestion, embedding, or generation) before optimizing any one stage.
Extend retrieval to compare clauses across contracts, e.g. flagging when a new vendor's renewal term is worse than a client's existing ones, on the same ChromaDB and LangChain infrastructure.
Live product
See it in action
OnTract is live: upload a contract and try the AI summarization and conversational search yourself.
