DEV Community: Yuvan Shankar M

I built a $0 alternative to $300/hr legal tech (and survived 190s API hangs doing it)

Yuvan Shankar M — Sat, 17 Oct 2026 15:39:01 +0000

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

yuvanshankarm007 / private-contract-decoder

🛡️ 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…

View on GitHub

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.

Touch Grass Garden: a plant tracker that only counts the days you went outside

Yuvan Shankar M — Mon, 12 Oct 2026 03:35:42 +0000

What I Built

Most apps want you to open them every day. I wanted to build one that doesn't care whether you open it at all.

Touch Grass Garden is a plant tracker for beginners. You enter your location and what you sowed, and it works out the season and suggests what to plant this month. Every day it writes a short card with the best time to go out, any weather warnings, and one thing to look for at each plant. After that you close the laptop and go and look at the real plant.

The streak is the part I care about most. It only counts days when you log a check-in at your plants, and opening the app earns nothing. The weekly goal, the badges and the 12-week heatmap all use the same rule, so the only way to make progress is to go outside.

Here's everything it does:

It reads your coordinates and the date to find the season (kharif, rabi or zaid in India, four seasons elsewhere), then lists what's good to sow this month with the growing method and what each crop needs (sun, water, soil).
Each plant gets stages like sown, germinated, flowering and harvest, with expected dates worked out from the sowing date.
Every day Gemma writes a short outdoor card: the best time to go out, weather alerts, and one thing to look for at each plant.
For check-ins you pick the stage you actually see, add a note, tick if you watered, and attach a photo. Each plant has a timeline with a chart and the photos.
Watering reminders are based on how often each crop needs water, with a warning when heavy rain is forecast.
The streak, a weekly target (4 days by default), badges and a 12-week calendar heatmap all come from real check-ins only.
The garden recap shows days outside, longest streak and totals for each plant, with a download button.
The printable card is a plain-text card with tick boxes and "what I saw" lines, so you can take it outside without a screen.
Each crop has two "if you see this" tips for common problems and what to do about each.
Anyone can drop a JSON file into a folder to add or change crops for their own region (I call these crop packs).
Deleting a plant or a check-in asks for confirmation first.
I also added two experimental extras. The card can be written in a few other languages (Hindi, Tamil and others), and the local model can describe a check-in photo. I haven't tested either properly, so I don't know how good the output is. The photo description is labelled as an unverified AI description in the app.
Weather alerts use each crop's own temperature limits, so a cold night warns about the plants it would actually hurt. Plants of the same crop are grouped into one alert, and the heat threshold is stricter so it doesn't warn all the time.
Saved photos are resized to 1600 px at most and stripped of EXIF location data, and the log is saved atomically so a crash can't corrupt it.

I Took It Outside

It was a good morning for it, and I could hear birds the whole time. I had planted a tomato and a chilli next to my hibiscus plant, so I took the card out there.

This is what it said:

Look for moist, not waterlogged soil around the Tomato plants.
Examine the timmy for moist, not waterlogged soil.
Observe the soil conditions for both plants during the best time.
Put the phone away and truly look at your plants.

The soil was moist because it had rained the day before, but it wasn't waterlogged. The ground had soaked up the extra water. The card got the one useful thing right, which was to check soil moisture. It had no idea it had rained, so that was partly luck. The rest wasn't great: three of the four bullets say almost the same thing, and "Examine the timmy"(The card calls my chilli "timmy" because that's the nickname I gave it.) is just clumsy. A 4B model does that. With wifi off, the first card took about 30 seconds because the model had to load. After that, each card took about 6 seconds, online or offline.

Demo

The app runs on my laptop, so there's no live link. Here's a walkthrough:

Code

yuvanshankarm007 / touch-grass-garden

A plant tracker that rewards you for going outside, not for opening the app. Local AI (Gemma via Ollama), works offline.

Touch Grass Garden (v3.0)

A plant milestone tracker that rewards you for going outside, not for opening the app.

Detects the local season from your coordinates and the date
Suggests what to sow this month, with the growing method and requirements for each crop
Tracks each plant through growth milestones (sown -> germinated -> ... -> harvest)
Builds a short "today's outdoor card" with a local open-weight model (Gemma via Ollama)
Weather alerts and a best-time-outside window (rule-based, forecast cached for offline use)
The streak counts days you logged a check-in at your plants - opening the app earns nothing
Weekly outdoor goal (default 4 days) with a progress bar - only real check-ins count
Photo log: attach a photo to each outdoor check-in and see it in the plant's timeline
Growth timeline: chart and history of every check-in per plant
Care reminders: watering due dates from crops.json…

View on GitHub

To run it, install Ollama, run ollama pull gemma3:4b, then pip install -r requirements.txt and streamlit run app.py.

How I Built It

I used Gemma 3 (4B) through Ollama, so everything runs on my own laptop. The app is Python and Streamlit. The logic lives in one file and the UI in another, and plants and check-ins are stored in a plain JSON file.

A few choices I made:

All the crop info lives in one crops.json file, and the model is only allowed to use what I hand it. I didn't want a small model inventing planting advice.
The season comes from a simple lookup on location and date, with the Indian calendar (kharif, rabi, zaid) inside India and four seasons elsewhere.
The forecast comes from Open-Meteo and gets saved to a file, so the app still has the last forecast when it's offline and shows how old it is. The alerts and the "best time outside" window are plain rules. The window is the longest stretch of daylight hours that are cool enough, dry enough and not too windy. The model never decides an alert, it only words things.
For the prompt, I told the model to output only the card, use each plant's exact name, combine advice that repeats across plants, keep it under about 70 words, never mention watering unless it's due, and end by telling you to put the phone away.
If Ollama isn't running, the app shows a rule-based card instead, so it never breaks in the garden.
Unit tests cover seasons, streaks, the weekly goal, alerts, watering, the timeline, crop packs and the fallback card. There's also a smoke test that loads the whole app without opening a browser. GitHub Actions runs all of it on every push, on Python 3.11 and 3.12, with a Ruff lint check and a check that every crop pack loads.

The first version of the card told me to water a plant that wasn't due for two days. I had passed in "next watering in about 2 days" and the model took it as an instruction. With two plants it also repeated the same bullet. I fixed it by only sending watering info when it's actually due, and by telling the model not to repeat itself. Even then it looked broken for a while, because my Generate button was showing a cached card. The card is still a bit repetitive, as you can see above, but the bigger lesson was that a small model does better with less context and stricter rules.

I built most of the app with Claude and used GitHub's Copilot coding agent for some follow-up features. The voiceover in the demo is from ElevenLabs.

Why Does Open Innovation Matter?

A planting guide is most useful in a garden or on a farm, and those are the places with the worst signal. An app that needs a connection to work is a bad fit.

Running Gemma locally fixes that. The advice, the milestones and the daily card all work on the laptop. Only the forecast needs internet, and the last one is saved, so it's mostly offline rather than fully offline.

A few other things it made possible:

Your location and plant notes never leave your device. With a hosted API, all of it would go to a server I don't control.
Nothing is charged per request, which matters for something meant for people growing food on a budget.
I can swap in a smaller model on a weaker machine, and I can change how it behaves just by editing the prompt.
Crop packs are just JSON files, so someone who actually grows things in their region can fix my data without touching any code. I'd want that, because my crop data is a starter set and no expert has checked it. The README tells people to confirm it locally.

The limits: a 4B model makes mistakes, which is why alerts are rules and not model output. I've also only tested the app for two days, so I can't show real growth over time yet.

My Agent Session

I didn't record a DevRelay session. The Copilot agent's work is public on GitHub, so here are the issues and pull requests it worked on:

Issues: #1, #3, #5, #7, #9, #11
Pull requests: #2, #4, #6, #8, #10, #12

Prize Categories

Best Use of Gemma: the daily card is written by gemma3:4b running locally through Ollama.
Best Use of GitHub Copilot: I wrote .github/copilot-instructions.md with the project's rules (logic in garden.py with no UI code, alerts are rules and never the model, crop facts only from crops.json, a test for every change). Then I gave the coding agent six real issues and reviewed every pull request before merging. It built the crop-specific temperature alerts (#2), atomic saves and privacy-safe photos (#4), plant and check-in deletion (#6), quieter weather alerts (#8), the calendar heatmap (#10) and a stronger CI workflow (#12). All six are merged. CI runs on GitHub Actions on every push. On #8 I left review feedback, but the agent ran out of monthly credits before it could act on it, so I merged it as it was.
Best Use of ElevenLabs: the narration in my demo video was generated with ElevenLabs text-to-speech using the Eleven v4 model and the "Dev Shah - Smooth and Engaging" voice. Here's the script and the generation I used:

I'm a solo participant.

I’m a first-year CS student building a free, open-source Descript alternative

Yuvan Shankar M — Sun, 11 Oct 2026 06:25:26 +0000

Hi DEV! I'm a first-year computer science student, and I'm excited to finally join the community.

I'm interested in AI, software development and open source. Right now I'm working on a small project to make video editing easier using AI, and learning a lot along the way. I'll share what I build and what I learn here.

I'd love to connect with other developers and learn from you. What's one thing you wish you'd known when you were starting out?