DEV Community: Jayant Jeet Tomar

My phone counts every reel I watch, and a 1.9 GB Gemma judges me for it

Jayant Jeet Tomar — Thu, 22 Oct 2026 07:35:18 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Sloths have one big idea: never do work you can make something else do.

So I built an app that does the one chore I'm worst at: honestly knowing how many reels I watched today.

The idea came from watching my parents. Almost all their free time was going to reels. Then I looked around and realised it isn't just them: babies, kids, millennials like me, parents, even grandparents. Everyone is scrolling in their spare moments. I don't think it's evil. But most of it isn't doing much for us, and most of us don't notice. So I built something that quietly shows you the number and says it out loud, kindly, or with a roast.

Scroll Sloth is an Android app that counts the short videos you watch in Instagram Reels, YouTube Shorts, and Facebook Reels. It shows daily, weekly and monthly totals, and gives you two scores: laziness and unproductivity, each with a "why this score" breakdown. Every night at about 00:30, while the phone is charging, a small Gemma model running on the phone writes a two-sentence verdict about your day. You pick the tone: gentle, or roast.

The lazy part: you don't log anything, you don't open anything, and the verdict is waiting in the morning. The only effort is the shame.

Demo

Landing page and install guide: https://jayant-jeet.github.io/Scroll-Sloth/
Download: signed APK (with SHA-256 checksum) on the latest release

The Play Store listing is still waiting on paperwork, so for now it installs straight from GitHub. On Android 13+ you first need App info > menu > Allow restricted settings before you can switch on the accessibility service. The onboarding screen walks you through it.

Code

Jayant-Jeet / Scroll-Sloth

Scroll Sloth

Scroll Sloth is an Android-only, on-device app for counting short-form video sessions in Instagram, YouTube Shorts, and Facebook Reels. The current build includes onboarding, rule-driven reel detection, daily/weekly/monthly statistics with laziness and unproductivity scores (with a "why this score" breakdown), on-device commentary (Gemma or templates), and the debug Rule Inspector used to collect the real UI structure that detection rules are built from.

Website and install guide: https://jayant-jeet.github.io/Scroll-Sloth/
Download: latest release (signed APK and its SHA-256 checksum)

Architecture overview

app: the only Android application module, written in Kotlin with Jetpack Compose and Material 3.
com.halfbloodcoder.scrollsloth.AppContainer: hand-written dependency container created by ScrollSlothApplication and shared by the activity and the accessibility service (one DataStore instance per process).
com.halfbloodcoder.scrollsloth.detect: supported platforms, the detection-rules schema, loader and repository, RulesUpdater/HttpRulesFetcher (rules fetch), AppStatuses (per-app status), RuleEngine (node tree → DetectorEvent), the pure-Kotlin ReelStateMachine (dwell, dedupe, resets), ReelDetector…

View on GitHub

Is it safe? Privacy in plain words

Privacy turned out to be the thing everyone cared about most. When I shared the app with friends for feedback, "wait, is this watching my phone?" was the first question every time. Fair question. So here are the honest answers.

Scroll Sloth counts your reels. It doesn't watch them.
It saves only the time, the app and how long you stayed. No captions, no names, no screen content. Everything stays on your phone. No server, nothing to sell. You can pause it, export it or delete it anytime. And the code is open for anyone to check.

What does it look at?
Only three apps: Instagram, YouTube and Facebook. Android itself enforces this. The app was never given permission to see anything else, so your messages, photos, banking apps and browser are out of its reach.

What does it look at inside those apps?
Only one thing: "Is a reel on the screen, and did it just change?" It doesn't read captions, comments, usernames or links. It can't tell what you watched. It only knows that you watched one.

What does it save?
Three small facts per reel: the time, which app, and how many seconds you stayed. That's all. It's like a tally mark on a wall.

What does it never save?
What the reel was about, who posted it, what it said, or what was on your screen.

Does anything leave my phone?
Your reel data, never. There is no server, so there's nowhere for it to go. The AI that writes your daily verdict (Gemma) runs on your phone too. The app makes only two internet requests, and both just download public files:

The AI model, once.
A small file of "how to spot a reel" rules, once a week, plus a tiny signature file. The app checks that signature before using the rules, so a tampered file is rejected. You can switch this off in settings.

Neither request carries your data. There is no analytics tool and no ad tool inside the app.

Can I stay in control?
Yes, all of this is in Settings:

Pause counting at any time.
Export your data, or delete all of it with one tap.
Turn off the app's permission in Android settings whenever you want.
Uninstall, and everything goes with it.

How do I know you're not fibbing?
Don't take my word for it. The whole app is open source, so anyone can read the code. The privacy rules are written in the README, and the app limits itself to those three apps in its own configuration file, not just in a promise.

One honest note.
Accessibility is a powerful Android permission, and you should always be careful about who you give it to. That's why I made the app open, kept it to three apps, and keep it fully on your phone. Only download it from the official link, and check the checksum on the release page if you want to be extra sure.

How I Built It

The rule: the model writes words, plain code does maths.
Every number in the app comes from a deterministic Kotlin engine. Laziness is a weighted sum of four things: how many reels (45%), how far above my own 28-day baseline (15%), how many were watched late at night (20%) and my longest unbroken session (20%). Unproductivity is minutes watched against a daily budget. Gemma never touches a number. It only gets a small JSON block of facts and is told to write two sentences using only those.

Then a checker called NumberGuard reads whatever Gemma wrote. Every number in the text (digits, percentages, even "seven") has to be in an allow-list built from the facts. If one isn't, Gemma gets one retry with the bad numbers named. If it fails again, a template engine writes the verdict instead. The card shows a badge, "Written by Gemma on your phone" or "Template", so I always know who to blame.

Counting reels in apps that don't tell you how they're built.
Instagram, YouTube and Facebook don't publish their UI structure, and I didn't want to guess view IDs from memory. So before writing any detection, I built a Rule Inspector: a draggable Capture button (an accessibility overlay, so it needs no extra permission) that saves the structure of the screen: view IDs, classes, sizes, and only whether text exists, never the text itself. I captured a reel screen and a home feed in each app on my Galaxy S24 Ultra, diffed them, and worked out the detection rules from what I could actually see, with GitHub Copilot as my pair for reading the captures. Facebook obfuscates its IDs, so its rule leans on class, size, and position instead.

The rules live in a versioned detection-rules.json, and the unit tests replay my real captures, so a rule change that stops matching them fails the build. The app checks for new rules weekly. When Instagram changes its layout (it will), I fix a JSON file instead of shipping a new APK. A reel counts after 2 seconds, loops are capped at 120 seconds, and scrolling back to a reel within 60 seconds doesn't count it twice.

Signed rules. After a reader asked whether the rules file could be tampered with, I added signatures. Official rule updates are signed offline with an ECDSA P-256 key. The app has two public keys built in (primary and backup), checks the signature before it even parses the file, and keeps its current rules if the check fails. Rules a user imports by hand, or fetches from a custom address, show up as "Unverified" and need confirmation.

Gemma 4 on the phone, and the bug that made it speak in tongues.
The writer is Gemma 4 E2B (instruction-tuned, about 1.9 GB, Apache 2.0, not gated) running through LiteRT-LM on the GPU, with greedy decoding and a 60-token cap. A verdict takes a few seconds on my phone.

The first outputs were fun for the wrong reasons: one sentence told me I had "watchedヒル closely". Mid-sentence, a Japanese word had wandered in. The cause turned out to be a known GPU issue in the public LiteRT-LM tracker (#3879), and Copilot helped me read the issue and turn it into a fix. Switching to FLOAT32 activations with a separate GPU cache directory solved it. I also taught NumberGuard to treat unexpected non-Latin letters as a sign of garbled output and fall back to a template.

The pipeline.
GitHub Actions runs the tests, validates the rules file on every pull request, builds the signed release APK on each tag, and deploys the landing page. Copilot also helped me fix a workflow that wouldn't run.

Stack: Kotlin, Jetpack Compose, Room, DataStore, WorkManager, LiteRT-LM.

Why Does Open Innovation Matter?

A tracker of my own habits has no business in someone else's cloud. Knowing when I scroll, for how long, and how late is about as personal as data gets. With an open-weight model on the phone, the model comes to the data, not the other way round. Nothing about my reel habit leaves the device.
Open weights meant zero friction. Gemma 4 E2B is Apache 2.0 and not gated, so there's no token or terms-acceptance step in the downloader. And once downloaded, it works on a plane for free, forever. There's no per-call bill for a tool that fires once a night.
Open issue trackers saved my afternoon. The garbled-output bug had a public issue with a matching symptom. That's the difference between "my model is broken" and "this is a known GPU precision problem, here's the workaround".
Open rules, open repo. Because detection is a JSON file in a public repo, anyone with a different phone or a newer Instagram can capture, fix and open a PR. The README has a step-by-step guide for it. And because the code is open, my privacy claims above are something you can check, not just believe.

Where closed worked better, honestly:

A cloud model would have been easier to set up and would run on any phone. Mine needs a capable GPU and about 2 GB of storage, and falls back to templates otherwise.
My promo video was made with ElevenLabs, a closed tool. It was easy and the result looks great. I'm not going to pretend an open pipeline would have been faster to get there.

The Lazy Payoff

Doing this by hand is exactly as annoying as it sounds. My calibration screen asks me to tap a +1 button for every reel I really watched so I can compare it to what the app counted. Scroll Sloth is the thing that makes that tap-by-tap tallying unnecessary.

I tested it on my own phone against my own thumb. Results of calibration runs (my manual count vs. the app's count):

App	My count	Scroll Sloth's count	Error
Instagram Reels	5	5	0%
YouTube Shorts	5	5	0%
Facebook Reels	6	6	0%

I knew, I watched a little insta reels before I went to sleep or when work was slow, but watching the actual numbers left me to wonder how much time I am wasting being unproductive. It was a wake-up call. I plan to decrease the amount of time I spend watching reels and maybe do something productive (like reading a book or learn to play guitar 😅)

I shared the app with my friends, and they liked it. But the immediate question that they asked was - "What about privacy?". So, I had to explain the whole project philosophy, and I won their trust finally.

What It Can't Do (Yet)

Android only. iOS has no equivalent of the accessibility service.
It depends on three apps' screen structure, which they can change in any update. The rules were calibrated on one phone (Galaxy S24 Ultra, Android 16), so other devices, app versions, or languages may need new rules.
Counting is close, not exact: picture-in-picture, split-screen, and reels inside DMs or Stories may be missed.

Prize Categories

Best Use of Gemma: Gemma 4 E2B writing every verdict on-device through LiteRT-LM, wrapped in a number checker so it can't invent stats.
Best Use of GitHub Copilot: Copilot helped me work out the detection rules for all three apps from my Rule Inspector captures, find the cause of the garbled Gemma output by reading an open GitHub issue, and fix a failing GitHub Actions workflow.
Best Use of ElevenLabs: The promo video above was made with ElevenLabs.

Now if you'll excuse me, I have a roast waiting for me in the morning. 🦥

My dad's health insurance covered nothing, so I built an AI that reads the fine print for him

Jayant Jeet Tomar — Wed, 14 Oct 2026 18:26:13 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Side Hustle

What I Built

Insurance Samjho ("samjho" = "understand", for the non-Hindi readers). You upload your health insurance policy PDF, and it tells you, in plain language, where the policy will quietly leave you paying out of pocket.

Here's why it exists.

A few insurance agents got hold of my father. You know the type: warm smile, big promises, "sir, everything is covered." He bought a policy. Then he was hospitalized for knee pain, and nothing was covered. Nothing. Zero. The "everything" in "everything is covered" was doing a lot of heavy lifting.

So I did what any slightly furious son would do: I read the entire policy. Forwards. Then backwards, in case the plot twist was at the end. Verdict: a deeply mediocre policy, nowhere near worth the premium he was paying.

And my dad isn't special here. Most people holding a health policy have no idea what's actually in it. Policy documents are 40+ pages of legal English written by people who are paid by the word and punished by clarity. Nobody reads them until the hospital bill arrives, and by then it's a bit late for reading.

So now you upload the PDF and get risk-level cards: long waiting periods for pre-existing diseases, room rent caps, deductibles, sub-limits, co-pays and more. Every finding links back to the exact quote from your policy, so you're not trusting an AI's vibes. You can check it yourself.

The whole site also works in Hindi, because the people who most need this are often the least served by English-only tools.

Who would pay for this? Anyone about to buy, renew, or claim on a policy. That's a lot of people. It's also the exact tool I wish someone had handed my dad before the agent finished his pitch.

Demo

🔗 Live: insurancesamjho.tech

Upload a policy and the app walks through four steps: segmenting the PDF pages, extracting coverage, cross-checking quotes against the original text, and building an "Out-of-Pocket Map."

Then you get your results. For the sample policy below it found 13 things worth a look: 4 high risk (red), 8 medium (yellow), and 1 note. Start with the red cards.

And the same results in Hindi, one click away:

Code

Jayant-Jeet / insurance-samjho

🛡️ Insurance Samjho (Health Insurance Check Karo)

Hacktoberfest 2026 - Week 2 (Side Hustle) Submission

Insurance Samjho is a privacy-first, local-AI web application that reads dense health insurance policies and instantly generates an "Out-of-Pocket Map." It tells users exactly when they are covered and when they will have to pay from their own pocket—without ever sending highly sensitive financial and medical documents to closed-source cloud providers.

🚀 The Architecture

This project utilizes a modern, decoupled full-stack architecture built for local-first AI:

Frontend (React / Vite / Tailwind): A high-trust, responsive UI utilizing Apollo Client to map financial risk via dynamic scenario cards.
API Gateway (Java Spring Boot / GraphQL): Orchestrates the data flow. Handles multipart PDF uploads via REST and serves complex, nested UI data via GraphQL.
ML Microservice (Python / FastAPI): Runs vLLM with Gemma 4 (12B). It segments PDFs and uses constrained decoding (guided_json) to…

View on GitHub

How I Built It

The pipeline is simple on purpose:

Upload the policy PDF.
Parse it with Gemma (gemma-2-9b-it) and extract the sections that matter: waiting periods, exclusions, caps, co-pays.
Cross-check each finding against the original text, so every card carries the exact supporting quote.
Translate on demand into Hindi with IndicTrans2 (AI4Bharat), another open model.

The part I'm most pleased with is that you choose where the model runs:

Local LLM (Private): vLLM serves Gemma on your own machine, so your policy never leaves your device. The site has a built-in setup panel with the exact commands for Windows (WSL2), macOS, and Linux, plus a "Refresh Status" button, so you can see that the parser and translator are running before it lets you upload.
Online LLM: for the 95% of humans who don't have a GPU lying around, the same Gemma setup is hosted on Modal. I'll be honest: the cold start is my villain origin story. On a cold start, parsing one policy sometimes took close to 30 minutes. I stared at a spinner long enough to reconsider my life choices (and my hairline). Once the container is warm it's fine, and I haven't found a fix I can afford yet, so for now that's the price of "free." If you have a GPU, Local mode skips the wait entirely.

The backend runs on Render.

The frontend lives on a .tech domain, which I got free for a year through the Hacktoberfest promo. If people actually start using Insurance Samjho (fingers crossed), I'll happily keep it there and renew every year.

I also leaned on the GitHub Copilot coding agent for the part I was dreading most: model setup. I have two models (Gemma for parsing, IndicTrans2 for Hindi), each with its own docs, serving flags, and parameters that all look equally mysterious until something breaks. Normally that's a weekend of tabs, GitHub issues, and muttering. Copilot read through the options, configured both models, and helped me debug performance problems, so I could spend my time on the actual product. Model setup went from "ugh" to a piece of cake.

Known rough edges: it's a 9B model, not a lawyer. Sometimes it repeats a finding in two cards (you can spot the pre-existing waiting period twice in the screenshot above) or flags a benefit as a risk. That's exactly why every card shows the exact quote from your policy: so you can verify it instead of trusting me. Please treat it as a "questions to ask your insurer" list, not legal advice.

Why Does Open Innovation Matter?

Because of what a health insurance policy is. It's full of personal health and financial details. Uploading that to a random closed API and hoping for the best felt wrong to me.

Open-weight models let me do things a closed API couldn't:

Privacy: run Gemma locally, so the document never leaves the user's machine. A closed API can't offer that option at all.
Language: IndicTrans2 is built for Indian languages. For a product aimed at people like my dad, "Hindi support" shouldn't mean a translation that reads like it was dictated to a very confused robot.
No lock-in, no meter I can't control: I'm a solo dev with a free domain and a Modal bill I'd rather not look at, so open models are the only reason this is financially possible. With a closed API, every policy a stranger uploads would cost me per token, and a tool people use once or twice a year can't really charge for that.

My First User

The first (and toughest) user was my dad. He's the reason this project exists, so it felt right that he got to try it first.

His review: he loved it. His only complaint was the parsing time, which is fair, and see the Modal section above for my own pain on that.

He now understands his policy far better than he did after paying the premiums for a year. Then something happened that I did not plan for: I caught him taking screenshots of his results and sending them to the insurance agent on WhatsApp. The agent who sold him the policy. The one who said everything was covered.

Would he pay for it? Obviously not. He's a typical Indian dad, and the idea of paying for a website is deeply offensive to him. But he did send the link to a bunch of relatives and then phoned them to explain how it works. That's a better growth strategy than anything I could have planned.

I've built a lot of things, but I've never seen one of them used to confront someone in real time. 10/10 would recommend to every family with an agent problem.

Prize Categories

Best Use of Gemma: Gemma does the policy parsing, both locally and online
Best Use of Render: hosts the backend
Best Use of GitHub Copilot: model setup, configuration, and performance debugging
Best Use of a .tech Domain: insurancesamjho.tech, free for a year via the Hacktoberfest promo, and I plan to renew it if people adopt the site

One Last Thing ☕

If Insurance Samjho saved you from a bad policy (or finally made you read the one you have), I'd love to hear about it. The results page also asks if it was helpful, and if it was, you can buy me a coffee. It funds the Modal GPU bill and my ongoing recovery from reading insurance PDFs.

And if you ever meet an insurance agent who says "everything is covered," please upload first, believe later.

4,271 plants, zero bars: BioDex, an offline Pokédex for the plants around you

Jayant Jeet Tomar — Wed, 07 Oct 2026 03:03:54 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Hacktoberfest said “touch grass"... so I built an app that literally makes you do it.

Meet BioDex — an Android game where plants are your Pokémon cards. Snap a pic 🌿📸, wait a few seconds, and boom: you’ve got a collectible card with the plant’s name, rarity, and a fun little field note. XP, a daily streak, and a daily field mission push you to go find the next one. The only way to fill the Dex is to leave the house.

The screen is meant to be the shortest part of the walk: one photo, five seconds of waiting, then the phone goes back in your pocket. This Saturday morning I tried it for 30 minutes in my society’s park and collected 8 cards. It took me back to my biology classes, where we learned the scientific and common names of plants and animals. I used to remember so many of them, like Mangifera indica for mango. It was a nice flashback to my school days.

🌱 Features:

• Camera-based plant capture for collectible cards
• Learn scientific names and common names of flora
• Rarity system (S‑rank, rare, common) for added challenge
• Offline gameplay — no internet required (apart from downloading the model on first run)
• Educational yet fun: explore, collect, and build your own flora deck
• Safe and private: no personal data collected or shared

Demo

A short screen recording shows BioDex in action:

🎮Try it

Join the closed testing group through this Google Group: BioDex Closed Testers
Or download the signed APK from GitHub: BioDex-v1.1.3.apk

Code

Everything lives in one repo: the Android app, the model export script, and the Gemma note generator.

Jayant-Jeet / BioDex

BioDex

BioDex is an Android-first, offline plant-collector MVP built with Kotlin, Jetpack Compose, CameraX, and the official Imageomics BioCLIP 2.5 ViT-H/14 image encoder. Capture a plant photo, find its closest match in a 4,271-species field guide, generate a field card, save it locally, and share the PNG.

Run

Prepare the official model

The app uses the official checkpoint, not the smaller distilled student. The upstream OpenCLIP/PyTorch checkpoint is about 3.94 GB. Before building the app:

Install Python 3.13 and create the project environment with py -3.13 -m venv .venv.
Install the model-export dependencies: .venv\Scripts\python.exe -m pip install -r scripts\requirements-bioclip-export.txt.
Run .venv\Scripts\python.exe scripts\export-bioclip-25-onnx.py.

The exporter verifies the existing 4,271-label embedding table against its published SHA-256 (the model author identifies it as the teacher's text-embedding space), downloads the checkpoint at a pinned Hugging Face revision, exports an FP16 ONNX image encoder, and verifies its output against OpenCLIP and…

View on GitHub

How I Built It

BioDex is a Kotlin app: Jetpack Compose for the UI, CameraX for the camera, ONNX Runtime for the model. The interesting part is what the model is and where each half of it runs.

BioCLIP, split in half. Only the image encoder runs on the phone. The 4,271 plant names were turned into embeddings ahead of time and ship as a table. At runtime, a photo becomes a vector, which is compared against that table with cosine similarity. The closest match becomes your card.

Gemma at build time. Gemma 4 E4B, running locally through Ollama, wrote a common name and a short field note for all 4,271 plants, once, with a resumable script. No language model runs on the phone. The notes describe the species, not your photo, and they can be wrong.

Shipping releases. I run a GitHub Actions workflow manually and choose whether the change is a patch, a minor or a major release. It bumps the version, then builds a signed AAB for the Play Store and a signed APK for sharing locally, such as the v1.1.3 link above.

🤦Things that went wrong (lol)

Testing on my own phone turned up two problems:

1. Random objects came back as plants. I photographed things that weren’t plants at all, and BioDex still returned the closest plant in the guide. Similarity always finds a nearest neighbour. I fixed it with a minimum cosine-similarity threshold of 0.45, so below that BioDex says it doesn’t recognise the photo.

2. Plain-looking plants give false matches. If the plant shows no distinguishing features, such as leaves and small buds but no recognisable flower, the model can still return a confident-looking wrong species. The threshold doesn’t catch this, because the photo is plant-like enough to pass. The similarity score isn’t a confidence level, so BioDex treats it as a suggestion, never a verdict.

Other rough edges:

Specimen #0001: the note said small pale flowers, and my photo was full of pink ones.
Plants only. Animals and fungi aren’t in the guide, and a plant that isn’t listed can only come back as its closest cousin.
Never use BioDex to decide whether a plant is edible, poisonous or medicinal.

Why Does Open Innovation Matter?

On the trail	Open (BioCLIP, ONNX Runtime)	Hosted vision API
No signal	Works after one model download	A spinner
Photos of your garden or kids	Stay on the phone	Uploaded
Cost	No per-photo fee or API key	Per call
Reproducibility	Pinned revision, verified checksums, swappable encoder	Can change underneath you

Where closed would have won. A hosted model would probably know far more than 4,271 plants, handle animals and fungi too, and wouldn't need 1.26 GB of my phone. Open cost me storage, RAM and one very long export script instead of money and privacy. For a game whose whole point is walking somewhere without signal, I'd make that trade again.

I also didn't have to invent any of the hard parts. The Imageomics Institute trained and open-sourced the model, Nate Hamilton published a plant list and embeddings I could build on, Google's Gemma wrote the notes, and ONNX Runtime ran the whole thing on a phone. I wired them together and put a card game on top. That's open innovation at hobby scale.

Prize Categories

Best Use of Gemma. Gemma 4 (E4B), running locally through Ollama, wrote the common name and field note for all 4,271 plants. It runs at build time, not on the phone, and the generator is a resumable script in the repo.

Best Use of GitHub Copilot. I used Copilot to generate the GitHub Actions workflow that prepares releases. I choose patch, minor or major, and it versions the app and builds a signed AAB and APK, so each release is one click to publish to the Play Store or share locally.

Interview Prep Buddy - Helping my friend prepare for his next job switch 🤫

Jayant Jeet Tomar — Sat, 03 Oct 2026 19:35:02 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built Interview Prep Buddy, a privacy‑first web app that helps my friend prepare for job interviews. The tool lets them upload their resume and paste a job description, then generates commonly asked interview questions tailored to their skills and experience. It also highlights strengths and gaps in the resume for that specific role, so they can prepare compensating answers.

The app goes further with a mock interview mode: an AI voice asks questions, the user responds via speech, and the system scores their answers, identifies gaps, and adds follow‑up questions. It’s a supportive, interactive way to practice interviews without risking personal data.

Demo

interview-prep.online

Code

Jayant-Jeet / interview-prep-buddy

Interview Prep Buddy

Interview Prep Buddy matches a resume to a job description, creates a role-aware question bank, and scores spoken or typed practice answers. Question generation runs in Ollama on each visitor's own device; the app does not use a hosted inference service.

Requirements

Node.js (only needed to run the local static development server)
Ollama installed on the device running the browser
The llama3.1:8b model

Download the model in a terminal:

ollama pull llama3.1:8b

Keep Ollama running while using the app. The app connects from the browser directly to http://localhost:11434; resume and job-description text are not sent to this project's web server.

Run the hosted website with local Ollama

Install Ollama on the device running your browser and download the model:
```
ollama pull llama3.1:8b
```
On Windows, allow the hosted website's exact origin in Ollama. In PowerShell, run:
```
setx OLLAMA_ORIGINS "https://www.interview-prep.online"
```
If OLLAMA_ORIGINS already has values, add…

View on GitHub

How I Built It

Open‑Source AI: Powered by Llama running locally via Ollama.
Frontend: Minimalist single‑page web app (HTML, CSS, lightweight JS).
Speech Integration: Browser‑based speech recognition and synthesis for interactive interviews.
Evaluation: AI + rule‑based scoring for clarity, technical accuracy, and confidence.

The USP is that resumes and job descriptions are processed entirely on the user’s device. Nothing is sent to external servers, ensuring complete privacy.

Why Does Open Innovation Matter?

Open innovation made this project possible. Running open‑weight models locally means users don’t depend on closed APIs or external services. They keep control of their data, while still benefiting from advanced AI capabilities. This freedom to adapt, extend, and run inference locally is exactly why open‑source AI matters — it empowers individuals to build tools that are both useful and trustworthy.

Prize Categories

Best Use of GitHub Copilot

DEV Community: Jayant Jeet Tomar

My phone counts every reel I watch, and a 1.9 GB Gemma judges me for it

What I Built

Demo

Code

Jayant-Jeet / Scroll-Sloth

Scroll Sloth

Architecture overview

Is it safe? Privacy in plain words

How I Built It

Why Does Open Innovation Matter?

The Lazy Payoff

What It Can't Do (Yet)

Prize Categories

My dad's health insurance covered nothing, so I built an AI that reads the fine print for him

What I Built

Demo

Code

Jayant-Jeet / insurance-samjho

🛡️ Insurance Samjho (Health Insurance Check Karo)

🚀 The Architecture

How I Built It

Why Does Open Innovation Matter?

My First User

Prize Categories

One Last Thing ☕

4,271 plants, zero bars: BioDex, an offline Pokédex for the plants around you

What I Built

🌱 Features:

Demo

🎮Try it

Code

Jayant-Jeet / BioDex

BioDex

Run

Prepare the official model

How I Built It

🤦Things that went wrong (lol)

Other rough edges:

Why Does Open Innovation Matter?

Prize Categories

Interview Prep Buddy - Helping my friend prepare for his next job switch 🤫

What I Built

Demo

Code

Jayant-Jeet / interview-prep-buddy

Interview Prep Buddy

Requirements

Run the hosted website with local Ollama

How I Built It

Why Does Open Innovation Matter?

Prize Categories

Community Feedback