AI‑Powered Contract Review for SMBs
A small business can cut legal review time from days to minutes by letting a custom LLM playbook scan contracts before a lawyer ever opens them. The idea is not to replace legal counsel. It is to eliminate the queue of routine documents that clog up a lawyer’s schedule and force your team to wait.
Why routine contracts are a real bottleneck
Most small businesses do not sign hundreds of contracts a year. They sign enough. A vendor agreement here, a service-level addendum there, a non-compete for a new hire, a lease renewal with amended terms. Each one goes to the same person, usually a retained outside counsel who bills by the hour and works through a backlog.
The problem is not the complex, high-stakes deals. Those deserve full human attention. The problem is the 70 to 80 percent of contracts that are essentially the same document with a few variables changed. A standard SaaS subscription agreement. A freelance engagement letter. A data processing addendum that mirrors the last three you signed.
Your lawyer charges the same rate to review a boilerplate NDA as they do to negotiate a multi-million-dollar MSA. That is the inefficiency. The document does not need a lawyer’s judgment; it needs a checklist.
Building a playbook that matches your risk appetite
Before you touch any model, you need to define what “review” means for your business. This is the playbook.
A playbook is a structured set of rules, red flags, and approval thresholds. It answers questions like:
- What is the maximum liability cap we accept without escalation?
- Which indemnification clauses are non-negotiable?
- What jurisdiction must disputes fall under?
- Which data processing terms trigger a mandatory legal review?
- What is the acceptable auto-approve threshold for contract value?
You write this down in plain language. Not as legal prose, but as a decision tree that an LLM can follow. Think of it as a runbook. Each rule maps to a specific action: flag, approve, or escalate.
The key is specificity. “Check that the liability clause is reasonable” is useless to a model. “Flag any clause that caps liability below 12 months of fees or that includes unlimited consequential damages” is actionable.
You iterate on this playbook over time. Every time a lawyer overrides an auto-approval or catches something the model missed, you add a rule. The playbook gets sharper with every contract that passes through it.
The technical architecture
The workflow has three layers: ingestion, analysis, and action.
Ingestion. A contract arrives as a PDF or Word document. You parse it into structured text. For PDFs, a tool like PyMuPDF or pdfplumber handles extraction. For Word documents, python-docx gives you clean text with headings and sections preserved. The output is a plain-text representation of the contract, split into sections.
Analysis. You send the extracted text to an LLM with your playbook as the system prompt. The model returns a structured JSON response: a list of findings, each with a severity level (info, warning, critical), the relevant clause text, and a recommended action.
For the model itself, you have options. If you want speed and low cost, Groq’s LPU-based inference runs Llama 3.3 70B at high throughput with a small per-token cost. If you want the strongest reasoning for edge cases, you can route critical findings to a larger model as a second pass. The routing logic is simple: if any finding is marked “critical,” send that specific clause to a second model for confirmation.
Action. The structured output goes into a Supabase table. A simple web UI (React or Next.js) displays the findings in a dashboard. Your team sees a color-coded summary: green for auto-approved, yellow for needs-review, red for escalate-to-lawyer. The lawyer only opens the red items.
This is the same pattern I use for other internal business tools: a Supabase backend with row-level security, a thin frontend, and a clear separation between the AI layer and the data layer. The architecture is not exotic. The value is in the workflow design. You can see more examples of this approach on gabrielepau.com.
Running the workflow with minimal human intervention
The goal is not zero human involvement. It is minimal, targeted involvement.
Here is what a typical flow looks like in practice:
- A new contract lands in a shared folder or gets uploaded through the web UI.
- The ingestion pipeline extracts text and splits it into sections.
- The LLM runs the playbook against each section.
- Findings are written to Supabase. The dashboard updates in real time (Supabase Realtime subscriptions make this straightforward).
- If all findings are “info” or “warning” and the contract value is below your threshold, it is marked as auto-approved.
- If any finding is “critical,” the contract is flagged for legal review. The lawyer sees only the flagged clauses, not the full document.
- After the lawyer’s decision, the outcome is logged back into the system. This feeds the playbook improvement loop.
The human touchpoint is step 6, and only for the subset of contracts that actually need it. In a typical SMB, that might be 15 to 25 percent of incoming contracts, not 100 percent.
Measuring what actually changed
You cannot justify the setup if you cannot show the impact. Track three numbers from day one:
Turnaround time. Measure the elapsed time from contract receipt to approval. Before the system: days (whatever the lawyer’s backlog dictates). After: minutes for auto-approved items, one business day for escalated items (because the lawyer sees only the flagged clauses and can act faster).
Escalation rate. What percentage of contracts require a lawyer’s full attention? If your playbook is well-tuned, this number should trend down over the first few months as you add rules for edge cases that previously triggered false positives.
Error rate. How often does a clause that should have been flagged slip through? This is the risk metric. It should be near zero for critical items. If it is not, you have a gap in your playbook.
These three numbers together tell you whether the system is working. Turnaround time proves the speed gain. Escalation rate proves the filtering is effective. Error rate proves you have not traded one problem for a worse one.
What this is not
This is not a replacement for legal counsel on complex, novel, or high-value agreements. It is not a general-purpose document AI. It is a targeted workflow for a specific, repetitive problem: routine contracts that do not need a lawyer’s full attention but still need to be checked against your company’s rules.
The barrier to entry is low. You need a parsing library, an LLM API key, a Supabase project, and a weekend to wire it together. The hard part is not the code. The hard part is writing a good playbook, which requires sitting down with your legal team and translating their judgment into explicit rules.
That translation step is where most attempts fail. People skip it, point a model at a contract, and get vague, unactionable output. The model is only as good as the playbook you give it.
Start with ten contracts your lawyer has already reviewed. Write the rules that would have caught the issues they found. Test the playbook against those ten. Fix the gaps. Then turn it on.