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.
View Live AppOnTract is an AI-powered contract intelligence platform built for small and mid-sized businesses that need the same contract analysis capabilities as the big enterprise contract management platforms, without the enterprise price tag. As an AI Engineer on a team of 7, I helped build the systems that read, understand, and surface key information from legal documents — from document ingestion through the retrieval pipeline that powers conversational search — reducing the manual work of contract review.
The existing players in contract intelligence — 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 that cost, so they're left reviewing everything manually. We built OnTract to close that gap: the same AI-powered contract analysis, at a price a smaller team can actually afford.
Reading a full contract to find a few key terms is slow.
Built AI workflows — running as Supabase Edge Functions — to summarize contracts and extract key clauses like renewal dates, payment terms, and obligations, using OpenAI's GPT-4o to process each document as it's ingested.
A single keyword search rarely captures what someone actually needs from a contract.
Integrated LLMs with semantic search and conversational memory using LangChain, supporting multi-turn chat over ingested contracts. Contract text is embedded and stored in ChromaDB, an open-source vector database — a deliberate choice to keep infrastructure costs low while the product proves itself with smaller customers. Every chat interaction is traced through LangSmith for visibility into model behavior and latency.
AI outputs are only useful if they're stored and retrievable at scale.
Leveraged Supabase's managed Postgres, storage, and edge functions to build a scalable backend for document storage and metadata management, with database migrations and seed data keeping every teammate's environment reproducible.
The product is a Next.js frontend paired with Supabase for auth, a Postgres database, file storage, and serverless edge functions — the same edge functions that run the AI document-processing pipeline. This keeps AI workloads close to the data without standing up a separate backend service.
Rather than requiring every integration just to run the app, the team designed the stack in layers: the core application (auth, contracts, clients) depends on Supabase alone. Everything else — AI processing, payments, observability, and email invitations — is an optional layer on top, each gated behind its own environment variables and only active when its keys are configured.
Keeping infrastructure costs low was part of the product itself, not just an engineering convenience. For vector storage and semantic retrieval, the team chose ChromaDB, an open-source embedding database, over managed alternatives like Pinecone — avoiding a recurring per-vector hosting cost while OnTract was still validating demand with smaller customers. As usage grows, the plan is to migrate to Pinecone for its managed scaling and faster retrieval at high volume, trading a higher fixed cost for headroom once the user base 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.
The result is a platform that gives smaller businesses the same AI-powered summarization, clause extraction, and conversational search as enterprise contract management tools — at a fraction of the cost, largely by choosing infrastructure like ChromaDB that scales down cheaply instead of defaulting to the same managed, enterprise-grade services our competitors run on. Because the retrieval layer isn't hard-coded to one vector store, swapping in Pinecone later as the user base grows is a targeted change rather than a rebuild.
Working on OnTract reinforced that the "best" technical choice depends on context. ChromaDB isn't as fast or as hands-off as a managed service like Pinecone at large scale, but it was the right choice for a product whose entire pitch is affordability for smaller customers. Designing the retrieval layer so ChromaDB could later be swapped for Pinecone, rather than assuming one vector store forever, was a small decision early on that should save real rework as OnTract grows.