What I Built
Legal tech has an awkward habit: it asks you to upload your most sensitive documents to a black box, charges you $300 an hour, or spits out a ten-page generic summary that still requires a law degree to understand.
The Private Contract & Lease Decoder solves this. It’s a free, blazing-fast tool that acts as a first-pass legal reviewer. You paste a contract (or upload a PDF/DOCX), select your role (e.g., Freelancer, Tenant), and in just 2-3 seconds, it gives you:
A bulleted list of specific red flags, hidden traps, and unfair clauses.
A polite, professional draft email to negotiate those exact terms.
A 1–10 "predatory risk" score.
An audio read-out of the negotiation email so you can listen to it on the go.
It’s built for anyone who needs to verify a document before signing but can’t afford a lawyer: a student signing their first freelance gig, a tenant reviewing a new lease, or a small business owner checking a vendor agreement.
Demo
Live App: https://private-contract-decoder.onrender.com
(Note: Because it runs on Render’s free tier, the very first click after a long idle period takes ~5 seconds to wake the server. Every click after that is instant thanks to in-memory caching.)
Code
🛡️ Private Contract & Lease Decoder
A fast, private, and free AI tool that acts as a first-pass legal reviewer. Upload a contract or lease, and in seconds, get a bulleted list of red flags, a professional negotiation email, and a predatory risk score.
Built for students, freelancers, and tenants who need to verify documents before signing but can't afford a $300/hr lawyer.
Live Demo: [Insert Your Render URL Here]
✨ Features
- Parallel AI Analysis: Three AI routers fire simultaneously to analyze the document in ~3 seconds.
- Self-Healing Fallback Chains: If a model fails, times out, or gets deprecated, the app instantly hops to the next available model.
- Multi-Format Support: Upload PDFs, DOCX files, or paste raw text.
- Audio Read-Out: Listen to your negotiation email on the go via ElevenLabs (with a silent fallback to free gTTS).
- 100% Private: No data is stored. The app processes text in memory and…
How I Built It
The architecture is conceptually simple, but making it fast, resilient, and reliable on free-tier APIs was the real engineering challenge. I built a parallel, self-healing router system with hard timeouts using Python's ThreadPoolExecutor.
Instead of running sequentially (which would easily take 15+ seconds), three AI routers fire at the exact same time:
Router 1 (Deep Analysis): Uses larger open-weight models to find specific legal red flags and hidden fees.
Router 2 (Email Drafting): Uses fast, structured models to draft a polite, professional negotiation email.
Router 3 (Risk Scoring): Uses a lightweight model with strict regex parsing to output a 1-10 predatory risk score.
Observability: How Sentry Saved the Build
My first version took a staggering 190 seconds to return a result. I was completely blind to why until I wrapped the main pipeline in a @sentry_sdk.trace decorator.
The Sentry Performance dashboard let me visually see the three router spans firing in parallel, and more importantly, it flagged the exact bottleneck: silent API errors causing a retry loop with no timeout, hanging for ~13 seconds per attempt.
Sentry caught every critical error during development, from the 190s timeout hangs to the deprecated model calls, letting me fix them before the demo.
Once I saw the traces, I added hard 10-second timeouts to every client and strict token budgets. If a model hangs or throws a gateway error, the router instantly kills the connection and hops to the next one. That single fix, guided entirely by Sentry, dropped my p95 latency from 190 seconds down to 6-8 seconds(due to audio rendering).
Surviving Mid-Hackathon API Nightmares
Building on free-tier APIs means dealing with constant, unpredictable changes. During this build alone, I faced three major hurdles that would have broken a naive app:
The Decommissioned Model: Mid-build, Groq quietly deprecated an older Llama model I was relying on. A closed system relying on a single hardcoded model would have just crashed. Because I built a fallback chain, the router simply caught the 400 model_decommissioned error, hopped to the next model in the list, and kept going without the user ever noticing.
The Namespace Shift: Groq suddenly changed their API naming convention, requiring prefixes like openai/ for their new GPT-OSS models. This caused a wave of 404 model_not_found errors. I had to quickly pivot, use the Groq Playground to identify the new live IDs, and update my fallback chains dynamically.
The "Lazy" Model: Router 2 kept cutting off the email draft abruptly after the subject line. I realized the model was getting overwhelmed by long contracts. I fixed it by truncating the context window to the first 600 characters and switching the drafting router to Qwen, which excels at structured writing tasks.
Caching and Audio Resilience
To make the app feel truly production-ready, I added a simple dictionary-based response cache keyed to the hash of the input text. If a user analyzes the same contract twice, the second request bypasses the AI entirely and returns in 0.1 seconds.
For the audio, the email is read aloud via ElevenLabs. But free-tier credits run out fast. I wrote a silent failover: if the ElevenLabs API throws an error, the app instantly catches it and switches to the free gTTS library, ensuring the demo never breaks.
Why Does Open Innovation Matter?
It costs nothing to run, so it can stay free. A fallback chain of open-weight models routed through flexible providers means I’m not locked into a single vendor’s pricing, rate limits, or sudden policy changes.
I could see and steer every step. When a model failed, I could inspect the raw Sentry error, see exactly which model name was deprecated, and update the chain. Open weights let me understand why it failed, not just that it failed.
Resilience is a feature. Free tiers get throttled. Open innovation made it possible to build a self-healing app on a $0 budget, rather than a fragile demo that breaks the moment a closed, proprietary API has a bad day.
My Agent Session
Note: This project was built using custom Python orchestration and parallel routing rather than a heavy, multi-step agent framework. I prioritized a deterministic, self-healing agent harness to ensure speed and predictability, avoiding the complex reasoning loops that would easily blow past free-tier timeouts.
My First User
I had a friend who needed to verify a freelance contract before signing it. He uploaded the document to the app, and it immediately flagged a few unfair clauses and hidden fees he had completely missed. It gave him a clear, plain-English breakdown of the risks, which he used to ask the client for a quick revision before signing. It was a small win, but it proved the tool does exactly what it's supposed to: catch the fine print before it becomes a problem.
Lessons Learned
Never ship an API call without a hard timeout. The 190-second hang taught me that the hard way. Optimism is not a concurrency strategy.
Model names rot weekly. Build fallback chains from day one. Hardcoding a single model ID is a ticking time bomb.
Parallel execution is free speed. Three routers firing concurrently via ThreadPoolExecutor is exactly why this feels instant to the end user.
Observability is non-negotiable. Without Sentry's distributed tracing, I would have been blindly guessing why the app was hanging for 3 minutes.
Prize Categories-
Best Use of Sentry: Distributed tracing of the parallel router fan-out, which was instrumental in diagnosing the 190-second timeout bug and catching live API errors.
Best Use of Render: $0 hosting with a startup warm-up thread and environment-variable secrets.
Best Use of ElevenLabs: Voice generation with a graceful, silent degradation to free gTTS if credits run out.
Top comments (0)