DEV Community: Harsh Tuli

SlothScroll: I Taught Gemma to Read Instagram So I Never Have To

Harsh Tuli — Sat, 24 Oct 2026 08:01:27 +0000

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

What I Built

Every morning I opened Instagram "just to catch up", and every morning the feed won. One quick check became another, with ads, reposts and giveaways in between.

SlothScroll is my lazy fix. It's a morning digest of the Instagram pages I follow. Once a day a cloud browser visits those pages for me. Gemma, Google's open-weight model, reads every new post and writes a one-line gist. It also sorts the post into a topic (Sports, Science, Finance, Tech…) and quietly drops ads, reposts and giveaways. What I get is one calm page and one email, grouped by topic, with the 1–3 posts actually worth opening.

I read it in about two minutes with my coffee, then close the tab. I never open Instagram.

Who gets to be lazier? Anyone who follows news, sports or creator pages to stay informed, not to scroll.

Demo

🔗 Live: https://slothscroll-web-ngb7.onrender.com

What you'll see in the video:

Today's edition: a greeting, the "scrolling saved" number, topic tabs, and Gemma's summary for each topic with its top picks
The archive, an RSS feed per page, and dark mode
The morning email, the same edition delivered to my inbox

Code

452Harsh / SnoozeFeed

The latest code is on the SlothScroll branch.

How I Built It

Gemma (gemma-4-26b-a4b-it) is the brain. It runs through an OpenAI-compatible client set by environment variables (AI_BASE_URL, AI_MODEL), so the same code can point at a hosted endpoint or, by changing one variable, a local Ollama. I use it for three jobs:
1. Per post: a one-line gist, the post's topic, and whether it's an ad, repost or giveaway. All three come back as JSON from a single call. When a caption is only emojis and hashtags, Gemma looks at the image instead.
2. Per page: a fallback category when I don't set one.
3. Per topic: a 2–3 line summary plus the posts worth opening.
Browserbase + Stagehand give it a real browser. I log in once through Browserbase's live view, and a persisted context keeps that session for daily runs.
MongoDB Atlas is the data layer. The cron job writes, the website reads, and a unique index on the post URL means a post is never processed twice.
Render runs everything from one render.yaml Blueprint: a cron job for the daily pipeline and a web service for the site. Every secret is sync: false, so none live in the repo.
The website is server-rendered HTML on Hono, with no frontend framework. It has light and dark mode, works on mobile, and loads quickly.
ElevenLabs narrated the demo video.

Slow and steady by design: one run per day, public pages only, visited one at a time with random pauses. A page that fails is noted, and the edition still ships. If Instagram asks for a login, SlothScroll stops and tells me instead of trying to get around it.

What broke (and how I fixed it)

Gemma was slow for this job. A demo run took about 4 minutes because the model reasoned before every answer. Setting reasoning_effort: "minimal" brought it down to about 20 seconds, with the same quality for one-line gists.
Everything was "News". Topics were assigned per page, so a football page's posts and an IPO story all landed in News. Now Gemma chooses a topic per post in the same call, with no extra requests. On my real feed the same 16 posts went from one topic to five.
The browser died mid-run. Browserbase sessions end after 5 minutes by default, and a full run takes longer. Asking for a 30-minute session fixed it.
Half-emoji headlines. Shortening captions sometimes cut an emoji in half and left "�". The page now cleans those characters before showing them.

Why Does Open Innovation Matter?

What you follow says a lot about you. Your reading habits are personal, and an open-weight model means this digest doesn't have to depend on one company's closed API:

I choose where it runs. Gemma is reached through a plain OpenAI-compatible endpoint, so switching providers is an environment-variable change. The client is built to switch to a local Ollama the same way, so the posts never have to leave my machine.
It's cheap enough to run every day forever. A small open model is plenty for one-line gists and topic tags. It's a daily habit, not a premium feature.
It's inspectable and forkable. The prompts, the pipeline and the model are all open, so anyone can adapt SlothScroll to their own pages, language or topics.

The Lazy Payoff

From a real run this week, using a deliberately conservative estimate of 8 seconds per post:

16 posts from my pages became 5 topics and one page, about 2 minutes of scrolling saved that day.
0 times I opened Instagram.

The real win is bigger than the 8-second math. One "quick check" usually turns into twenty minutes. SlothScroll ends the session before it starts, and it scales with the pages you follow: I've since added six more (The Verge, National Geographic, CNBC, Tasty, Netflix and 9GAG).

Prize Categories

Best Use of Gemma: Gemma writes the gists, picks the topics, filters ads and summarizes each topic.
Best Use of Render: a Blueprint with a cron job for the agent pipeline and a web service for the front end.
Best Use of Browserbase: Stagehand drives a real browser with a persisted login, as a repeatable daily workflow.
Best Use of MongoDB Atlas: the database behind an app built on an open-weight model.
Best Use of ElevenLabs: narration for the demo video.

Outward: an adventure story that only moves forward when you go outside

Harsh Tuli — Sun, 11 Oct 2026 05:43:36 +0000

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

What I Built

Outward is a story game you can't play from the sofa. You are the main character of an adventure, and the next chapter only unlocks when you go outside, finish a small real-world mission, and tell the story what you found.

"The Archivist needs something the city has forgotten. Walk for ten minutes and find a mark someone left on purpose."

You pick 10, 30 or 60 minutes, put the phone in your pocket, and walk. When you've actually covered the distance (250 m, 700 m or 1.4 km, tracked by GPS), Outward wakes up and asks what you found: "a chalk heart drawn on the pavement." A small language model running on your phone writes that chalk heart into the next part of the story, ends on a cliffhanger, and the chapter is done. Your find goes into a field journal, and Sprig, a small leaf-sprout companion, celebrates with you.

It's for anyone whose screen time has quietly crept past their outside time, including me. Most "go outside" apps use guilt (streaks, step counts, red rings). Outward uses curiosity instead: you go outside because you want to know what happens next, and the story can't happen without something you saw with your own eyes.

Three things I cared about:

The story is really about your walk. Every chapter is written around your discovery, not picked from a list. The puddle, the cat on the wall and the chalk heart become plot.
Phone in pocket, not in hand. During a mission the screen tells you to put it away. There's no map to stare at and no feed. The app counts screen-off time as a good thing.
It works with no signal. After one install, the whole thing runs in airplane mode: the storyteller model, voice-to-text, narration and safety rules. Parks, trails and basements don't break it.

Two partners, two jobs:

🧠 Tinker trains the brain. I fine-tuned Qwen3.5-4B on Tinker and distilled it into a 241 MB Gemma that writes almost as well as its 4B teacher (4.75 vs 4.79). Total cost: $2.56.

🚚 Render delivers it. One Render service ships the app, the model weights and new story seasons to every phone, with the browser headers that make on-device AI fast and a guardrail on bandwidth cost. After that, the phone needs no internet at all.

Demo

🔗 Live on Render: https://outward-6fhh.onrender.com (install it as an app from the browser menu)

🩺 Live server status: https://outward-6fhh.onrender.com/api/health (deployed commit, model ready on the Render disk, bandwidth used this month)

What to try:

Open it once on Wi-Fi. The setup screen "packs your bag": it downloads the 241 MB storyteller and the 44 MB voice model, then tells you it's safe to go offline.
Turn on airplane mode and start Chapter 1. Everything still works.
No time to walk right now? Settings → Practice mode skips the walking check so you can see the whole loop at your desk. (Real chapters do want the walk.)
Settings → Diagnostics shows which model is installed, tokens per second on your phone, and the last chapters it wrote.

In the video, the chapter after "a chalk heart drawn on the pavement" is written live with the network switched off, in about 2–3 seconds.

Code

452Harsh / outward

Outward: your story happens outside. Offline PWA with an on-device Gemma storyteller.

Outward

Your story happens outside.

Outward is an installable web app (PWA) that turns a walk into an adventure. You are the main character. The story moves forward only when you go outside and complete real-world missions, like "find something that flows." You describe what you found, and a small open-weight model running on your phone weaves it into the story.

After one install, it works fully offline: no signal needed, and nothing about your location, voice or walks leaves the phone.

Status: Phase 7 of 8. The offline PWA, the 5-chapter story, an on-device Gemma 3 270M storyteller and on-device voice input (Whisper) work in airplane mode, along with walking-gated missions, a drawn walk path and screen-time stats. The phone now runs a Gemma 3 270M that was distilled from a Tinker fine-tuned Qwen3.5-4B (rubric 2.55 → 4.75; see training/RESULTS.md). A story factory ships new reviewed, narrated story…

View on GitHub

A monorepo: /app (the PWA), /server (Render), /training (Tinker fine-tune, distillation and evals), /content (stories, safety rules, prompts and the model registry). It's MIT licensed, with the Gemma weights under Gemma Terms.

How I Built It

The core problem: a good storyteller is a 4B model, but a phone in a park needs something about 15× smaller that never calls home. So I used open-weight models end to end: I trained a teacher in the cloud, distilled it into a tiny student, and shipped the student to the phone.

                       ┌──────────── TRAINING (one-off, ~$2.56) ────────────┐
 648 hand-checked  ──► │ Qwen3.5-4B ──LoRA on Tinker──► Teacher v3          │
 seed chapters         │                                   │                │
                       │                     2,500 prompts × 3 samples      │
                       │                     rubric + safety filter         │
                       │                                   ▼                │
                       │        3,186 examples ──► Gemma 3 270M (Kaggle)    │
                       │                           full fine-tune ► GGUF Q4 │
                       └───────────────────────────────────┬────────────────┘
                                                           ▼
  Render (Starter, Singapore)                 Phone (offline after install)
  ┌──────────────────────────┐   one-time    ┌───────────────────────────────┐
  │ Fastify: PWA + /models   │──download────►│ Preact PWA + Service Worker   │
  │ 1 GB disk, HF fallback   │               │ wllama (llama.cpp → WASM)     │
  │ /api/packs (new seasons) │               │ Whisper tiny.en (ONNX, WASM)  │
  └──────────────────────────┘               │ Safety filter (JS)            │
                                             │ GPS walk gate · IndexedDB     │
                                             └───────────────────────────────┘

Open-source AI

Role	Model / tool	Where it runs
Teacher storyteller	Qwen3.5-4B + LoRA r32	Tinker (training + sampling)
On-device storyteller	Gemma 3 270M, distilled, Q4_0 GGUF (241 MB)	The phone, via wllama (llama.cpp WASM, WebGPU or CPU)
Optional bigger model	Gemma 3 1B QAT Q4_0 (720 MB)	The phone, downloaded from Hugging Face
Voice → text	Whisper tiny.en int8 (44 MB)	The phone, via Transformers.js + ONNX Runtime WASM in a worker
Student training	Hugging Face TRL SFT	Kaggle notebook (free GPU)
Conversion	llama.cpp `convert_hf_to_gguf` + `llama-quantize`	My Mac
App, model and story delivery	Fastify + persistent disk	Render (Starter, Singapore)

Step 1: Fine-tune the teacher on Tinker

Base Qwen3.5-4B already writes decent prose. The problem is that it ignores the player: it mentions your discovery and then carries on with its own plot. In a story whose whole point is "you shaped this," that's the main failure.

I wrote 648 seed chapters, built a 5-point rubric (uses the discovery, coherent, steers the plot, safe, length), and trained a LoRA with per-epoch checkpoints. I picked the checkpoint by validation loss after my first run overfit. Results on 50 held-out prompts × 3 samples:

	Base Qwen3.5-4B	Fine-tuned (v3)
Rubric score (/5)	4.66	4.79
Coherent	93%	99%
Discovery actually steers the plot	6%	39%
Length	93 words	82 words (closer to target)

Steering went from 6% to 39%, about 6.5× better on the property the game depends on. It also held up on a separate dev set (12% → 30%). To be honest about it: the safety checker flagged slightly more outputs (4 → 6), and every one of those came from the player's own words being quoted back, not from anything the model made up.

Step 2: Distil it into something a phone can run

A 4B model doesn't belong in a browser tab on a phone. The teacher generated 2,500 prompts × 3 samples. Each sample was scored by the rubric and the safety filter, leaving 3,186 good examples. I then full-fine-tuned Gemma 3 270M on them in a Kaggle notebook and quantised it to Q4_0 GGUF.

Same 50 eval prompts	Score (/5)	Unsafe flags	Steers plot
Stock Gemma 3 270M	2.55	27	—
Stock 270M + my best one-shot prompt	3.66	6	17%
Distilled Outward student (270M)	4.75	2	44%
Teacher (4B, cloud)	4.79	6	39%

A 270M model at 241 MB comes within 0.04 points of its 4B teacher. It writes a chapter in 2–3 seconds on-device (≈53 tokens/s on CPU) at zero cost per chapter. It also wrote a good chapter for a story season it never saw in training.

Total Tinker spend for the whole project: $2.56.

Step 3: Keep it safe outdoors

A game that sends people outside has to be careful about where. Missions never ask for roads, water edges, strangers, private property, climbing or the dark. Safety rules live in one rules.json that both a JavaScript filter (on the phone) and a Python filter (in training) use. A shared test file of cases keeps them in sync, and CI fails if they disagree. The filter also checks everything the model writes: it must use the discovery, stay on length, not copy the example or echo the prompt, and not talk about being an AI. If an output fails, the player gets a hand-written fallback instead. The app shows which one you got ("Written on this phone" vs "Pre-written").

Step 4: Render, the runtime that gets AI onto the phone

An on-device model still has to reach the device: 241 MB of weights, a WASM runtime that needs special browser headers, and new stories after launch. Render is that delivery layer. It's one Node service (Fastify) on the Starter plan in Singapore, the closest region to me in India, deployed from a single render.yaml Blueprint.

 git push ──► Render build (npm ci && npm run build) ──► health check /api/health
                                                              │
 content/models.json ──(pinned HF revision)──► boot sync ──► 1 GB disk /var/data/models
                                                              │
 phone ◄── PWA + COOP/COEP ◄── /models/<id>/<version>/…gguf ◄─┤  (over budget → 302 to Hugging Face)
       ◄── /api/packs + /packs/<id>/audio/*.mp3 (new seasons)◄┘

What Render does, and why each part matters:

It makes fast on-device inference possible. Every response carries Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy. That cross-origin isolation unlocks SharedArrayBuffer, which llama.cpp's WASM build needs to run on several CPU threads. Without these two headers, the phone's storyteller falls back to a single thread. A plain static host where you can't set headers wouldn't have worked.
The persistent disk is the model store. On boot, the server reads content/models.json, downloads the exact pinned Hugging Face revision of the student model to the 1 GB disk (as a .part file, size-checked, then renamed), and deletes old versions so the disk never fills. Shipping a better model is just a registry entry and a git push: Render rebuilds, the disk syncs, and phones see a new versioned URL.
Caching is designed for an offline app. Model files and hashed assets are served immutable for a year, so a phone never downloads 241 MB twice. index.html and the service worker are no-cache, so app updates still reach installed phones.
Costs have a guardrail. The server counts model bytes it sends each month. After MODEL_BANDWIDTH_BUDGET_GB (60 GB), /models/* answers with a 302 redirect to the identical file on Hugging Face. The app also tries Render first and falls back to Hugging Face by itself. Hosting stays at about $7.25/month, and 100 installs come to roughly $11. The worst case is capped instead of open-ended.
New story seasons arrive without an app update. /api/packs lists approved story packs, and their ElevenLabs narration is served from content-hashed URLs. The app picks them up and caches them for offline play. That's how Season 2 (The Second Atlas) shipped.
No secrets on the server. Render never runs a model and holds no API keys. Tinker and ElevenLabs are only used in the offline story factory on my Mac. If someone breaks into the server, there's nothing to steal and no bill to run up.

It's live, and you can check it yourself:

$ curl https://outward-6fhh.onrender.com/api/health
{"ok":true,"commit":"475692a","app":true,
 "models":[{"id":"outward-gemma3-270m","version":"distilled-v1-133f250","ready":true}],
 "bandwidth":{"month":"2026-10","gb":0,"budgetGB":60},"packs":["second-atlas"]}

I deliberately didn't run the model on Render. A cloud model would need a connection on every walk and would see every user's location. Here, Render does the job a server is good at: shipping, versioning, updating and guarding the cost. The phone does the thinking.

Step 5: Voice, story seasons and CI

ElevenLabs narrates the fixed story text (George, as the Archivist). The clips are rendered once and cached for offline use, about 2.4 MB in total. The model's live text is read by the phone's own voice, with karaoke-style captions and Sprig's mouth synced to the audio.
New seasons: a "story factory" on my Mac takes a human-written plot outline, drafts prose with Qwen on Tinker, applies my edits, renders narration, and only publishes a pack after I approve it. Season 2 (The Second Atlas) cost $0.007 in Tinker credits.
GitHub Actions runs lint, the safety-parity tests, app and server tests, the build and the Python tests on every push.
Install size: 311 MB total (model 241, Whisper 44, runtimes 24, narration 2.4, app 0.1).

Why Does Open Innovation Matter?

Because the whole idea doesn't work with a closed API.

"Go outside" and "needs a connection" don't go together. The moments Outward is built for (a trail, a park, a basement café, a country with expensive roaming) are exactly where cloud APIs fail. Open weights mean the storyteller travels with you. After one download it belongs to you: no rate limit, no outage, no key in the client, and no bill that grows with every walk.

Privacy isn't a setting here; it comes from where the model runs. Outward knows where you walk and what you noticed. With a hosted model, every chapter would send your location and your words to someone else's server. Here, the walk, the voice recording and the story never leave the phone.

Open weights let me change the model, not just the prompt. The biggest jump in quality didn't come from prompt engineering (stock 270M with my best prompt reached 3.66). It came from fine-tuning a teacher on Tinker and distilling it into a 270M student (4.75). You can only do that when you can touch the weights. With a closed API I'd have been stuck asking a model 15× bigger, over the network, to please pay more attention to the chalk heart.

Open weights are weights I'm allowed to host. Because Gemma and my distilled student can be redistributed, the model sits on my Render disk, versioned next to the app that uses it and cached forever on the phone. A closed model can't be downloaded at all, let alone hosted on a $7 server and carried into a park.

And it was cheap enough for one person in a week. Qwen and Gemma weights, llama.cpp, wllama, Whisper, Transformers.js, ONNX Runtime and TRL are all open. The cloud cost of training both models was $2.56. Everything I trained is published too: the student weights are on Hugging Face, and the training scripts, evals, rubric and safety rules are in the repo, so someone else can build their outdoor story on top of it.

My Agent Session

I built Outward with Claude Code as my pair programmer. It helped with everything from the Tinker training loop and the eval rubric to the wllama integration, the safety-filter parity tests and the demo-video tooling. I made the product, cost and account decisions; it helped with the implementation and the debugging. One example: it found that the stock 270M "passed" my first rubric by copying the example story word for word, which is why the copies_example and echoes_prompt checks exist.

Prize Categories

Best Use of Tinker: Qwen3.5-4B LoRA fine-tune on Tinker. The plot-steering rate went from 6% to 39% over base, the teacher was distilled into a 270M on-device student that scores 4.75 vs the teacher's 4.79, and the whole project cost $2.56.
Best Use of Render: Render is the runtime that delivers on-device AI, deployed from one render.yaml Blueprint. It hosts the AI app's front end with the cross-origin isolation headers that multithreaded llama.cpp WASM needs. It keeps the versioned model weights on a persistent disk that syncs from a pinned Hugging Face revision on boot. A monthly bandwidth budget redirects to Hugging Face once it's used up, and new story seasons ship through /api/packs. A live /api/health endpoint shows the deployed commit, model readiness and bandwidth use.

Patternwise: Stop Grinding. Start Learning Patterns. Your Open-Source AI Interview Coach.

Harsh Tuli — Sun, 04 Oct 2026 10:30:39 +0000

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

What I Built

Patternwise is a DSA and System Design practice workspace with an AI interview coach built on open-weight Gemma models. It answers one question every morning:

"Given everything I've practised so far, what should I learn, revise, or practise today?"

I built it for Nikhil, a friend from my office who recently started preparing for interviews.

When he started, he jumped between multiple websites and couldn't keep track of his progress across them. Some sites only cover DSA, others only System Design, but today's interviews expect both. And even within one site, a list of hundreds of problems tells you what you've done, not what to do next: Is sliding window still weak? Should I learn something new, or redo what I failed last week? It never tells you to stop.

So I built one place for both DSA and System Design (HLD and LLD), with an AI coach on top that looks at everything he's practised and tells him what to work on today. Now he can just open it and practise.

Patternwise does three things:

Tracks practice by pattern, not by problem. There are 27 topics, 112 patterns and 364 curated LeetCode problems, plus 77 System Design concepts, 35 HLD/LLD patterns and 34 design problems. Every attempt records the result (solved, needed hints, failed), confidence, time, and your own mistake notes.
Computes what matters today, with a deterministic recommendation engine. Each pattern gets an explainable priority built from six signals: weakness, revisions due, time since practice, interview importance, variation coverage and recent trend.
Coaches you through it with Gemma. The model explains the plan using your own data, answers "why do I keep failing this?", gives progressive hints without spoiling the solution, checks your explanations, and plays a realistic interviewer that asks follow-up questions instead of teaching.

The feature I'm proudest of: the coach knows when not to give you another problem. If you keep failing the same idea across different problems, it says so:

Don't solve another problem yet. You've struggled with Variable Window: Longest Valid on 4 different problems recently. Spend 10 minutes on the invariant, then try one guided problem.

That's the difference between a coach and a problem generator.

Demo

🔗 Live: https://patternwise.onrender.com · password: patternwise-demo

The demo account has three weeks of realistic practice history: strong hashing, a sliding-window pattern that keeps going wrong, an overdue binary search, and a System Design concept with slipping ratings. That way you can see the coach react to real signals. Try:

AI Coach → Today's Plan: the priority badge shows exactly how each score was calculated.
Ask Coach: "Why do I keep struggling with sliding window?" The answer quotes the mistake notes from the history.
Interview Mode → System Design → Design a URL Shortener: answer a few questions, then End & get feedback.

Code

452Harsh / patternwise

Pattern-first DSA preparation workspace: curated curriculum, spaced-repetition revision and progress analytics (Next.js + MongoDB)

Patternwise

A personal, pattern-first preparation workspace for DSA (data structures and algorithms) and System Design (HLD and LLD). It combines a curated curriculum with a tracker built around recognition, spaced-repetition revision, daily plans, notes, workspaces and analytics, plus an AI interview coach that runs on open-weight models and answers: "Given everything I've practised, what should I do today?"

It's built with Next.js 16, React 19 and TypeScript, styled with Tailwind CSS v4 and shadcn/ui on Base UI, and stores data in MongoDB. It's a single-user app that you sign in to with a password.

Why

Most practice tracking is a checklist of problems. Patternwise is organised around the pattern instead: how to recognise it, the core idea, a template, variations, pitfalls and where else it applies. Every solve, review and note feeds a spaced-repetition schedule, so things you're shaky on come back before you forget them. System Design gets the…

View on GitHub

How I Built It

Stack: Next.js 16 (App Router), React 19, TypeScript, Tailwind v4 and shadcn/ui; MongoDB Atlas (data plus vector search); deployed on Render.

Open-source AI:

Role	Model	Where it runs
Coaching, hints, interviewer	Gemma 4 26B-A4B	Google AI Studio (production)
Same, fully local	Gemma 4 E2B (QAT, 4.3 GB)	Ollama on my 8 GB M1, about 28 tokens/s
Retrieval embeddings	EmbeddingGemma (768-d)	Hugging Face Inference (production) or Ollama (local)

The rule that shaped everything: the engine decides, the model explains

Small open models are good at explanation and dialogue. They're bad at arithmetic over a user's history, and they'll happily invent "you've solved 12 sliding-window problems". So I split the work:

The engine (lib/coach/) is plain, pure TypeScript and fully tested:

For each pattern it computes success over the last 21 days (hints count half), failures, confidence, due reviews, staleness, per-difficulty results, and variation coverage. Every curated problem teaches one variation, so "10 solved but only 1 variation" is detectable.
From those facts it picks an action (review the concept, revise, strengthen, broaden, level up, learn) and a difficulty move (harder, easier, back to fundamentals).
For System Design it also spots concepts you studied but never applied in a design problem.
The stop rule fires on 3+ shaky attempts across 2+ problems with mostly failed recent attempts. Then it recommends one guided problem, not five more.

Gemma gets those facts as structured text, plus retrieved curriculum. It runs under strict rules: every user-specific claim must come from the supplied data, and if the data doesn't say, it says it doesn't know. The server recomputes all facts from MongoDB on every request, so the browser can't feed the model made-up stats.

RAG on MongoDB Atlas Vector Search:

Indexing: 649 curriculum documents are embedded with EmbeddingGemma (patterns with signals, templates and pitfalls; problems; HLD/LLD concepts, patterns and problems). They live in a knowledge collection with a knowledge_vector index filtered by module.
Search quality: retrieval maps unseen problems to the right pattern. "Longest substring without repeating characters" lands on Variable Window, and "sorted rotated array minimum" lands on Rotated Binary Search.
Fallbacks: if the Atlas index isn't ready it falls back to in-memory cosine, and if the embedding model is down it falls back to keyword search. The coach never just breaks.

DSA and System Design stay separate. Every coach request is scoped to one module, so a System Design answer never drags in your DSA history, and vice versa.

It closes the loop. Interview results, "explain it back" scores, and practice logged anywhere in the app feed straight back into tomorrow's plan.

Things I had to solve:

Gemma 4's inline reasoning: on Google's endpoint it always streams its reasoning as <thought>…</thought>, and switching that off isn't supported for this model. I wrote a small stream filter that drops the block, even when a tag is split across chunks, and adds token headroom so the answer isn't cut short.
Different embedding vectors: EmbeddingGemma from Ollama and from Hugging Face produce different vectors for the same text (cosine ≈ 0.71). The indexer records which embedding model built the index and flags "index needed" when the provider changes.
Testing the engine: 34 checks cover the stop rule, revision priority, difficulty moves, time budgets, and that SD data never leaks into DSA. They run in GitHub Actions CI on every push, alongside lint, type-checking, curriculum integrity checks and the production build.

Why Does Open Innovation Matter?

For an interview coach, open models aren't a philosophy point. They decide who can use it.

It runs on a laptop, for free. The exact same coach runs on Gemma 4 E2B through Ollama on an 8 GB MacBook Air, with EmbeddingGemma for search and MongoDB on localhost: no API keys, no bill. A config switch moves it over, and I checked that while it answers, the app, database and model make zero connections outside localhost (it's in the video at 2:45). Anyone who can't afford a paid prep subscription gets the same coach.
Your preparation data stays yours. Your failures, mistake notes and mock-interview debriefs are personal. With a local model they never leave your machine. Even in the hosted version, the vector store holds only curriculum content; progress and conversations are never indexed.
Swapping models is a config change, not a rewrite. All model calls go through a tiny provider interface. I developed on Gemma 4 E2B locally, deployed on Gemma 4 26B-A4B, and could point it at a GPU server running E4B or 31B by changing two environment variables. No vendor lock-in, no rewrite when pricing or terms change.
The open model made the honest design possible. Because I control the model and the prompt pipeline end to end, I could put a deterministic engine in charge and give Gemma a clear, checkable job. That's why every number on the screen has an explanation behind it.
Open models keep it free to run. Open Gemma on free tiers, MongoDB Atlas and Render keep running costs at about zero. A closed API would turn a personal study tool into a monthly bill.

What Nikhil said after trying it:

"Honestly, I really liked the concept behind [Patternwise]. Instead of just solving hundreds of random DSA questions, it focuses more on understanding the patterns. I feel that once you know the pattern, you can approach and solve a lot of different questions on your own, rather than just remembering solutions.

I also liked the way the preparation is structured with a proper timeline, so it's easier to know what to focus on and when. The System Design part is also really helpful because it covers both LLD and HLD. Overall, I think it's a much more practical way to prepare for interviews instead of just going through a huge list of problems."

That's exactly the shift I was going for: from how many problems have I solved? to which patterns do I actually understand?

My Agent Session

I built Patternwise with an AI coding agent, Claude Code, as my pair programmer. I set the direction: what Nikhil needed, the features, the design decisions, and what to cut. I also tested every step in the browser. The agent wrote and refactored most of the code with me, ran the checks, and debugged the issues we hit along the way, like Gemma 4's inline reasoning tags and the embedding mismatch between Ollama and Hugging Face.

Prize Categories

Best Use of Gemma: Gemma 4 26B-A4B powers all coaching, hints and interviews in production; Gemma 4 E2B runs the same app fully locally; EmbeddingGemma powers retrieval.
Best Use of Render: the whole app (the coach's front end and API) is deployed on Render as a Blueprint (render.yaml). The repo also includes an optional Render Blueprint that self-hosts Gemma via Ollama behind a key-checking proxy (deploy/render-ollama).
Best Use of MongoDB Atlas: Atlas is the data layer for all progress, sessions and plans, and Atlas Vector Search retrieves the curriculum for every grounded answer.
Best Use of ElevenLabs: the demo video's narration is generated with ElevenLabs (voice "Eric"), split per scene and timed to the footage.
Best Use of GitHub Copilot: GitHub Actions CI runs lint, type-checking, curriculum integrity, the 34 coach-engine checks and the production build on every push, plus a weekly job that re-verifies all 364 LeetCode links.