DEV Community: vishu

Building LeetRun: How I Turned Scattered LeetCode Prep into a Gamified SaaS Platform

vishu — Sat, 29 Aug 2026 14:02:55 +0000

Live at leetrun.vercel.app - guest preview at /sheets, /patterns, /analytics before signup

The Problem: Prep Is Scattered, Unmotivating, and Lonely

If you have ever prepared for a software-engineering placement cycle, you know the ritual: open Blind 75 in one tab, NeetCode 150 in another, Striver's sheet in Notion, LeetCode in a third window, and manually tick boxes when you finally get an Accepted verdict.

Nobody tells you which pattern you are weak in relative to Google or Amazon interviews. Nobody holds you accountable when you skip a week. And every AI chatbot gives the same generic two-pointer lecture whether you solved 200 mediums yesterday or zero.

I built LeetRun to close that gap.

The Core Insight

The data already exists on LeetCode. The GraphQL API exposes full submission history. The product opportunity was indexing that history against curated sheets and wrapping it in motivation loops — not building another problem database from scratch.

What LeetRun Actually Ships

Curated sheets — Blind 75, NeetCode 150, Striver SDE, Striver A2Z, Striver 79, Love Babbar 450, Google Top 100, Amazon Top 100
Deep LeetCode Sync — one import of your full accepted history auto-checks every matched problem on every sheet
Interview patterns — DP, graphs, two pointers, sliding window and more, ranked by weightage with C++ templates
Build-your-own revision — random sets filtered by topic, difficulty, and solved state
Adaptive quests — daily, weekly, revision quests generated from weakest topics and target company, auto-verified against real solves
Savage AI mentor — context-aware coach with personality modes from supportive to savage (Pro unlocks full roast mode)
Leaderboards — global and friends boards by XP, level, streak, solve count, or contest rating
Multiplayer rooms — private 6-char codes, live solve progress, mock contests with your batch
Public profiles — shareable analytics, levels, streaks, badges for resumes and LinkedIn

Deep Sync: One Import, Every Sheet Auto-Checked

Basic LeetCode integrations show public profile stats. Deep Sync goes further.

User authenticates once with LeetCode session token
→ Backend fetches full accepted submission graph via GraphQL
→ Submissions normalised and matched against 1,500+ problem corpus
→ Every sheet row updates atomically
→ Client caches in localStorage SWR for instant repaint

The reaction in user testing was always the same: "Wait, it already knows I solved all of these?"

Yes. That is the point.

Savage AI Mentor: Context Snapshot + RAG, Not a Chatbot Wrapper

When a user asks LeetRun a question, we do not pass a bare prompt to Gemini or Groq. We compile a context snapshot first:

LeetCode stats and current streak
Active daily quests
Sheet completion percentages
Weakest pattern families by weightage

On top of that, a RAG retrieval layer searches a corpus of 1,500+ indexed problems, 21 interview pattern families, and system-design notes. Lexical scoring selects citeable chunks before generation — reducing hallucinated constraints and invented problem variants.

Why Both Gemini and Groq?

Use Case	Model
Complex explanations, multi-step reasoning, system design	Gemini
Low-latency mid-session coaching	Groq

The router sends queries to the optimal model based on complexity, expected response length, and whether the user is in savage mode (Pro) or standard coaching (Free).

Gamification That Respects the Grind

Interview prep is a marathon. Consistency beats intensity.

XP system — Easy 15, Medium 40, Hard 120, verified against real LeetCode accepts
Streaks and levels — visible on public profiles and leaderboards
Adaptive quests — daily (Free), weekly and revision (Pro)
Leaderboards — global and friends, pre-fetched server-side with 60s revalidation
Multiplayer rooms — 6-character codes, live member progress, mock contests
Badges and coins — tied to verified solves and quest completion

Pricing (Student-First, INR)

Tier	Price	Highlights
Free	₹0 forever	Sync, daily quests, basic leaderboard, standard AI, 1 room
Pro	₹299/month	Weekly + revision quests, savage AI, unlimited rooms, badges
Team	Custom	Up to 20 members, shared leaderboard, admin analytics

Founding offer: Pro free for the first 200 users, no credit card required.

Why PostgreSQL Over a Document Store

LeetRun's data model is deeply relational: users, problems, sheets, user-problem join tables, quest progress, XP events, leaderboard rankings, multiplayer room state, and friend graphs.

Firebase could work for a MVP checklist app. It would fight you once you need ranked leaderboards, quest verification against historical solves, and room state with live member progress.

Five Caching Layers

1. Next.js unstable_cache — leaderboard and profile data, 60s revalidation
2. HTTP Cache-Control (s-maxage + stale-while-revalidate) — analytics API routes
3. In-memory memoization — 1,500+ problem corpus loaded at boot
4. localStorage SWR — instant sheet and analytics repaints on client
5. Vercel Edge CDN — guest-preview routes (/sheets, /patterns, /analytics)

Stack Summary

Layer	Choices
Frontend	Next.js 16, TypeScript, Tailwind CSS
Auth & Data	Supabase Auth, PostgreSQL, Prisma ORM
AI	Gemini API, Groq API, RAG retrieval, lexical scoring
External	LeetCode GraphQL (authenticated Deep Sync)
Observability	Sentry, PostHog
Deploy	Vercel, Edge CDN, multi-layer SWR

What I Learned Building a Personal Product as SaaS

LeetRun started as a tool I needed during my own prep cycle. Productising it forced decisions client work sometimes lets you defer:

Pricing in INR for Indian students
Guest preview instead of hard paywalls
Founding-member caps instead of fake urgency
Caching architecture before traffic justifies it

The hardest engineering was not the UI. It was trust. Users hand over LeetCode session tokens and expect every sheet to stay in sync forever. Deep Sync, quest verification, and XP integrity had to be boringly correct. The fun parts (savage AI roasts, leaderboard climbs, room codes) only work if the data layer never lies.

Try it live: leetrun.vercel.app

Guest preview at /sheets, /patterns, and /analytics — no signup needed.

Tags: webdev javascript beginners career nextjs ai saas leetcode placement buildinpublic

How I Slashed a GCP Bill by 80%: The Hidden Trap of the Serverless CPU Toggle

vishu — Fri, 28 Aug 2026 12:59:34 +0000

How I Slashed My GCP Bill by 80%: The Hidden Trap of the Serverless CPU Toggle

Key Takeaways
• The --no-cpu-throttling (CPU always allocated) flag on Cloud Run opts you silently into 24/7 always-on billing, destroying the serverless cost model.
• Cloud Run bills for active CPU milliseconds. With throttling off, containers log 168 billable instance-hours per week even when idle.
• Google Cloud Tasks is purpose-built for this problem: explicit HTTP-targeted worker invocations with retries, rate-limiting, and backoff.
• The architectural fix: Return 200 OK fast, enqueue a Cloud Tasks job, let the CPU scale to zero, and fire the worker separately.
• Re-enabling CPU throttling plus Cloud Tasks cut billable instance-hours by ~80% while improving reliability.

Last month I dropped my cloud computing bill by 80%. I didn't rewrite anything in Rust or migrate away from serverless. The savings came from realizing that a "genius" 30-second configuration fix I had applied weeks earlier was a silent budget assassin running 24 hours a day.

If you are running Next.js, Node, or Go on Google Cloud Run and rely on background tasks, you are likely at risk of the exact same trap.

The Problem: Scale-to-Zero Kills Background Jobs

Serverless platforms like Cloud Run are cost-effective because they scale to zero. You pay only for the milliseconds a container is actively processing a request. The moment your handler fires a response, Cloud Run throttles the container CPU to near zero.

This creates a hard problem for async work. I was building a standard webhook flow:

Cloud Run API receives a webhook from a third-party service.
The system needs to parse the payload, sync a batch of heavy images to a GCS bucket, and update the database.
I need to return a 200 OK immediately so the third party does not time out.

The moment the 200 OK fires, GCP assumes the work is done. CPU is throttled to near zero. The Node.js event loop jobs — image sync, DB writes — stall, freeze, or fail silently. Network connections drop. The work vanishes.

The Expensive Workaround: --no-cpu-throttling

I hit the docs and found what looked like a magic wand: CPU always allocated (--no-cpu-throttling). I flipped the flag in 30 seconds. The background job issue vanished. The webhooks succeeded, the images synced, and I posted on LinkedIn about how easy the fix was.

The hidden tradeoff nobody warns you about: By flipping --no-cpu-throttling, you quietly opt out of the entire serverless pricing model. You are now paying for 24/7 always-on compute at serverless prices.

When I opened the GCP billing dashboard the next month, my Cloud Run instances were logging 168 billable instance-hours per week. The CPU was kept 'allocated' around the clock waiting for background jobs, so I was billed for 24/7 compute. I was paying premium serverless prices to run what was effectively a traditional always-on VM.

Cost Impact: Throttling ON vs. OFF

• Billing Model: Pay per active request ms (ON) vs. Always-on, pay 24/7 (OFF)
• Idle Cost: Zero (ON) vs. Full instance-hour rate (OFF)
• Weekly Instance-Hours: ~2–4 hrs (ON) vs. 168 hrs (OFF)
• Background Reliability: Poor, jobs stall (ON) vs. Good (OFF)
• Relative Monthly Cost: Baseline (ON) vs. ~10–15x baseline (OFF)

The Real Fix: Event-Driven Decoupling

To get that 80% reduction I re-architected the flow. The goal: let Cloud Run safely scale to zero the moment a request ends, while guaranteeing that the heavy background jobs actually execute.

Step 1: Turn CPU throttling back on. Instant 24/7 billing leak plugged.

Step 2: Migrate async work to Google Cloud Tasks. Cloud Tasks is specifically built for explicit, point-to-point HTTP execution. You target a specific worker endpoint, guarantee delivery, and get fine-grained control over retries, rate-limiting, and execution timing. (This is why I chose it over Pub/Sub — Pub/Sub is great for fan-out messaging, but for webhook processing with one worker and controlled retries, Cloud Tasks is the right primitive).

The New, Cost-Optimized Architecture

• Ingestion (fast and cheap): The main Cloud Run API receives the webhook. CPU is throttling-enabled.
• The Handoff: Instead of executing the heavy image sync inline, the API parses the required IDs, builds a JSON payload, and enqueues a Cloud Tasks job targeting the dedicated worker endpoint.
• The Quick Exit: The API returns 200 OK instantly. The request ends. Cloud Run throttles CPU to zero. Billing stops.
• The Worker (on-demand compute): Cloud Tasks fires an HTTP request to the dedicated worker endpoint. Cloud Run spins up fresh compute for exactly this task. The worker completes the heavy sync and scales back down.

Results: Faster, Cheaper, and Resilient

• 80% cost reduction: Billable instance-hours plummeted. The platform idles for free between requests.
• Bulletproof reliability: Cloud Tasks has built-in retries with exponential backoff. If an image sync fails due to a network hiccup or a database lock, Cloud Tasks retries the worker automatically without touching the main API or losing data in a frozen event loop.
• Zero main-thread blocking: The webhook ingestion API now responds in milliseconds, completely decoupled from processing time.

The Lesson: Serverless infrastructure is cheap because it idles for free. The moment you force it to stay awake to paper over an architectural flaw, you are paying always-on rates for always-on compute — and getting none of the resilience benefits of a real worker queue.

If background jobs are stalling your APIs, don't flip the throttling flag. Build a worker, enqueue a task, and let the cloud scale to zero. The fix is never the flag. The fix is the architecture.

Frequently Asked Questions

What does the --no-cpu-throttling flag do on Google Cloud Run?
It keeps a Cloud Run container's CPU active even after an HTTP request has completed. By default, Cloud Run throttles CPU to near zero once a response is sent, which is what makes serverless cheap. Disabling throttling means you pay for 24/7 compute regardless of actual traffic — effectively turning Cloud Run into an always-on VM billed at serverless prices.

Why do background jobs stall on Cloud Run after returning a 200 OK?
Cloud Run treats the end of an HTTP request as the signal to throttle the container CPU. Any background work still running in the Node.js event loop (image uploads, database writes, webhook fan-outs) is starved of CPU immediately. Network connections drop, promises hang unresolved, and the work disappears silently.

What is the correct architecture for background jobs on Cloud Run?
Event-driven decoupling via Google Cloud Tasks. The primary handler receives the webhook, enqueues a Cloud Tasks job targeting a dedicated worker endpoint, and returns 200 OK. Cloud Run scales to zero. Cloud Tasks then asynchronously calls the worker endpoint, spinning up fresh compute specifically for that task. You pay only for the milliseconds each container actively executes.

Why use Cloud Tasks instead of Pub/Sub for background jobs?
Cloud Tasks is built for explicit, point-to-point HTTP execution. You target a specific endpoint, control the exact delivery time, set per-task retry limits, and get fine-grained rate-limiting. Pub/Sub is optimized for high-throughput fan-out messaging where multiple subscribers need the same event.

How much does the Cloud Run CPU throttling flag actually cost?
With --no-cpu-throttling enabled, a container running 24/7 logs approximately 168 billable instance-hours per week. Depending on memory allocation and region, a single always-on instance can cost 10-15x more than the same workload processed on-demand with CPU throttling enabled.

How I Use Docker, GCP, and Supabase to Scale Production Apps

vishu — Thu, 27 Aug 2026 06:21:17 +0000

Most portfolio sites list “Docker, GCP, Supabase” as chips. This article is how I actually scale client apps: what each layer is for, what I refuse to put on it, and how that showed up on SVSFood and Ezlearn. [ https://vishu.app/blog/docker-gcp-supabase-scale ]

The shape of the stack
I treat infrastructure as three contracts:

Docker is how software is packaged. If it is not in an image, it is not what production runs.
Google Cloud Platform is where images run and where files live. Cloud Run, Cloud SQL or a VPC path to Supabase, Cloud Storage, Secret Manager, Cloud Build.
Supabase is production PostgreSQL with auth, Row Level Security, and realtime when the product needs live order or presence updates - accessed from app code through Prisma.
Frontends are often Next.js on Vercel when they are content and dashboard surfaces (Jara, LeetRun). APIs, workers, and anything that must stay warm or talk to hardware stay in Docker on GCP. Mixing those two is intentional, not indecision.

Docker as the unit of deploy
I containerize Node and Fastify services with multi-stage builds: a build stage with devDependencies, a runtime stage with only what the process needs. The image listens on a port, exposes a /health route, and reads secrets from the environment. Cloud Run starts that process, routes HTTPS, and scales the container count with traffic.

Why not a bare VM
A Compute Engine VM is fine as a jump box or for a stateful exception. It is a poor default for app servers. Patch levels drift. Node versions drift. “I SSH’d and npm installed” is not a rollback plan. Docker plus Cloud Run gives me immutable deploys: revert means serving the previous digest. That matters when you are on-call for a restaurant kiosk at dinner rush.

What goes in the image
The compiled or bundled API (Fastify + TypeScript).
Prisma client generated against the production schema.
A non-root user and a pinned Node LTS base.
No .env files. Secrets arrive from Secret Manager at runtime.
Local docker compose runs the API next to a Postgres that matches production (or a Supabase local stack). CI builds the same Dockerfile. The promotion path is an image tag, not a new ritual.

GCP as the runtime
I chose Google Cloud Platform for Ezlearn over AWS and over “put the whole product on Vercel” for three reasons that still hold:

Pricing and latency in Asia for Compute Engine and Cloud SQL were better for a bootstrapped EdTech targeting Indian learners.
Docker is a first-class citizen. Cloud Run is a container product, not an afterthought.
Cloud Storage plus a CDN is the correct place for course video, certificates, and kiosk assets - not the Node process.
Cloud Run for APIs
SVSFood’s Fastify API - kiosk, admin, website, rider - is the kind of service Cloud Run is for: bursty lunch and dinner traffic, idle overnight, needs HTTPS and a custom domain, must not require me to size a VM. Concurrency is tuned so one instance can hold multiple in-flight orders without melting. CPU is allocated only during request processing unless a WebSocket path needs a minimum instance.

Storage, SQL, and secrets
Ezlearn course video never streamed from the application server. Objects live in a bucket; the app mints URLs. Certificates are rendered server-side as PDFs and stored the same way. Secrets (payment keys, session material, third-party tokens) sit in Secret Manager and are mounted as env on the Cloud Run service. I do not keep production secrets in GitHub or in a Vercel dashboard for the API layer.

Supabase as the data plane
Supabase is PostgreSQL I do not have to baby-sit, plus auth and realtime when I want them. On SVSFood, Prisma talks to Postgres hosted on Supabase. Orders, inventory, menus, coupons, riders, and audit logs are relational on purpose. I will not put that in a document store and then re-implement joins in application code.

Auth and Row Level Security
For products where the client app can talk to the database under a user JWT, Supabase Auth plus RLS is a force multiplier. Admin consoles and payment webhooks still go through Fastify - those paths need server secrets and idempotency. The split is: Supabase for identity and row-level rules; custom API for money and vendors.

Realtime without a second architecture
Kiosk and rider status can move over Supabase realtime or over WebSockets on Fastify. I pick based on who owns the write path. If the write already goes through Fastify (inventory reservation, payment capture), I broadcast from there. If the write is a simple presence or chat-like update, Supabase realtime is enough. I do not run Redis “because scale” on a product that does a few thousand orders.

Case: SVSFood - four clients, one pipeline
SVSFood needed a kiosk, an admin console, an online ordering site, and a rider app. The constraint: one menu, one inventory, one order state. Docker packaged the Fastify API. GCP hosted it. Supabase PostgreSQL was the source of truth. Next.js handled console and website. React Native handled kiosk and rider. PhonePe and Petpooja stayed behind the API so a tablet never held a settlement key.

Scale here is not millions of QPS. Scale is correctness at dinner rush across three outlets, offline kiosks that sync, and an operator who can change a price once. The stack is sized for that. ₹40L+ in month one on owned devices is the outcome that matters.

Case: Ezlearn - EdTech on GCP for 1,000+ MAU
As CTO I owned architecture and shipping for Ezlearn: subscriptions, Hindi-first course delivery, AI learning roadmaps, certificates, a job portal. The platform ran on Next.js, Node, PostgreSQL, and GCP with 99.9% uptime and 1,000+ monthly active users. Video on CDN-backed storage kept the Node process small. Certificates were a server-side PDF pipeline into Cloud Storage. GCP’s Asia pricing made that viable for a bootstrapped company in Noida.

What I do not do
I do not run Kubernetes for a single API. Cloud Run is enough until it is not; I have not hit that wall on these products.
I do not put the database in a container on the same Cloud Run service as the API.
I do not use Supabase as a replacement for payment orchestration or complex vendor adapters.
I do not multi-cloud a client MVP. One cloud, one database, one container registry.

The architecture, simply
Vishu Pratap scales production apps by packaging APIs in Docker, running them on Google Cloud Run, storing relational data and auth in Supabase PostgreSQL (or Cloud SQL), and putting media on Cloud Storage. The pattern is proven on SVSFood’s food-tech stack and Ezlearn’s EdTech platform. Deeper notes: Docker in production, GCP architecture, Supabase and PostgreSQL.

Frequently asked questions
How does Vishu Pratap use Docker, GCP, and Supabase together?
Application servers (Fastify, Node) are packaged as Docker images and deployed to Google Cloud Run. Relational data, auth, and realtime live on Supabase PostgreSQL (or Cloud SQL when a project outgrows it). Object files go to Cloud Storage behind a CDN. The same Docker image is what ran in development.

Why Docker instead of deploying Node directly on a VM?
A VM drift problem - “it works on the server” - is expensive when you are the only operator. Docker pins the runtime, system libraries, and start command. Health checks, rolling deploys, and Cloud Run all assume a container contract.

Why Google Cloud Platform instead of AWS or only Vercel?
For Ezlearn, GCP won on Compute Engine and Cloud SQL pricing in Asia and on native Docker support. Vercel is excellent for Next.js frontends (Jara, LeetRun) but is the wrong home for long-running APIs, kiosk backends, and video-adjacent workloads. AWS would have worked; it was more expensive for the same region and shape.

For more - https://vishu.app/blog
medium article - https://medium.com/@vishurizz0/how-i-use-docker-gcp-and-supabase-to-scale-production-apps-d41f611b5078?postPublishedType=initial