DEV Community: Pritam Patra

Your Policies Are Out of Date: How I Built a Sanity AI Agent to Catch Fact Drift

Pritam Patra — Sat, 03 Oct 2026 21:21:17 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

Fact Ledger — an AI-assisted fact drift detection and remediation engine built on Sanity Content Lake.

Here's the problem it solves, told as a scene:

A product manager at a SaaS company decides to extend refunds from 30 days to 60 days. She opens the CMS, finds the Refund Policy page, updates it, clicks publish. Done. She sends the Slack message: "Refund window is now 60 days, effective immediately."

What she doesn't know: the Help Center article still says 30. The Pricing FAQ still says 30. The Onboarding Guide, the Terms of Service, the Enterprise SLA page, the Checkout confirmation modal copy — all still say 30. Six weeks later, a customer disputes a charge, screenshots the Pricing FAQ, and sends it to their lawyer.

That is Fact Drift — and it happens quietly, constantly, in every company with more than a handful of content pages and more than one person editing them. It's not a CMS problem, it's a structural problem. The number "30" is stored in twenty-three places as dead characters. There's no relationship between them. When one changes, the others don't know.

Fact Ledger fixes this at the data model level.

Business values — refund windows, SLA commitments, file size limits, pricing tiers, data retention periods — become first-class Sanity documents called facts. Pages don't copy those values; they reference them via a custom factRef inline Portable Text annotation. When the fact document changes, every page that uses a factRef renders the new value instantly, automatically, with zero editor intervention.

For every page that still has the hardcoded plain text — either because it predates the system or because someone didn't know — a deterministic scanner runs on every webhook event, finds the stale copies, and raises structured finding documents. An AI agent drafts the exact Sanity patch mutations to fix them. A human reviews the before/after diffs and clicks one button. Everything updates atomically in a single transaction. The audit ledger captures the whole chain.

The core principle, distilled to four words per step: Rules flag. AI drafts. Human approves. Sanity remembers.

Fact Edit → Webhook → Deterministic Scanner → Finding Graph
         → AI Mutation Synthesis → Draft Release → Human Approval → Zero Drift

The 5 Scanner Rules (Zero AI Involved)

This is where the design gets interesting. The scanner is pure deterministic TypeScript — no model calls, no embeddings, no fuzzy matching libraries. It runs in milliseconds and produces findings with exact block keys and character offsets.

Rule	What it catches	Why it matters
R1 — Unlinked Match	Plain text `"30 days"` where a `factRef` should be	The most common drift; editors hardcode values without realising
R2 — Contradiction	Text says `"60 days"` while the canonical fact says `30`	Catches the pages that were partially updated manually
R3 — Deprecated Reference	A `factRef` pointing to a fact marked `deprecated`	Catches linked pages when a fact is retired, not just changed
R4 — Orphan Fact	An active fact exists in Sanity but zero pages reference it	Surfaces forgotten policies that have drifted into irrelevance
R5 — Temporal Violation	A `factRef` pointing to a fact outside its `effectiveFrom/Until` range	Catches seasonal pricing or time-bound policies used out of window

Run the benchmark against the seeded dataset of 31 planted violations: 100% precision, 100% recall. Every planted issue found, zero false positives. That's not a marketing number — the seed/groundTruth.ts file has the exact expected findings per page, and the benchmark runner verifies against them on every run.

The precision comes from a design decision in R2: the proximity window. Instead of flagging any number that contradicts the fact value anywhere on the page (which would catch phone numbers, copyright years, and table row counts), R2 only flags numbers that appear within N characters of the fact's label in the text. That single detail is the difference between a rule that's useful and one that's noise.

The Workflow

Once findings exist in Sanity, the AI remediation agent kicks in. It fetches the page's Portable Text, locates the exact block and character span identified by the scanner, slices out the stale text, and generates a valid Sanity patch mutation — the kind you'd write by hand if you were doing this manually, except it does it for twenty pages in the time it takes to refresh the dashboard.

All of this goes into a remediation document: a structured release with a fixes array where each item carries beforeText, afterText, the raw patch JSON, and an approved boolean the editor can toggle.

In Sanity Studio, there's a custom "Apply Fixes & Publish" document action on the remediation type. The editor reads through the diffs. They can approve or reject individual fixes. When they're satisfied, one click fires a client.transaction() that atomically:

patches every affected page
flips every linked finding to fixed
publishes the remediation document itself
writes an immutable changeEvent to the audit ledger

No partial states. No "we fixed 17 of 21 pages and then the tab closed." All twenty-one pages update in the same transaction or none of them do. The Drift Score on the dashboard drops back to zero and stays there — until the next fact changes.

🌟 Key Features (The App SDK Experience)

The Next.js dashboard at https://fact-ledger.onrender.com/dashboard is a live, interactive layer on top of Content Lake. It isn't just a read-only frontend — it's a full App SDK Control Center.

1. The Clause Impact Tree
When a policy changes, officials don't just see a list of broken pages. They see a cascading change graph. The Clause Impact Tree visualizes exactly how a single canonical fact ripples outward across the entire corporate document graph, showing nodes turning red in real-time as the webhook fires.

2. The Live Control Center & Charts
Every number and graph on the dashboard comes from a live GROQ query.

The KPI Row: Tracks current Drift Score, total facts, scanned pages, and overall health.
Resolution Health Chart: A before-vs-after breakdown showing open findings vs fixed findings across releases.
The Heatmap: A CSS grid visualizing Fact × Page drift anomalies. Red for drift, green for clean.
Interactive Triage: Editors can approve or dismiss findings directly from the dashboard table. The API route patches the finding document in Sanity immediately, and the table re-queries live without reloading.

3. The Employee Voice Portal
Policy confusion doesn't only flow downward. Employees and customers notice stale policies first. The Employee Voice portal gives that signal a home.

Employees can submit policy complaints or questions.
These submissions are stored as complaint or policyQuestion documents directly in Sanity.
Officials see every submission in Sanity Studio right next to the open findings. When an employee asks, "Why does the checkout page say 30 days but I was told 60?", the complaint lives right next to the scanner finding that explains exactly why.

Demo

Live Dashboard: https://fact-ledger.onrender.com/dashboard
Sanity Studio: https://pritam.sanity.studio/

The Full Loop in 60 Seconds

Here is how the system actually looks in practice when a fact changes:

1. The Trigger
An editor changes the Cancellation Policy fact value from 60 to 30 in Sanity Studio.

2. The Detection
The webhook fires. The scanner runs R1–R5 across all pages. The dashboard Drift Score jumps and the KPI pulses red.

3. The Remediation Draft
Clicking "Draft AI Remediation" triggers the AI to draft exact before/after patches for all stale spans.

4. The Human Approval
The editor opens the Remediation Release in Studio, reads through the diffs, and clicks "Apply Fixes & Publish".

5. The Resolution
client.transaction() commits. All pages are patched atomically, findings flip to fixed, and the Drift Score returns to 0.

Code

Pritam-mb / sanity

An AI-assisted fact drift detection engine built on Sanity Content Lake.

Live Demo • Sanity Studio • Installation

🛑 The Problem: Fact Drift

A product manager at a SaaS company decides to extend refunds from 30 days to 60 days. She opens the CMS, updates the Refund Policy page, and clicks publish. What she doesn't know: the Help Center article still says 30. The Pricing FAQ still says 30. The Onboarding Guide, the Terms of Service, the Enterprise SLA page, the Checkout confirmation modal copy — all still say 30.

That is Fact Drift. The number "30" is stored in twenty-three places as dead characters. There's no relationship between them. When one changes, the others don't know.

💡 The Solution: Fact Ledger

Fact Ledger fixes this at the data model level. Business values become first-class Sanity documents (facts). Pages don't copy those values; they reference them.

For every…

View on GitHub

fact-ledger/
├── studio/     # Sanity Studio v3 — 13 schema types, custom structure, Document Action
├── web/        # Next.js 16 App Router — Drift Dashboard + API routes
├── scanner/    # Pure TypeScript R1–R5 + Vitest unit tests
├── seed/       # Idempotent seed script (facts, pages, ground truth)
└── bench/      # Benchmark runner — writes benchmarkResult docs to Sanity

Sanity Project ID: tmics7hc (dataset: fact-ledger)

My Build Process

I used Antigravity IDE (Google DeepMind) as my primary AI-native IDE, with its browser agent running alongside for live validation and UI feedback during development.

How it started

I came into this with a real problem in mind — not a contrived demo. The scenario of "fact changes in one place, stays stale everywhere else" has bitten real teams I've worked with. I wanted to see if a vibe-coded system could actually address it with structural rigor, not just vibes.

My opening prompt was deliberately ambitious:

"Build a closed-loop fact drift detection system on Sanity. Facts are first-class documents. Pages reference them with custom Portable Text inline objects. A deterministic scanner runs on webhook triggers and creates finding documents. An AI agent synthesizes patch mutations. A human approves via a custom Studio document action. Everything is audited. The LLM never publishes anything."

That single prompt produced the full schema architecture, the factRef Portable Text annotation type, and an initial scanner skeleton in one pass. What struck me: the model correctly inferred the key constraint on its own — no unsupervised publishing — and every design decision that followed was shaped by that constraint without me having to repeat it. It understood why the LLM's role should be limited to drafting, not deciding.

Prompts that worked

Schema design:

"Design a fact schema for Sanity with: key (slug), label, value, unit, aliases (array of strings for surface-form matching), owner (reference to person), dependsOn (self-referential array), effectiveFrom/Until (dates), status (active/deprecated), and a highStakes flag."

The aliases field is what makes the whole system actually useful in practice. Without it, the scanner could only catch exact matches like "30 days". With it, each fact document carries its own list of surface forms: ["30 days", "thirty (30) days", "one month", "30 calendar days"]. R1 matches any of them. That's how you catch the policy writer who wrote "one month" in the terms and the marketing person who wrote "thirty days" in the campaign landing page — same fact, same finding, zero NLP required.

The highStakes flag is a quiet but important detail: facts marked high-stakes require two human approvers in the remediation workflow. One person can't unilaterally ship a fix to the refund policy affecting twenty pages.

Scanner architecture:

"Write the 5 scanner rules as pure TypeScript functions. Zero dependencies. Zero AI. Take facts and Portable Text blocks as input, return findings with exact block key, child key, start offset, and end offset."

The model got genuinely clever here. For R2 (contradiction detection), it implemented a proximity window — a contradictory number only fires as a finding if it appears within N characters of the fact's label in the text body. That design decision alone is what separates a useful rule from a useless one. A naive implementation would flag every number on every page. This one only flags the ones that are contextually near the fact's label, which is where contradictions actually matter.

Running npm run bench against the 31 planted issues: 31 found, 0 false positives. That's a real validation, not a demo.

The custom document action:

"Write a Sanity Studio document action for the remediation type. Label: 'Apply Fixes & Publish'. Filter for approved=true fixes, parse each mutation JSON, build a client.transaction() that patches every page, flips findings to fixed, publishes the remediation doc, writes a changeEvent. Atomic commit."

This came out nearly correct on the first pass. The model chose client.transaction() without prompting — it understood on its own that sequential patches would create a window where some pages are fixed and others aren't. That matters: if the tab closes halfway through twenty patches, you're left with a half-consistent dataset and no way to know which pages were updated. A transaction is all-or-nothing. The model knew that.

Prompts that didn't work

Sanity Functions as the webhook handler. The model scaffolded a genuinely clean Sanity Function — right structure, right exports, correct handler signature. Then I went to deploy it and hit the plan wall: Sanity Functions require a paid upgrade. Beautiful code, zero utility at my tier. The fallback was a Next.js API route, which actually turned out cleaner: scanner and webhook in the same process, easier to debug, no cold start latency.

The lesson: beautiful code requiring a plan upgrade isn't code you can ship. We fell back, and the fallback shipped.

Auto-generating seed data. My first two attempts at generating realistic policy pages with planted drift violations produced pages where every violation was placed inside a heading element. Headings in Portable Text don't have child span arrays the way body blocks do — so the scanner couldn't see them. Completely valid Sanity documents, completely invisible to R1–R4.

The fix was to be brutally explicit:

"All planted violations must be inside Portable Text body blocks with at least 2 child spans. Include exact byte offsets in the ground truth file so the benchmark can verify TP/FP/FN."

After that, seed/groundTruth.ts became the source of truth for the benchmark. Every time you run npm run bench, it checks the scanner's output against those exact expected findings. If someone breaks a rule, the benchmark fails — not gracefully, loudly.

The heatmap. Describing the Fact × Page heatmap in prose got me a Recharts cell chart with tiles so small you needed a magnifying glass. The breakthrough was switching from describing what it should look like to describing how it should be built:

"Implement this as a CSS grid. Rows = facts, columns = pages. Each cell: red background if open findings exist for that combo, green if clean. No charting library — plain CSS grid. Title attributes for hover tooltips."

One pass, done. The lesson: when the output is wrong, don't describe the outcome differently — describe the implementation.

Reaching past the Studio

Workflows as data. The remediation schema is the workflow document. Status transitions: draft → pending_review → approved → published. Each transition is a Sanity patch. Every state is queryable in GROQ. The AI agent advances the document to pending_review. A human editor reviews and advances to published via the custom document action. If they're not ready, the document sits at pending_review indefinitely — visible in the Studio sidebar under "Remediation Releases" with a running count of unapproved fixes. Nothing gets lost. Nothing gets auto-published.

A real-time custom interface. The dashboard is not read-only. Editors can approve or dismiss individual findings directly from the /findings table — the action patches Sanity and the table refreshes with the new state. The Drift Score pulses visually when non-zero. It's a small UX decision, but it matters: you want people to feel the urgency of a non-zero drift score, not just read a number.

The Employee Voice portal. A late addition in Session 3, prompted into existence in a single session. Policy confusion doesn't only flow downward — employees and customers notice it first and report it through informal channels (Slack, email, support tickets) that never get structured or tracked. The portal gives that signal a home in the same Content Lake. A complaint about a confusing refund promise routes directly into a complaint document in Sanity; the editor sees it in Studio next to the open findings for that fact. The problem and its reports live in the same place.

Three schema types, three Studio sidebar sections, five Next.js routes — roughly 45 minutes from prompt to running.

What surprised me

The model never once suggested putting the LLM in the approval loop. Even when I described the remediation flow in ways that left room for autonomous action, it consistently added a canPublish guard, an approved boolean per fix, and explicit before/after text fields for human review. The safety architecture emerged from the model's understanding of the design, not from me specifying every guardrail.

The GROQ queries were also clean on first generation — almost no iteration needed. GROQ's declarative shape maps well onto how the model reasons about data: you describe the shape you want, not the traversal you'd write in SQL. When the output is wrong in SQL, you debug joins. When GROQ output is wrong, you usually just re-describe the shape. The model seems to prefer describing shapes.

The most important moment: the model wrote an elegant Sanity Function. I had to explain that elegance and deployability aren't the same thing. The fallback shipped. The elegant version sits in a comment block as a note for when the plan gets upgraded.

That's the honest build: seven and a half hours, a real problem, a model that got most of it right, a few walls we had to route around, and a system that actually works.

Sanity Project Details

Project ID: tmics7hc
Dataset: fact-ledger
Schema types: fact, factRef (custom Portable Text annotation), page, finding, scanRun, remediation, changeEvent, benchmarkResult, complaint, policyQuestion, policyUpdate, person
Custom Studio features: custom desk structure (Facts / Pages / Open Findings / Remediation Releases / Employee Voice / Audit Log), custom document action "Apply Fixes & Publish" (PublishRemediationAction.ts), visionTool for GROQ exploration
Webhooks: fact and page publish events trigger /api/webhook → scanner → finding creation
Transactions: remediation publishing uses client.transaction() for atomic multi-document patches
TypeGen: sanity typegen generate in studio/ — all GROQ queries are fully typed

Agent Session

Built with Antigravity IDE (Google DeepMind) over three sessions, roughly 7.5 hours total.

Session 1 (~2.5 hrs): schema design, factRef annotation, scanner R1–R5, seed script
Session 2 (~3 hrs): dashboard panels P1–P6, API routes, webhook handler, benchmark runner
Session 3 (~2 hrs): Studio structure, "Apply Fixes & Publish" action, Employee Voice portal, audit ledger, polish

The model wrote the large majority of the TypeScript. My role was architect, reviewer, and the person who hit pricing walls so you don't have to.

Pritam-mb / sanity

An AI-assisted fact drift detection engine built on Sanity Content Lake.

Live Demo • Sanity Studio • Installation

🛑 The Problem: Fact Drift

That is Fact Drift. The number "30" is stored in twenty-three places as dead characters. There's no relationship between them. When one changes, the others don't know.

💡 The Solution: Fact Ledger

Fact Ledger fixes this at the data model level. Business values become first-class Sanity documents (facts). Pages don't copy those values; they reference them.

For every…

View on GitHub

👥 The Team

Our team came together for the International Charity Day DEV Challenge to build NeedFeed:

@pritam_patra_429a25dedae6 (Lead Developer)
@t-rexbytes (Collaborator)

OmniML: We Built an AutoML System That Refuses to Be a Black Box

Pritam Patra — Tue, 22 Sep 2026 09:17:49 +0000

This is a submission for the MLH x DEV Writing Challenge

OmniML: An AutoML Pipeline That Actually Asks Before It Decides

What I Built

Most AutoML tools operate as complete black boxes. You feed in a dataset, a brute-force search algorithm churns away behind closed doors, and out comes a model with zero explanation, no room for expert intervention, and no consideration for regulatory standards like the EU AI Act or FDA Software-as-a-Medical-Device (SaMD) guidelines. That opacity is exactly what my team set out to fix.

At HackTropica, we built OmniML — an open-source, full-stack, autonomous machine learning system that keeps a human explicitly in the loop at every critical decision point. Orchestrated with LangGraph, powered by Groq's openai/gpt-oss-120b for fast reasoning, and wrapped in an interactive Chainlit UI, OmniML turns a plain-English request into a fully trained, compliance-checked, and deployment-ready ML model, sourcing real datasets from Kaggle along the way.

The pipeline runs through a chain of dedicated stages, and at five separate checkpoints it pauses and hands control back to the user before proceeding. The architect agent first proposes a baseline model graph from the problem statement, which the user can then visually edit through an embedded React Flow canvas before anything is compiled. From there, the system searches, ranks, and downloads a real tabular dataset via the Kaggle API, profiles it for feature distributions and data quality, and surfaces that analysis for review. The user then configures hyperparameters, fairness settings, and compliance mode, and makes an explicit choice between local and cloud compute before training is ever allowed to start. Once training resumes, an engineer and debugger agent pair generates deterministic training code, validates it, and executes it in a sandboxed environment while streaming real-time logs and metrics back to the UI. The final stage produces SHAP and LIME explainability outputs, fairness benchmarks, and a full compliance report formatted against EU AI Act and FDA SaMD guidance, alongside a production-ready deployment bundle.

One design decision I'm particularly proud of is supporting two distinct training paths depending on the problem. Path B, which is the default, uses scikit-learn for fast tabular, text, or image training via grid search over a featurized CSV. Path A compiles the user-approved React Flow graph directly into a custom OmniMLNet PyTorch module and trains it with real epoch-level metrics, which is useful when someone actually wants to reason about network architecture rather than just get a fast baseline. OmniML also grounds its architecture decisions in real research: before training begins, an agent pulls relevant literature and produces a gap-analysis comparing the current dataset, task, and proposed architecture against published methodologies, so the user can see exactly where their setup diverges from established approaches in the field. Every run is also fully reproducible: each execution persists to runs/<run_id>/manifest.json as a complete evidence bundle covering artifacts, plots, logs, and reports, all downloadable and normalized for later benchmarking.

Here's the high-level flow end to end:

User Query
  └─► Architecture generation
        └─► HITL architecture editor (React Flow)
              └─► Dataset sourcing and ranking (Kaggle)
                    └─► HITL dataset selection
                          └─► Dataset download + validation
                                └─► Drift sentry
                                      └─► EDA profiling
                                            └─► HITL training configuration
                                                  └─► HITL compute strategy
                                                        └─► Hyperparameter tuning + deterministic code generation
                                                              └─► Code validation & self-healing
                                                                    └─► Execution sandbox
                                                                          └─► XAI / benchmark / fairness / compliance
                                                                                └─► Deployment dashboard + downloadable reports

What I learned building this had less to do with the ML itself and more to do with orchestration. Getting an LLM-driven agent graph to pause reliably at a UI checkpoint, hold state correctly, and resume exactly where it left off — without losing context or re-triggering earlier stages — turned out to be the hardest engineering problem in the whole project, harder than anything on the modeling side.

Demo

Here's the full walkthrough of OmniML running end to end, including the interactive HITL graph editor, live dataset profiling, and compliance report generation:

🎬 Video Demo

🔗 GitHub Repository: https://github.com/Pritam-mb/hacktropica

Visual Architecture Editor (HITL Checkpoint)

The embedded React Flow visual editor inside Chainlit lets you visually refine a proposed neural network topology before it's compiled into a trainable model:

Pipeline Walkthrough in Screenshots

1. EDA Profiling Dashboard. After a dataset is sourced from Kaggle, OmniML runs it through an automated profiling stage that surfaces missing values, feature distributions with skewness stats, and categorical feature breakdowns — all before the user is asked to approve moving forward:

2. Outlier Detection, Correlation Analysis & AI Data Insights. The same EDA stage flags outliers using IQR fencing, ranks the strongest feature-to-feature correlations, renders a full correlation heatmap, and closes with a natural-language summary generated by Groq — explaining data quality issues and how the dataset maps to its likely source (in this run, correctly identifying it as the Wisconsin Breast Cancer Diagnostic dataset):

3. Training Configuration (HITL Checkpoint). Before any training runs, the user is handed an interactive configuration panel to set epochs, test split, batch size, learning rate, optimizer, and regularization settings — with quick presets for fast debug runs versus deep, balanced, or overfit-test configurations:

4. Live Training Progress. Once training is launched, OmniML streams real epoch metrics back into the chat as live loss and accuracy curves, alongside a running Groq-generated observation of what's happening in the training dynamics — in this case flagging a plateau in validation loss and suggesting the learning rate may be too high for further fine-tuning:

5. Literature Comparison & Gap Analysis. Before the pipeline finalizes an architecture, an agent cross-references the task and dataset against relevant published research, summarizing methodologies from comparable papers and calling out where the current setup diverges from established approaches in the literature:

Try It Yourself

git clone https://github.com/Pritam-mb/hacktropica.git
cd hacktropica

python -m venv venv
source venv/bin/activate   # Windows: venv\Scripts\activate

pip install -r requirements.txt
cp .env.example .env       # then fill in GROQ_API_KEY, KAGGLE_USERNAME, KAGGLE_KEY, CHAINLIT_AUTH_SECRET

python start.py

Then open http://localhost:8001 and try a prompt like "Diagnose breast cancer from biopsy records" or "Detect credit card fraud from transaction telemetry." Runtime diagnostics — Groq auth status, Kaggle CLI resolution, credential checks — are available at http://localhost:8001/runtime-diagnostics if anything needs debugging.

Partner Technologies

Groq (openai/gpt-oss-120b) is the reasoning engine behind almost every intelligent decision in OmniML: generating the initial model architecture from a natural-language prompt, ranking candidate Kaggle datasets, writing deterministic training code, self-healing that code when validation fails, and generating live natural-language commentary during training (as shown in the screenshots above). What made Groq stand out for this specific project was inference latency. Because OmniML's architecture involves an LLM call at nearly every stage transition in a multi-agent LangGraph state machine, using a slower inference provider would have made the human-in-the-loop experience feel sluggish and would have broken the sense that you're interacting with a live system rather than waiting on a batch job. Groq's speed meant the architect agent could regenerate a model graph, or the debugger agent could rewrite a failing script, fast enough that the checkpoint-and-resume UX in Chainlit felt responsive rather than like a loading screen. Swapping in the openai/gpt-oss-120b model specifically gave us a good balance between reasoning quality for code generation tasks and the raw throughput Groq's hardware provides.

Chainlit is the backbone of the entire user-facing experience. Rather than building a custom frontend from scratch, we used Chainlit's message and element system to embed custom React components — the React Flow architecture editor, the EDA profiling dashboard, the training console, and the deployment dashboard — directly inside a chat interface. The interesting implementation challenge was making Chainlit's async message flow pause execution and wait on user interaction from an embedded custom element, rather than just displaying static content. We used Chainlit's action and custom-element callback system to bridge state from the frontend graph editor back into the LangGraph execution state, so a user's edits to the visual canvas actually mutate the architecture object that gets compiled downstream. Working with Chainlit's extensibility for custom JS/React elements alongside a Python-native backend was one of the more rewarding parts of the stack.

Kaggle API powers structured dataset discovery, evaluation, and automated ingest — letting the agent search, rank, and validate real-world tabular datasets against the user's problem statement without any manual dataset hunting.

PyTorch, Optuna & Scikit-Learn drive graph compilation, hyperparameter search, and model execution across both the sklearn (Path B) and PyTorch (Path A) training routes.

Hackathon Experience

We attended HackTropica on 5th April 2026 at Asansol Engineering College. The energy in the hall was electric from the moment we walked in—hundreds of developers, whiteboards filled with architecture diagrams, and a clear challenge in the air to build something truly transformative.

Building AxisVision OmniML under a tight deadline was both thrilling and intense. A pivotal part of our journey was the guidance we received from Prof. Tridib Chakraborty. His mentorship helped us sharpen our system design, pushing us to ensure our Human-in-the-Loop (HITL) workflow was seamless, robust, and genuinely useful for real-world application.

The most memorable moment was our final pipeline test. We had spent hours resolving a late-stage bug where the LLM-generated graph layout refused to bind cleanly with the Kaggle dataset streaming pipeline. After painstaking step-by-step debugging, we hit "Run"—and watched in real time as the prompt generated a complete 7-layer neural network, downloaded live data, rendered EDA metrics, and executed training end-to-end without breaking.

What I'll remember most about this event is the sheer thrill of turning a complex, multi-module AI system into a working reality in a room full of passionate builders. HackTropica was a powerful reminder of what good teamwork and dedicated mentorship can achieve under pressure.

If you find OmniML valuable, consider giving it a ⭐ on GitHub — and if you build something with it or have feedback, I'd love to hear about it.

NeedFeed 🤝 — Safe, In-Kind Mutual Aid Without Cash or Tagging

Pritam Patra — Mon, 07 Sep 2026 04:14:30 +0000

This is a submission for the Weekend Challenge: Generosity Edition.
Prize categories: Best Use of Snowflake · Best Use of Google AI

The problem I couldn't unsee

Most charity tech solves the wrong problem.

It makes it easier to move money — when the actual friction is moving things. It makes it easier to identify people in need — when the actual requirement is protecting them. It makes it easier to claim generosity — when the actual value is proving it.

Three failure modes, and they all start before a single dollar changes hands:

Cash is a liability, not a feature. When the need is "10 kg of rice" but the mechanism is "send ₹500," you've introduced an unnecessary conversion step — and with it every failure mode: fee skimming, diversion, a middleman buying the wrong thing entirely.

Tagging is surveillance in a helpful mask. "Tag someone who needs this!" sounds generous. It publicly identifies a vulnerable person to a stranger, with no consent, no accountability, and no recourse.

Self-reported badges are meaningless. Most platforms award "generous donor" status when someone says they gave. No one checks. The badge becomes a participation trophy, not a trust signal.

NeedFeed exists because charity does not have to mean money — and almost everyone has something they can give.

What I Built

NeedFeed is a hyperlocal, in-kind mutual aid platform. Neighbors coordinate real, physical help — food, clothing, medical supplies, school materials, volunteer time — without ever touching cash, without publicly tagging vulnerable people, and without asking anyone to just trust the process.

The unit of generosity is a physical item: a warm sweater, a walking cane, a bag of rice.
The unit of trust is a verified handoff — not a payment receipt, not a checkbox.

Four hard rules — in the data model, not the guidelines

1. Strictly in-kind, zero cash, ever.
Food, clothing, medicine, mobility aids, school supplies, shelter materials, hygiene kits, and volunteer time only. There is no "donate cash" button, and there never will be.

2. Open pledge pool, no direct tagging.
A posted need enters a public pledge pool. Any neighbor can pledge to fulfill it, but no one gets a private link, a DM, or a direct connection to the beneficiary.

3. Steward representation, with recorded consent.
People who can't represent themselves online — no phone, no literacy, no connectivity — are represented by a verified local steward who opens a persistent Case Page on their behalf, only after a recorded verbal consent clip, not a checkbox.

4. Two-party verification cycle.
A giver pledges, marks the item "Handed Off." Only after the steward independently confirms receipt with the beneficiary does the giver earn their Honor Badge. A mismatch is flagged and auditable.

The badge means something because it costs something to earn.

Demo

Run locally — zero API keys required:

git clone https://github.com/Pritam-mb/charity.git
cd charity
npm install
npm run dev
# → http://localhost:3000

The local auto-tagger and local metric engine stand in for Gemini and Snowflake respectively. To connect the real services, add keys to .env.local:

# Snowflake Data Cloud
SNOWFLAKE_ACCOUNT=<account>.<region>
SNOWFLAKE_USERNAME=<username>
SNOWFLAKE_PASSWORD=<password>
SNOWFLAKE_DATABASE=CHARITY
SNOWFLAKE_SCHEMA=PUBLIC
SNOWFLAKE_WAREHOUSE=COMPUTE_WH

# Google Gemini AI
GOOGLE_AI_API_KEY=AIzaSy...
GOOGLE_AI_MODEL=gemini-1.5-flash

Delete data/store.json and restart the dev server to reseed with fresh, realistic demo data.

GitHub → Pritam-mb/charity

The walkthrough

The feed

The home feed is designed for Gen Z: visual, fast, and community-driven. It's a dark-mode, Reddit-style three-column layout — a collapsible left sidebar for navigation, a center feed with segmented sorting (New / Hot / Top Urgent) and category/neighborhood filters, and a right rail with a Local Area Explorer and community rules.

You can browse new, hot, or urgent needs, filter by category and neighborhood, and see exactly what is needed — with a real image, urgency flair, and steward-beneficiary attribution ("Posted by Rashid on behalf of Arjun"). Every need card has a four-action bar: Support, Comments, Share, and Pledge Help.

Opening a need

Open a need and you get the full context — item, urgency, quantity, neighborhood, and the Case Page it belongs to. A verified local handoff point appears on the Leaflet map, so help stays simple and local. No stranger-to-stranger coordinates. No private DMs.

Making a pledge

Choose Pledge Help, select what you can provide, and complete the handoff. But a pledge is not impact.

You mark it Handed Off. Then the verified steward confirms delivery with the beneficiary. Only when both sides confirm does the system record a verified contribution and award the Honor Badge. That two-step is not a formality — it's the whole point.

Posting a need

Posting only requires a plain-language caption and an optional photo or video. Gemini AI analyzes the description and proposes category, item type, quantity, and urgency — all fully editable before publishing. AI proposes; a human confirms. Nothing auto-publishes.

When Gemini isn't configured, a local keyword-and-regex inference engine (lib/auto-tag.ts) handles the same job. The workflow never breaks because of a missing API key.

Case Pages

Case Pages (/cases/[id]) are dedicated, persistent profiles for recurring or high-vulnerability beneficiaries. Instead of isolated posts, a Case Page becomes a living record of the community helping one person over time.

Each page has:

A letter avatar and alias name (never a legal name)
A verified-consent badge
An append-only steward update timeline with photo evidence
All associated needs with their fulfillment status
A defined handoff location — a known local anchor point, not a stranger's address

The community extends beyond individual needs too — people can offer items, volunteer their time, connect with organisations, and follow cases they care about.

Account settings define a person's platform role (volunteer, steward, NGO leader), primary neighborhood for anchor-point matching, and contact info — which is only ever shared with stewards at the point of a pledge or handoff, never made public.

Achievements

Confirmed, fulfilled needs become a quiet public record — not a leaderboard of who gave the most, but a feed of what actually changed for someone, with a link back to their Case Page. Verified contributions, not participation trophies.

Snowflake HQ — the transparency layer

Then comes Snowflake HQ — what I call the GlassPocket layer, because every transaction is visible through the glass.

A one-click POST /api/sync pushes the entire local transactional state to Snowflake. Dashboard metrics are then computed via Snowflake SQL when available, or locally from store.json when not — the platform is always operational either way.

Snowflake surfaces:

Which neighborhoods have the most unfulfilled needs
Which categories are chronically undersupplied
Which Case Pages are going stale (steward abandonment detection)
Whether badge counts actually correspond to real confirmed handoffs
Which shared needs convert into pledges and which don't

Top Givers are ranked by confirmed handoffs — not pledges. That single distinction is the difference between a leaderboard and an accountability record.

The stack

Layer	Tech	Why
Framework	Next.js 15 (App Router), React 19	Server Components for the heavy lifting, Client Components for interactive hubs
Language	TypeScript (strict mode)	100% type safety across every API route and component
Styling	Vanilla CSS, custom design system	Reddit dark theme, glassmorphism, responsive grids — no framework overhead
Data	Local JSON store (`data/store.json`)	Atomically managed via `lib/store.ts`, auto-seeded on first run
Intelligence	Google Gemini AI	Auto-categorization, item extraction, urgency scoring on upload
Analytics	Snowflake Data Cloud	Relational telemetry with automated local fallback
Mapping	Leaflet + OpenStreetMap	Hyperlocal anchor point visualization

Repo structure:

app/              Next.js App Router — pages, layouts, API routes
components/       Feed, need cards, pledge pool, steward tools, forms, dashboard widgets
lib/              Types, store, seed data, Gemini client, Snowflake queries, auto-tagger
data/             store.json (auto-generated, gitignored)
scripts/          Snowflake diagnostics and connectivity tests
public/images/    Photorealistic need imagery

Worth reading: plan.md (product thesis), problems.md (every risk identified and how it's mitigated), lib/store.ts (the two-party verification cycle), lib/snowflake.ts (dual-engine telemetry with automatic fallback).

Safety decisions I'm proud of

Alias names, not legal names. Case Pages use pseudonyms and broad neighborhood tags — never exact addresses, never legal identity.

No solo stewardship. One person alone speaking for another is exactly the risk the platform exists to prevent. The system requires co-stewardship.

Consent isn't a checkbox. Verbal recorded consent is a structural requirement — a field in the data model, not a terms-of-service paragraph.

Anchor points over direct meetups. Handoffs route through a known local location (a shop, a community hub) rather than a stranger-to-stranger connection.

Staleness detection. Snowflake flags Case Pages with no recent updates. An abandoned page that still looks active is worse than no page at all.

Editable AI tags. Gemini proposes; the steward confirms. No auto-publish, no blind trust in classification.

Prize categories

Best Use of Snowflake — GlassPocket accountability layer
Snowflake is the transparency backbone. It powers the institutional dashboard (unfulfilled needs by category/area, urgency distribution, steward staleness detection, confirmed-handoffs-only leaderboard) with a dual-engine design that falls back to local computation with zero downtime if Snowflake is unreachable. Key design choice: analytics that fail silently are worse than no analytics at all — so the fallback is first-class, not an afterthought.

Best Use of Google AI — Gemini auto-categorization
Gemini analyzes every posted need (description and/or photo) to propose category, item type, quantity, and urgency. A local keyword-and-regex engine (lib/auto-tag.ts) provides identical functionality when Gemini isn't configured, so the platform never depends on a live API key to function. AI assists the steward — it does not replace the steward's judgment.

What I'd build next

Solana confirmation ledger — writing each verified handoff on-chain so badge counts are cryptographically auditable, not just database rows. The ConfirmationRecord model already has an on_chain_ref field waiting.
ElevenLabs voice input — letting stewards speak updates instead of typing, with auto-narrated Case Page timelines in multiple languages for low-literacy accessibility.
Duplicate detection — Gemini visual-similarity + area matching at Case Page creation, to prevent two stewards unknowingly opening pages for the same person.
Stewardship transfer — a formal flow for community members to take over inactive Case Pages after a defined inactivity window.
Real geospatial infrastructure — replacing manual neighborhood tags with location-aware matching and proximity-based feed prioritization.

The point

Someone posts a need. Someone else offers what they can. The community connects them. The handoff happens. The steward verifies it. The contribution becomes part of a trusted record.

Not everyone can donate money. But almost everyone has something they can give — a bag of rice, a spare cane, an afternoon.

NeedFeed turns those small acts into a connected, accountable community. No cash to divert. No vulnerable people to tag. No badges to fake. Just rice, sweaters, wheelchairs, and the receipts to prove they arrived.

Pritam-mb / charity

NeedFeed

Hyperlocal in-kind giving. Post a need, anyone can pledge a piece of it into an open pool a steward confirms the handoff, and the giver earns a verifiable badge — no money, no tagging of vulnerable people.

Product thinking lives in plan.md and problems.md (at repo root, ..).

Run it

npm install
npm run dev        # http://localhost:3000

The app works with zero API keys. Local auto-tagging stands in for Google AI and the Snowflake dashboard falls back to computing the same metrics locally.

Demo script (2–3 min)

Reel (/) — filter by category/area, open a need.
Case Page (/cases/c-arjun) — multi-entry timeline, recorded-consent badge, steward tools.
Pledge — on a need card, pledge a portion → “Mark handed off”.
Confirm — on the Case Page, steward tools → “Confirm received” → giver badge increments (see / toolbar is per-user; badge lives in store.json).
…

View on GitHub

👥 The Team

Our team came together for the International Charity Day DEV Challenge to build NeedFeed:

@pritam_patra_429a25dedae6 (Lead Developer)
@t-rexbytes (Collaborator)

Built with Next.js 15 · React 19 · Snowflake Data Cloud · Google Gemini AI · Leaflet · TypeScript

From 2.0 MB to 471 KB: Debugging Rawbee with Sentry + Gemini

Pritam Patra — Sun, 16 Aug 2026 21:37:22 +0000

I Thought Rawbee Was Slow — Then I Opened the Network Tab

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The Project

Rawbee is a full-stack video-sharing and real-time streaming platform that I built as a YouTube-inspired application.

It currently includes:

Video uploads
Video discovery
Subscriptions
Watch history
Live streaming
WebRTC-based functionality
Screen sharing
Socket.IO communication
Cloudinary media delivery

The stack includes:

Frontend: React 18, TypeScript, Tailwind CSS, Vite
Backend: Node.js, Express
Database: MongoDB
Media: Cloudinary
Real-time: Socket.IO, WebRTC
Observability: Sentry
AI debugging: Google Gemini

Repository: View Rawbee on GitHub

Bug Smash PR: View the Pull Request

For this Bug Smash, I deliberately stopped adding new features and focused on one question:

Where is Rawbee doing unnecessary work, and can I prove that my fixes actually made it better?

The Moment I Realized Something Was Wrong

Nothing was obviously broken.

The homepage loaded. Videos appeared. Search worked.

But the application felt heavier than it should.

My first instinct was to blame React.

When I typed into the search bar, the parent component updated and the video-card tree was being evaluated again.

So I opened React DevTools and started profiling.

The profiler showed repeated VideoCard renders during a simple interaction, even when the underlying video data had not changed.

That was the first bug.

Then I opened the Network tab.

And I found a much bigger problem.

The Network Tab Changed Everything

The production homepage was transferring approximately:

2.0 MB

Some individual image assets were enormous for their displayed size:

834 KB
433 KB
160 KB

An 834 KB thumbnail for a relatively small video card immediately looked wrong.

At that point, the problem stopped being:

"The page feels slow."

and became:

"The browser is downloading far more data than this UI should need."

Before: Production Baseline

📸 SCREENSHOT 1 — BEFORE NETWORK

Production baseline before optimization. The homepage transferred approximately 2.0 MB, with individual image assets reaching 834 KB, 433 KB, and 160 KB.

The baseline showed:

30 requests
2.0 MB transferred
2.3 MB resources
593 ms DOMContentLoaded
2.61 s Load
2.82 s Finish

For the first time, I had a real baseline instead of a vague feeling that the application was slow.

Fix #1 — Stopping Unnecessary React Renders

The first fix was React.memo().

The problem looked roughly like this:

Search state changes
        ↓
Home re-renders
        ↓
VideoCard renders again

But if the video's data hasn't changed, that child component doesn't necessarily need to render again.

I changed the component to:

import { memo } from "react";

const formatDuration = (seconds: number) => {
  // ...
};

const formatViews = (views: number) => {
  // ...
};

const VideoCard = memo(function VideoCard({
  video
}: VideoCardProps) {
  return (
    <div className="group cursor-pointer">
      {/* Video card UI */}
    </div>
  );
});

export default VideoCard;

I also moved pure formatting helpers outside the component so their definitions weren't recreated during every component execution.

The important optimization, however, was React.memo() combined with stable props.

When the video prop remains referentially equal, React can skip rendering the component.

React Profiler — Before

📸 SCREENSHOT 2 — REACT PROFILER BEFORE

Before memoization: VideoCard renders repeatedly during the recorded interaction as parent state changes.

The profiler gave me a concrete reason to make the optimization instead of blindly applying React.memo().

React Profiler — After

📸 SCREENSHOT 3 — REACT PROFILER AFTER

After memoization: the Profiler explicitly reports "Did not render on the client during this profiling session." The memoized component is skipped when its props remain unchanged.

The important result wasn't the raw number of React commits.

It was seeing React actually skip the component when its props remained unchanged.

Fix #2 — The 834 KB Thumbnail

The React optimization removed unnecessary rendering work.

But the Network tab was still pointing at the much larger problem:

image delivery.

The original application requested full-size images from Cloudinary even when the UI only needed a relatively small thumbnail.

I created a helper:

const getOptimizedCloudinaryUrl = (
  url: string,
  width = 500
) => {
  if (!url || !url.includes("cloudinary.com")) {
    return url;
  }

  return url.replace(
    "/upload/",
    `/upload/w_${width}/f_auto/q_auto/`
  );
};

Then:

<img
  src={getOptimizedCloudinaryUrl(
    video.thumbnail,
    500
  )}
  alt={video.title}
/>

The transformation uses:

w_500 to resize the image
f_auto to let Cloudinary select an appropriate format
q_auto to optimize quality

Before optimization, some image responses were approximately:

834 KB
433 KB
160 KB

After optimization, examples included:

7.3 KB
2.0 KB
22.0 KB
2.6 KB

This became the biggest contributor to the overall network improvement.

Instead of:

2.0 MB

the optimized production build transferred:

471 KB

That's a:

76.5% reduction in transferred data.

After: Optimized Production Build

📸 SCREENSHOT 4 — AFTER NETWORK

Same page, same throttling, same cache-disabled conditions. Payload dropped from 2.0 MB to 471 KB and Load time from 2.61 s to 1.60 s.

Fix #3 — Why Load JavaScript for Pages the User Hasn't Opened?

Rawbee contains multiple routes.

But a user visiting the homepage doesn't need every page's JavaScript immediately.

So I introduced route-level code splitting using React.lazy() and Suspense:

import { lazy, Suspense } from "react";

const Home = lazy(
  () => import("./pages/Home")
);

const Login = lazy(
  () => import("./pages/Login")
);

function App() {
  return (
    <Router>
      <Suspense <div className="flex h-screen items-center justify-center" fallback="{">
            Loading...
          </div>
        }
      >
        <Routes>
          <Route element="{<Login" path="/login"/>}
          />

          <Route element="{<Home" path="/"/>}
          />
        </Routes>
      </Suspense>
    </Router>
  );
}

Instead of:

Application
    ↓
Everything loads immediately

the browser can now load:

Current route
    ↓
Current route chunk
    ↓
User navigates
    ↓
Additional route chunk

This keeps the initial JavaScript workload focused on the route the user is actually visiting.

Fix #4 — Cleaning Up Sentry Configuration

While working on observability, I also found that the Sentry DSN was hardcoded in the source.

I moved it to environment configuration.

Before:

Sentry.init({
  dsn: "your_dsn_here"
});

After:

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN
});

with:

VITE_SENTRY_DSN=your_dsn_here

This makes the configuration easier to manage across environments and keeps environment-specific configuration outside application source.

Fix #5 — When MongoDB Stopped Connecting

While working on the frontend, I encountered a completely different problem.

MongoDB stopped connecting and the backend reported:

querySrv ECONNREFUSED

At first, I treated it as a MongoDB problem.

But the failure was occurring during DNS/SRV resolution.

I investigated the DNS behavior using:

Resolve-DnsName <mongodb-host>

After confirming the DNS resolution problem in my Windows environment, I changed the MongoDB connection strategy to a direct connection configuration as a workaround.

The backend then reconnected successfully.

Best Use of Sentry

Sentry became part of my debugging workflow rather than something I added only after the application was finished.

My process became:

Runtime problem
      ↓
Sentry captures the event
      ↓
Inspect issue + stack trace + context
      ↓
Locate affected code
      ↓
Fix
      ↓
Verify

One concrete example happened during a refactor.

I accidentally removed an import for VideoSkeleton.

The application could still build successfully.

But when the loading path executed at runtime, the browser threw:

ReferenceError: VideoSkeleton is not defined

Sentry captured the runtime failure and provided the stack trace and surrounding debugging context.

Instead of:

"Something is broken."

I now had:

"This exact runtime path is throwing this exact error."

📸 SCREENSHOT 5 — SENTRY ISSUE

Sentry captured the runtime failure with the stack trace and execution context used during debugging.

Sentry and React Profiler Answered Different Questions

One of the biggest lessons from the project was that different debugging tools answer different questions.

Sentry

What is failing?

React Profiler

What is rendering?

Chrome Network

What is the browser downloading?

Using separate tools for separate questions made the investigation much clearer.

Best Use of Google AI

I used Google Gemini 3.1 Pro as a debugging partner rather than simply asking it to generate code.

The MongoDB DNS error was the clearest example.

I provided Gemini with:

The querySrv ECONNREFUSED error
My Windows environment
Node.js information
The MongoDB connection behavior

Gemini helped investigate possible causes involving DNS resolution, MongoDB SRV records, and IPv4/IPv6 behavior.

One useful diagnostic was:

Resolve-DnsName _mongodb._tcp.cluster0.x3qwygg.mongodb.net

I ran the command myself.

That distinction was important:

I treated Gemini's response as a hypothesis, not as proof.

I independently verified the behavior before changing the connection configuration.

The debugging loop became:

MongoDB querySrv ECONNREFUSED
        ↓
Gemini analysis
        ↓
DNS / IPv4-IPv6 hypothesis
        ↓
Resolve-DnsName verification
        ↓
Connection configuration workaround
        ↓
Backend restored

📸 SCREENSHOT 6 — GEMINI DEBUGGING

Gemini helped narrow down the MongoDB connection failure; I independently verified the suggested diagnostic path before implementing the workaround.

The useful part of AI debugging wasn't:

"AI wrote code for me."

It was:

"AI helped me turn an unfamiliar error into a testable hypothesis."

The Final Benchmark

After applying the fixes, I repeated the production benchmark under the same conditions:

Chrome
Fast 4G throttling
Browser cache disabled
Same homepage
Same machine
Same production preview workflow

Metric	Before	After	Change
Network transferred	2.0 MB	471 KB	−76.5%
Resources loaded	2.3 MB	767 KB	−66.7%
Load event	2.61 s	1.60 s	−38.7%
Finish	2.82 s	1.81 s	−35.8%
Requests	30	32	+2
DOMContentLoaded	593 ms	624 ms	+31 ms

The two numbers I cared about most were:

2.0 MB → 471 KB

76.5% less network data transferred

and:

2.61 s → 1.60 s

38.7% faster Load event

What Didn't Improve

Not every metric improved.

The request count changed:

30 → 32

and DOMContentLoaded changed:

593 ms → 624 ms

I also had a stale thumbnail returning a 404, which I flagged as follow-up work.

I don't want to turn a benchmark into:

"Everything got better."

It didn't.

The meaningful result was the large reduction in transferred data and the improvement in the Load event.

Those are the results I can actually demonstrate.

What I'm Most Proud Of

The thing I'm most proud of isn't a particular line of code.

It's the change in how I approached the problem.

Before this work, my instinct would have been:

"The application feels slow. I should optimize the code."

Now the process is:

Observe
   ↓
Measure
   ↓
Hypothesize
   ↓
Test
   ↓
Fix
   ↓
Measure again

I thought React rendering was the main problem.

Then the Network tab showed me that an 834 KB thumbnail was a much bigger issue.

That was a useful reminder:

The thing that feels slow isn't always the thing that is actually expensive.

What I Learned

Profile before optimizing

React.memo() is useful when you can identify unnecessary renders.

The profiler gave me evidence to make the change.

Network payload matters

A frontend can have clean React code and still feel slow if the browser downloads unnecessary data.

Observability changes debugging

Sentry turned runtime errors into actionable issues instead of vague UI failures.

AI works best with verification

Gemini helped me investigate the MongoDB problem faster, but I still tested the hypothesis myself.

Not every metric needs to improve

A useful benchmark should report the actual result, including the numbers that didn't move in the desired direction.

What's Next for Rawbee?

The Bug Smash focused on performance, reliability, and debugging.

But Rawbee is still evolving.

The next direction is a more interactive social streaming experience.

Future work includes:

Live Rooms
WebRTC video/audio
Screen sharing
Real-time Socket.IO chat
Synchronized watch parties
Multi-user co-streaming
Host controls

The goal is eventually to let users watch, communicate, and participate together without needing a separate application for every part of the experience.

These are future roadmap features and are not included in the performance measurements above.

Final Result

The most important transformation was:

2.0 MB → 471 KB

A 76.5% reduction in network transfer.

The Load event changed from:

2.61 s → 1.60 s

A 38.7% improvement.

Along the way I also:

Reduced unnecessary VideoCard rendering
Optimized Cloudinary image delivery
Added route-level code splitting
Improved Sentry configuration
Diagnosed a MongoDB DNS/SRV failure
Used Sentry for runtime observability
Used Gemini to accelerate debugging

No rewrite.

No new framework.

Just:

Measure → Understand → Fix → Verify

Links

Rawbee Repository:
https://github.com/Pritam-mb/rawbee

Bug Smash Pull Request:
https://github.com/Pritam-mb/rawbee/pull/1

Thanks for reading.

And thanks to DEV and Sentry for giving me a reason to stop adding features for a moment and ask:

How well does the application I've already built actually work?

Slashing Network Payload by 76%: How I Used Sentry and Gemini to Optimize a Real-Time Streaming Platform

Pritam Patra — Sun, 16 Aug 2026 19:21:13 +0000

From 20+ Unnecessary Renders to a 76.5% Smaller Network Payload — How I Optimized Rawbee with Sentry + Gemini

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

Project: Rawbee — Collaborative Real-Time Streaming Platform
Implementation: View the GitHub Pull Request
Repository: View the GitHub Repository

Rawbee is a full-stack video sharing and live streaming platform with traditional VOD features (uploads, subscriptions, watch history) alongside a WebRTC-based collaborative streaming engine for co-streaming, screen sharing, and in-browser voice/video chat.

The current stack includes:

Frontend: React 18, TypeScript, Tailwind CSS, Vite
Backend: Node.js, Express
Database: MongoDB
Media: Cloudinary
Observability: Sentry
AI debugging assistant: Google Gemini

For the Summer Bug Smash, I focused on improving the existing application rather than adding a new feature.

My goal was simple:

Find real problems → measure them → understand the root cause → fix them → measure again.

During the Bug Smash, I addressed frontend performance issues, a backend reliability problem, and runtime errors surfaced through Sentry.

Bug Fix or Performance Improvement

As Rawbee grew, the homepage started doing more work than necessary.

The first issue appeared while using the search bar. Updating the search state caused the parent component to re-render, and the video-card grid was repeatedly evaluated even when individual video data had not changed. React Profiler confirmed repeated VideoCard renders during the interaction, which led me to investigate whether those renders were actually necessary.

The second problem was visible directly in Chrome DevTools. The homepage was transferring a surprisingly large amount of data, with several individual image assets reaching hundreds of kilobytes.

The original production trace contained images such as:

834 KB PNG
433 KB JPEG
160 KB JPEG

I also found that the frontend was loading more JavaScript up front than necessary because page-level code was not being split efficiently.

On the backend, MongoDB was failing to connect in my Windows environment with:

querySrv ECONNREFUSED

Finally, Sentry was capturing frontend runtime errors that gave me useful visibility into failures occurring inside the application.

Controlled Before/After Benchmark

To make the performance comparison meaningful, I benchmarked the before and after production builds using the same setup:

Chrome
Fast 4G throttling
Browser cache disabled
Same homepage
Same machine
Same production preview workflow

Metric	Before	After	Improvement
Network transferred	2.0 MB	471 KB	76.5% reduction
Resources loaded	2.3 MB	767 KB	66.7% reduction
Load event	2.61 s	1.60 s	38.7% faster
Finish	2.82 s	1.81 s	35.8% faster
Requests	30	32	No improvement
DOMContentLoaded	593 ms	624 ms	Slightly higher

I am deliberately reporting the metrics that actually improved instead of dressing every measurement as a win. Request count went slightly up, partly because of a stale thumbnail returning 404, and DOMContentLoaded shifted marginally within measurement noise.

The headline result is the 76.5% payload reduction.
The biggest measurable gain came from reducing the amount of image data transferred to the browser.

Before: Production Benchmark

Production baseline before optimization. The homepage transferred approximately 2.0 MB, dominated by unoptimized image assets — including an 834 KB PNG, a 433 KB JPG, and a 160 KB JPG.

After: Production Benchmark

Same page, same throttling, same cache-disabled conditions. Payload dropped from 2.0 MB to 471 KB and Load time from 2.61 s to 1.60 s.

Code

The complete implementation is available in the GitHub Pull Request.

The main changes covered:

React.memo
Cloudinary image transformations
React.lazy / Suspense
MongoDB connection workaround
Sentry configuration improvements

1. Memoizing `VideoCard`

import { memo } from "react";

const formatDuration = (seconds: number) => {
  // ...
};

const formatViews = (views: number) => {
  // ...
};

const VideoCard = memo(function VideoCard({
  video,
}: VideoCardProps) {
  return (
    <div className="group cursor-pointer">
      {/* Video card UI */}
    </div>
  );
});

export default VideoCard;

The important optimization here is React.memo.

When the parent component updates, React can skip rendering the memoized VideoCard if the video prop remains referentially equal.

I also moved pure formatting helpers outside the component so they are not recreated as part of each component execution.

2. Cloudinary Image Optimization

This was the single biggest performance win in the benchmark. An 834 KB PNG for a card thumbnail was far larger than necessary for the displayed dimensions.

const getOptimizedCloudinaryUrl = (
  url: string,
  width = 500
) => {
  if (!url || !url.includes("cloudinary.com")) {
    return url;
  }

  return url.replace(
    "/upload/",
    `/upload/w_${width}/f_auto/q_auto/`
  );
};

Then:

<img
  src={getOptimizedCloudinaryUrl(video.thumbnail, 500)}
  alt={video.title}
/>

The w_500 resizes to display dimensions, f_auto serves modern formats (WebP/AVIF) where supported, and q_auto picks quality intelligently.

The before trace contained image responses of 834 KB, 433 KB, and 160 KB. The after trace shows the same images at 7.3 KB, 2.0 KB, 22.0 KB, and 2.6 KB. This single change is the primary contributor to the 2.0 MB → 471 KB reduction.

3. Route-Level Code Splitting

import { lazy, Suspense } from "react";

const Home = lazy(() => import("./pages/Home"));
const Login = lazy(() => import("./pages/Login"));

function App() {
  return (
    <Router>
      <Suspense
        fallback={
          <div className="flex h-screen items-center justify-center">
            Loading application...
          </div>
        }
      >
        <Routes>
          <Route path="/login" element={<Login />} />
          <Route path="/" element={<Home />} />
        </Routes>
      </Suspense>
    </Router>
  );
}

This moved page-specific JavaScript into route-level chunks instead of requiring every page to be part of the initial route workload.

4. Sentry Environment Configuration

// frontend/.env

+ VITE_SENTRY_DSN=your_dsn_here

// frontend/src/main.tsx

Sentry.init({
-  dsn: "your_dsn_here",
+  dsn: import.meta.env.VITE_SENTRY_DSN,
});

This makes the configuration easier to manage across different environments.

5. MongoDB DNS Failure

The backend was failing with:

querySrv ECONNREFUSED

I investigated the DNS behavior in the Windows environment and used:

Resolve-DnsName <mongodb-host>

to verify the DNS resolution problem.

I then switched to a direct MongoDB connection configuration as a workaround for the affected environment, restoring database connectivity.

My Improvements

1. Eliminating unnecessary React work

The first performance problem was component-level rendering.

A search update causes the Home component to update, but an individual video card does not necessarily need to update with it.

Before optimization:

Search state changes
        ↓
Home updates
        ↓
VideoCard repeatedly renders

After optimization:

Search state changes
        ↓
Home updates
        ↓
React.memo checks props
        ↓
VideoCard render skipped when props are unchanged

React Profiler Evidence

React Profiler evidence — before:

Before memoization: VideoCard renders repeatedly across the profiling session as parent state updates.

React Profiler evidence — after:

After memoization: the Profiler explicitly reports "Did not render on the client during this profiling session." The memoized component is skipped entirely when props are unchanged.

React Profiler evidence for the memoized component. The optimized VideoCard was skipped during the recorded interaction when its props remained unchanged.

I am intentionally not presenting the React commit count itself as the number of renders. The important result is that the profiler directly shows the memoized component being skipped.

2. Reducing image payload

The largest measurable performance improvement came from image delivery.

The original production trace contained image resources such as:

834 KB
433 KB
160 KB

After applying Cloudinary transformations, the optimized trace contained much smaller responses, including examples around:

7.3 KB
2.0 KB
22.0 KB
2.6 KB

This change was the main contributor to:

2.0 MB → 471 KB

or a 76.5% reduction in transferred data.

3. Reducing initial JavaScript work

The route-level React.lazy() change means that the browser no longer needs to load code for every page before the current route can operate.

Before:

Initial application
├── Home
├── Login
├── other route code
└── dependencies

After:

Initial route
├── shared dependencies
└── current page chunk

Additional page
└── loaded on demand

This keeps the initial route focused on the code it actually needs.

4. Backend reliability improvement

The MongoDB issue was not treated as a performance metric because it was fundamentally a reliability problem.

The debugging process was:

MongoDB connection fails
        ↓
querySrv ECONNREFUSED
        ↓
DNS investigation
        ↓
Resolve-DnsName verification
        ↓
Direct connection workaround
        ↓
Backend connectivity restored

This fix removed a development blocker that was preventing the API from connecting to the database.

Best Use of Sentry

I am submitting this project for the Best Use of Sentry category.

Sentry became part of the debugging workflow rather than simply being another dependency.

The workflow was:

Runtime problem
      ↓
Sentry captures the event
      ↓
Inspect issue + stack trace
      ↓
Locate affected code
      ↓
Fix
      ↓
Verify application behavior

During development, Sentry captured frontend runtime errors including:

ReferenceError: VideoSkeleton is not defined

Sentry provided:

issue details
event information
stack trace
browser/environment context
affected execution path

That helped me move from:

"Something is broken."

to:

"This specific code path is failing for this specific reason."

Sentry Evidence

Sentry became part of my debugging loop, not just a dependency in package.json. The workflow was consistent throughout the Bug Smash:

Runtime failure → Sentry captures event → inspect issue + stack trace + context → locate affected code → fix → verify.

One concrete example: during a refactor, I accidentally removed an import for VideoSkeleton. It didn't crash the build — it only threw at runtime when the loading state triggered. Without Sentry I'd have found it eventually when a user reported a blank page. With Sentry, I had it within minutes:

Sentry captured the ReferenceError with the full stack trace, release hash, browser and OS context, and event breadcrumbs. This turned "the page is broken sometimes" into a single actionable issue with a direct line to the failing code path.

What Sentry gave me that my terminal couldn't: the release hash tying the error to a specific build, the browser and OS the user hit it on, the URL and route where it happened, and the trace ID linking to surrounding events. That context is what turned a five-word error into a five-minute fix.

Importantly, I used Sentry for runtime observability and React Profiler for component rendering analysis — I didn't conflate them. Sentry told me what was failing; the Profiler told me how components were rendering. Keeping those two evidence streams separate gave me a cleaner picture of the application's actual behavior.

Best Use of Google AI

I am also submitting this project for the Best Use of Google AI category.

I used Gemini 3.1 Pro as a debugging partner during the Bug Smash rather than simply asking it to generate the implementation.

The clearest example was the MongoDB connection problem.

1. Problem

The backend returned:

querySrv ECONNREFUSED

and the application could not establish its database connection.

2. Gemini investigation

I provided Gemini with the error and information about my Windows environment.

Gemini analyzed the failure and suggested investigating DNS and IPv4/IPv6 resolution behavior.

3. Independent verification

I did not blindly copy the recommendation.

I ran the diagnostic myself:

Resolve-DnsName <mongodb-host>

and verified the DNS resolution problem.

4. Implementation

After confirming the issue, I changed the MongoDB connection strategy to use a direct connection configuration that avoided the failing SRV-resolution path.

5. Result

The backend was able to reconnect to MongoDB and resume normal operation.

The overall debugging loop became:

querySrv ECONNREFUSED
        ↓
Gemini analysis
        ↓
DNS hypothesis
        ↓
Resolve-DnsName verification
        ↓
Connection workaround
        ↓
Backend restored

I treated Gemini's response as a hypothesis, not as the final answer. I independently verified the DNS behavior before changing the MongoDB connection strategy.

Gemini Evidence

Use the screenshot showing Gemini analyzing the querySrv ECONNREFUSED problem and discussing the DNS/connection investigation.

Suggested caption: Gemini helped narrow down the MongoDB connection failure; I independently verified the suggested diagnostic path before implementing the workaround.

The important part for me was not simply generating code faster. It was shortening the path from an unfamiliar error to a testable hypothesis.

Final Impact

The clearest measured result was the reduction in network transfer:

2.0 MB → 471 KB

That's a 76.5% reduction.

The Load event changed from:

2.61 s → 1.60 s

which is a 38.7% reduction in Load time.

The total resource footprint changed from:

2.3 MB → 767 KB

which is a 66.7% reduction.

The React Profiler also showed that the optimized VideoCard could be skipped during the recorded search interaction when its props remained unchanged.

The MongoDB issue was resolved as a backend reliability fix, while Sentry and Gemini made the debugging workflow more observable and efficient.

What I Deliberately Did Not Claim

Not every metric improved.

Request count moved from 30 to 32, partly because a stale thumbnail returned 404. DOMContentLoaded moved from 593 ms to 624 ms, which I consider within the noise of this benchmark.

The strongest measured result is the reduction in transferred data from 2.0 MB to 471 KB, followed by the Load improvement from 2.61 s to 1.60 s.

The Sentry runtime event shown in this post was captured in development; validating the same workflow against production traffic is a next step.

Future Roadmap for Rawbee

The Bug Smash was focused on performance and reliability, but I also have a larger direction planned for Rawbee.

The next stage is to turn Rawbee from a traditional video-sharing application into a more interactive, social streaming platform.

Planned future work includes:

Live Rooms where users can create and join shared sessions
WebRTC video/audio calling
Screen sharing
Real-time room chat using Socket.io
Synchronized watch experiences
Multi-user collaborative streaming
Host controls and participant management

The goal is to let users watch and interact together without needing a separate Discord or video-call application.

These real-time features are future work and are not included in the performance measurements reported in this Bug Smash submission.

Conclusion

This Bug Smash started with a simple observation: Rawbee was getting slower as the application grew.

Instead of rewriting large parts of the project, I used measurement and debugging tools to identify where the actual problems were.

The result was a focused set of improvements:

React.memo
      ↓
Less unnecessary rendering

Cloudinary transformations
      ↓
Smaller image payloads

React.lazy + Suspense
      ↓
Route-level code splitting

DNS investigation + MongoDB workaround
      ↓
Backend reliability restored

Sentry
      ↓
Runtime visibility

Gemini
      ↓
Faster debugging investigation

The biggest measurable performance improvement was:

2.0 MB → 471 KB transferred

with the production Load event improving from:

2.61 s → 1.60 s

The main takeaway is simple:

Before optimizing code, measure what the application is actually doing.

That is what I tried to do throughout this Bug Smash: identify the real bottlenecks, fix them deliberately, and verify the results instead of relying on assumptions.

Implementation

GitHub Pull Request: View PR #1

Repository: View Rawbee on GitHub

Thanks for checking out my submission!