DEV Community: Ranbir Singh

Every refused COD parcel costs an Indian seller ₹150. RTO Shield stops them before they ship.

Ranbir Singh — Sun, 18 Oct 2026 18:03:02 +0000

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

In India, a lot of online orders are cash on delivery. The buyer taps "COD", forgets about it, and when the courier shows up three days later they refuse the parcel, aren't home, or gave an address the courier can't find. The parcel goes back to the seller. That's an RTO, a return to origin.

The seller doesn't get the product's price back as profit. They lose the shipping out and the shipping back. RTO Shield uses ₹150 as the default cost of one RTO, and the shop can change it. For a small D2C brand making a few hundred COD orders a month, that adds up to a real slice of the margin, lost on orders that never had to ship.

Most of these returns can be predicted, and many can be fixed: confirm the order before it ships, correct a bad address, or nudge the buyer to pay up front. Sellers already know that. They just don't have the hours to message every risky buyer by hand.

So I built RTO Shield, an autopilot that does that work for Shopify sellers.

What I Built

RTO Shield connects to a Shopify store and works through every new COD order:

Scores it. Every pending order gets a 0–100 risk score, a Low / Medium / High band and a one-line reason.
Messages the buyer on WhatsApp. The message goes from RTO Shield's platform number with the shop's name on it, asking the buyer to confirm, or offering a prepaid link. The seller never pastes a token.
Fixes the address. If the buyer replies with a corrected address, the API parses it and checks the pincode against India Post. If the city and state agree, the fix is written back to Shopify and confirmation carries on.
Calls when nobody answers. A silent buyer moves on to a voice-agent call.
Hands the leftovers to a human. Whatever still needs the seller lands on Exceptions, with Confirm, Cancel and one extra call. Nothing else needs their attention.

The seller mostly looks at two screens. Results shows the money saved. Exceptions shows the short list that needs a decision.

The demo shop's Results screen (demo data): ₹13,246 prevented, 3 COD orders converted to prepaid, 2 addresses fixed, 17 orders confirmed before they shipped.

Who pays, and why. The buyer is a small Indian D2C seller on Shopify who ships COD. The suggested price is ₹499 a month. At ₹150 an RTO, preventing four returns a month pays for it. Everything after that is margin they'd otherwise have handed to the courier. (This build doesn't take a card yet.)

There's also a robot voice tour that walks a new seller through the app in Hindi, English or Hinglish, because many of the people running these stores aren't developers and don't want to read docs.

Demo

Live: www.rtoshield.tech
Judges: press Try the demo on the landing page. There's no sign-up; it drops you into a demo shop with real screens and demo orders. The robot tour starts by asking for a language.
Talk to the agent: open Exceptions and pick the order. In the demo you can start an in-browser call with the voice agent, so you can hear what a buyer would hear. You get two demo calls every 30 minutes, and Reset call starts a fresh one.
The API and ML service run on Render's free plan and sleep when idle, so the first load can take about a minute. The site waits until both services report healthy.

Exceptions keeps a human in the loop: the order's history, Confirm / Cancel, and at most one extra call. In test mode the call is clearly labeled "Simulated call".

Code

Ranbir5ingh / rto-shield

Predict and prevent COD return-to-origin (RTO) losses for small Indian sellers with open-source AI (TabPFN + Gemma).

RTO Shield

Autopilot for cash-on-delivery returns. It scores an order, messages the buyer, fixes the address, and calls when nobody answers. The seller sees what stopped.

Live demo: www.rtoshield.tech

Suggested price: ₹499 a month. This build does not take a card.

The problem

A refused cash-on-delivery parcel in India still costs the return trip. RTO Shield uses ₹150 as the default cost of the shipping on one return-to-origin. The shop can change that number. Results counts rupees prevented as converted and cancelled risky orders, plus shipping. It is a planning figure, not a payout.

The buyer is asked before the parcel ships. A bad address is checked. A silent buyer gets a call. The orders that still need a person land on Exceptions.

Features

Score. Each pending order gets 0–100, a Low, Medium, or High band, and a short reason. A pincode is courier context, not a ban.
Autopilot WhatsApp.…

View on GitHub

A monorepo with three services and an MIT license. CI runs lint, typecheck, unit tests, a production build and Playwright end-to-end tests (seller tour, judge demo tour, Exceptions) on every push, plus ruff and pytest for the ML service.

How I Built It

Shopify order ─▶ NestJS API (Render) ──▶ ML service (FastAPI, Render)
                    │                       ├─ TabPFN: risk score from this shop's own history
                    │                       ├─ scikit-learn: instant score on every new order
                    │                       └─ Gemma 4: address-quality notes + message drafts
                    ├─▶ WhatsApp Cloud API ─▶ buyer replies ─▶ address parse ─▶ India Post ─▶ Shopify write-back
                    ├─▶ ElevenLabs voice agent (calls, Hindi/English/Hinglish tour)
                    └─▶ MongoDB Atlas (orders, users, audit; phones and addresses encrypted)
Next.js 15 web app (Vercel) ─ www.rtoshield.tech

The model learns the shop, not the pincode

The easy shortcut in RTO scoring is to blacklist pincodes. It's unfair to buyers, and it's wrong for a seller whose customers in that area pay fine. So in RTO Shield a pincode is not a model feature. The score uses 15 signals: order value, COD or prepaid, the hour (as a circle, so 11 PM sits next to midnight), the buyer's prior orders and prior returns, whether they're new, high-value COD, late-night orders, address-quality flags (incomplete, junk, landmark-only, city/state mismatch), and this shop's own return rate in that area, shrunk toward typical so one bad week can't swing it. The score never sees the buyer's phone or name.

TabPFN does the full scoring. It's Prior Labs' open-source tabular foundation model: it learns in context from the shop's own labelled history (delivered vs returned) and scores the pending orders in one pass. There's no training pipeline to run per seller, which matters when every shop has a different few hundred orders. On the live service it runs through Prior Labs' hosted tabpfn-client.

A new order needs a score straight away, before WhatsApp fires, so new orders, webhooks and the demo get an instant scikit-learn gradient-boosting score. TabPFN then rescores in full. If TabPFN is unreachable, the chain falls back to local TabPFN, then scikit-learn, then a rules prior, and scoring never just stops.

Gemma reads the address, code decides

Indian addresses are messy: "near Hanuman mandir, behind petrol pump", a missing house number, or a city that doesn't match the pin. Gemma 4 (gemma-4-26b-a4b-it) reads each address and returns structured quality notes, which become features and a plain-English reason for the seller. It also drafts the confirmation messages.

Gemma never gets the last word on facts. Whether an address is valid is decided by India Post's pincode data, not by a model: when a buyer sends a correction, it's only written to Shopify if India Post's city and state agree. If a check fails, that's recorded on the order and the fix is skipped.

WhatsApp without the setup

Asking a small seller to create a Meta Business account, register a number and paste tokens loses them on day one. So RTO Shield sends from its own platform number, with the shop's name on every template. A shop that wants buyers to see its own number can switch that on in Settings. Its token is stored encrypted and only that shop's messages move.

Calls, but autonomous

Calls run on an ElevenLabs conversational agent. The seller doesn't start calls; Autopilot does. From Exceptions the seller gets exactly one extra call per order, the result shows inline, and if the buyer answers, the order goes back into the pipeline. I capped it on purpose, because a tool that lets a seller ring a buyer five times turns into a harassment tool. ElevenLabs also voices the Hindi, English and Hinglish tour.

What's real today, and what's a switch

I'd rather say this up front:

WhatsApp runs on Meta's test number. It works end to end. I've confirmed an order from my own phone. But a test number can only message numbers verified on the Meta app, and the store-name templates are waiting for Meta's approval.
Outbound phone calls are simulated. With CALLS_MODE=browser, Autopilot and "Try one more call" record a clearly labeled Simulated call and dial nobody. The in-browser demo call is a real conversation with the agent.
Going live is config, not code. Add a paid WhatsApp number, import a Twilio number into ElevenLabs, and set CALLS_MODE=live. The steps are in docs/PRODUCTION.md. Sellers don't set anything up.
Demo numbers are demo data. ₹13,246 is the demo shop's figure. The model eval in the repo runs on a synthetic set, and I label it that way.

Built fast, with agents

I built this during the challenge week (first commit October 15) with AI coding agents doing much of the typing, while I made the product calls: no pincode bans, one extra call, platform-owned AI keys, Exceptions-first design. The whole stack runs on free tiers: Vercel, Render, MongoDB Atlas and free API tiers.

Why Does Open Innovation Matter?

The unit economics only work if the AI is cheap. A seller pays ₹499 a month, and a single RTO costs ₹150. If every order's score and every address check went through a per-token closed API, the AI bill would eat the margin I'm trying to save. TabPFN and Gemma are open, so I can run them wherever is cheapest. Today that's free hosted tiers. At scale it can be my own box.

Open models let me fit the problem instead of the API. Every Shopify store is a different, small dataset. TabPFN is built for exactly that: a few hundred rows, scored in context. It's open, so I can read how it works, run it locally (the code already supports the local tabpfn package) and fall back to scikit-learn without changing anything else. A closed "risk score API" would give me a number and ask me to trust it.

Seller and buyer data stays under our control. Buyer phones and addresses are some of the most sensitive data a small business holds. Gemma's weights are open, so the same address check can run on our own hardware through Ollama. Setting OLLAMA_BASE_URL switches it, and docker compose --profile ollama brings up a local Gemma. Today, honestly, production calls Gemma through Google AI Studio, because a free Render instance can't hold the model. The point is that I'm not locked in.

No lock-in on price or on a vendor. Every AI piece sits behind an env var with a fallback: TabPFN → scikit-learn → rules, Gemma → templates. If a provider changes its price or goes down, RTO Shield degrades instead of breaking.

Where I still use closed models: Gemini 2.0 Flash parses buyers' free-text address replies and powers the call agent's conversation, because it was the fastest reliable option for messy Hinglish on a free tier this week. It also sits behind templates as a fallback, and moving those jobs onto Gemma is the next step.

The stack is open too: Next.js, NestJS, FastAPI, scikit-learn and India Post's public pincode API. RTO Shield is mostly glue on top of other people's open work, and the repo is MIT so the next person can build on it.

My First User

I haven't charged anyone yet, and I won't pretend I have.

I messaged e-commerce business owners in my own circle, people who ship COD orders and deal with RTOs every week, and showed them what RTO Shield does. They told me they want to use it once it's live. What's holding it back isn't the product. It's the paid pieces: a verified WhatsApp Business number, a calling number and paid hosting. Right now everything runs on free and developer tiers because I don't have funding for those yet.

As soon as that's sorted, the switch is a config change, and I have sellers waiting to plug in their stores.

Prize Categories

Best Use of TabPFN: TabPFN does the full risk scoring. It learns in context from each shop's own delivered-vs-returned history across 15 features (no pincode) and scores the pending orders through Prior Labs' tabpfn-client. It's the core of a wider prediction agent: the score decides who gets a WhatsApp, a prepaid offer, a call, or a spot on Exceptions. The live service reports active_predictor: tabpfn-client, and the fallback chain is local TabPFN → scikit-learn → rules.
Best Use of Gemma: Gemma 4 (gemma-4-26b-a4b-it, served through Google AI Studio) reads every address for quality problems: incomplete, landmark-only, junk, or a city/state mismatch. Those notes become model features and the seller-facing reason, and Gemma also drafts the confirmation messages. A local Gemma path through Ollama is built in.
Best Use of Render: The NestJS API and the FastAPI ML service (TabPFN + Gemma) both run on Render from a render.yaml Blueprint, with secrets kept out of the repo (sync: false), health checks, and the custom domains api.rtoshield.tech and ml.rtoshield.tech.
Best Use of ElevenLabs: A conversational ElevenLabs agent is the calling layer for buyers who don't reply. Judges can talk to it in the browser in the demo. ElevenLabs v3 also narrates the robot tour in Hindi, English and Hinglish. Outbound phone calls are simulated in test mode, and live dialing is one config switch.
Best Use of MongoDB Atlas: Atlas is the data layer for orders, scores, WhatsApp threads, call outcomes, users and the audit log behind Results, Exceptions and Activity. Buyer phones and street addresses are encrypted at rest.
Best Use of a .tech Domain: The whole product lives on rtoshield.tech: the app at www.rtoshield.tech, the API at api.rtoshield.tech and the ML service at ml.rtoshield.tech.

Built solo by Ranbir Singh.

If you sell on Shopify in India, how many of your COD orders come back? I'd love to hear what you'd want RTO Shield to handle next.

Dead Drop: a hide-and-seek network for the real world

Ranbir Singh — Sun, 11 Oct 2026 18:27:06 +0000

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

What I Built

Dead Drop — a hide-and-seek network for the real world.

Here's the problem with most "touch grass" apps: they hand you AI-generated errands. Walk to the park. Photograph a tree. Check in. You're still playing single-player against an app, and the grass is just a backdrop.

Dead Drop flips it. Humans hide real objects for other humans. You stash a painted stone in a park, describe the vicinity (never the exact spot), and the AI writes a cryptic riddle for it. Hunters browse riddles, walk outside, find the thing, and photograph it. Then the AI does the one job it's actually good at here: referee. It compares the find photo against the hider's description and issues a verdict — match or no match. No couch-faking. Both sides score.

Every screen is designed to end with you going outside. No feeds. No infinite scroll. No notification spam. The reward is genuinely variable — you never know what's hidden until you find it, and as a hider you never know when someone finds yours. Finders become hiders; that's the loop.

It's for anyone who's ever wanted their neighborhood to feel a little more like an adventure.

Demo

Live app: https://dead-drop-eight.vercel.app/

(Narration generated with ElevenLabs. The video shows the full loop: login → hiding a drop with live AI riddle generation → the drop going live → hunting → photo verification → leaderboard.)

Code

Ranbir5ingh / dead-drop

Hide a small treasure outdoors. Hunt someone else's by riddle. An AI referee checks the photo.

Dead Drop

Humans hide real things for each other. AI only referees.

A hider stashes a small object outdoors, describes the vicinity, and the referee writes a riddle. A hunter reads the riddle, goes outside, and photographs the object. Vision verification decides the match. Both sides score. The exact spot is never published. The app never arranges a meeting.

This is a mobile-first PWA for the Hacktoberfest Week 1 "Touch Grass" DEV challenge.

Phone (mobile browser, nothing installed)
   │  HTTPS JSON
   ▼
Vercel  — Next.js UI, GSAP, camera
   │  NEXT_PUBLIC_API_URL
   ▼
Render  — NestJS API, the AI runtime
   ├── Supabase Postgres (Drizzle) — drops, finds, scores
   ├── Supabase Storage — drop-photos bucket
   └── Google AI Studio — Gemma, riddles + photo checks

The phone does not run a model. It calls the API. The API calls Gemma. Keys never reach the browser.

Honesty about photos

The hosted demo sends find-photos…

View on GitHub

How I Built It

The AI: Gemma as the referee, not the quest-giver.

Riddle generation. Gemma takes the hider's vicinity description and writes a cryptic, solvable riddle — behind strict guardrails: never an address, coordinates, or exact spot name. A deterministic safety scan runs in code, and the AI never overrides it.
Find verification. Gemma (vision) compares the hunter's photo against the hidden object's description and returns a strict match/no-match verdict with a confidence score. Uncertain → no match, always. This honesty is the product's trust core: scores only mean something because the referee can't be gamed.

Gemma runs two ways behind one provider interface: served through Google AI Studio (gemma-3-12b-instruct) in production, and via Ollama locally during development. Same adapter, env-switched.

The stack:

Frontend: Next.js 16 + Tailwind + GSAP, mobile-first PWA (Vercel)
Backend: NestJS API — the project's AI runtime (Render)
Data: Supabase Postgres via Drizzle ORM; photos in Supabase Storage, uploaded server-side only
Auth: email + Google/GitHub OAuth, httpOnly sessions

One honest note: the deployed demo sends find photos to Google's API so Gemma can referee them. The local Ollama path — where photos never leave the machine — is documented in the README as the privacy-preserving alternative. Open weights mean you get to choose.

Why Does Open Innovation Matter?

Because the referee has to be inspectable.

Dead Drop's entire value proposition is trust: a scoreboard that means something, riddles that are fair, verdicts that can't be gamed. If the referee were a closed black box, you'd have to take my word for it. With open weights, anyone can read the prompts, swap the model, run the whole AI layer locally, and verify the game is fair. That auditability isn't a nice-to-have — it is the product.

It also made the architecture possible on a hackathon budget: no per-seat AI pricing, no vendor lock-in, and a local inference path that runs with zero cloud spend. I built the thing I wanted to exist — and anyone can fork it and run their own city's dead-drop network tomorrow.

My Agent Session

Built with Cursor as the agentic IDE (Grok 4.7, high-effort planning mode) against a written master prompt: strict AI contracts, deterministic safety rules, and a provider-neutral AI adapter came straight out of that spec. No DevRelay session for this one.

Prize Categories

Best Use of Gemma — Gemma writes every riddle and judges every find photo; the served-in-prod / local-via-Ollama setup shows genuine, load-bearing use of the open-weight model.
Best Use of Render — the NestJS backend, the project's AI runtime, is deployed as a Render Web Service.
Best Use of ElevenLabs — the demo video's narration was generated with ElevenLabs.

My Girlfriend Manages Her Family's Health From a Plastic File. I Built Her SehatFile.

Ranbir Singh — Sun, 04 Oct 2026 12:11:32 +0000

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

What I Built

SehatFile — for my girlfriend, who handles all the health stuff in her family.

Every Indian home has a plastic file. Hers holds years of her family's medical reports — different labs, prescriptions in fading handwriting, none of it sorted, all of it important. Before every doctor visit, she's the one spreading it across the bed and digging through it. And then, in the 90-second consultation, the doctor asks the question nobody can answer precisely: "What medicines are they on, and since when?" Recently, the doctor re-ordered the same tests because she couldn't prove they'd already been done. The information existed. It just wasn't organized by person — so it might as well not have existed.

I built it for her.

She photographs each report once — lab slip or prescription, printed or handwritten, English or Hindi. SehatFile reads it, files it under the right person and date, pulls the medicines into a living medication list, and tracks the key values over time. Before the next appointment, one click generates a one-page doctor's brief: the conditions, the current medications, how the numbers have moved, and the exact questions to ask. She prints it and hands it to the doctor. Ninety seconds, finally used well.

I handed it over to her, and in her words, it's "really a lifesaver."

Demo

The demo shows the real thing: a stack of genuine reports from her family's plastic file, photographed and filed; the timeline building up; the medicine list populating itself; and the doctor's brief generating — the same brief she'll carry to the next appointment.

Code

https://github.com/Ranbir5ingh/sehatfile

Public repo, MIT licensed. README covers the one-command setup. The app runs fully offline once the model is pulled — there is deliberately no cloud component, and that's the point (see below).

How I Built It

Stack: Next.js 16 (App Router) + TypeScript + Tailwind CSS — one codebase, no separate backend. All server logic lives in Route Handlers under app/api/. The database is SQLite via node:sqlite — built into Node.js, zero dependencies, a single file on the machine.

The AI core is Gemma, and the architecture is built around a hard rule: no API route is allowed to touch the model directly. Everything goes through a HealthAI interface in lib/ai.ts with exactly two methods — extractReport(image) and generateBrief(record). Two implementations:

MockHealthAI (default) — realistic sample data in the exact same shapes, so the entire app works end-to-end with no model installed.
GemmaHealthAI — calls Gemma via Ollama's /api/generate with JSON mode. Switching providers is one env var: AI_PROVIDER=gemma. Zero code changes.

The extraction prompt is the most carefully written part of the project. Medical data punishes hallucination, so its prime directive is: read only what is actually visible; if handwriting is illegible, say so; never invent a value, a date, or a medicine name. Photos are downscaled client-side before they ever reach the model.

The brief prompt turns the structured record into the one-pager: patient snapshot, current medications, key values over time with trends in plain words, recent changes, and 3–5 specific, data-grounded questions for the doctor — explicitly instructed never to diagnose or suggest doses.

Why Does Open Innovation Matter?

This is the section the whole project stands on, so I'll be direct:

1. This tool cannot exist on a closed API. Nobody uploads their family's heart reports to someone else's server. Health data is the most sensitive data a family owns. A closed model would require piping all of it through a vendor's cloud — which means the families who need this most would never trust it. Open weights running locally aren't my preference here. They're the precondition.

2. Free forever isn't a pricing tier, it's the design. A family files reports for years; a parent's chronic illness is a decades-long paper trail. Per-report API billing would put a meter on the exact people who can least afford one. Gemma on the home computer costs nothing per report, forever.

3. It works where the internet doesn't. Small towns, hospital basements, homes with patchy connectivity — the app doesn't care, because nothing leaves the machine.

4. Multilingual without a pipeline. Indian medical documents mix printed English, handwritten English, and Hindi. An open multilingual model reads all three in one pass — no translation service, no OCR vendor, no extra bill.

5. It's inspectable. The prompts, the schema, the brief format — all in the repo. Any family, any clinic, any student can fork it and adapt the brief to their doctor. That's what open innovation actually means: the tool belongs to the people it serves.

Prize Categories

Best Use of Gemma — Gemma (vision + text, via Ollama) is the entire AI core: it reads the photographed reports and writes the doctor's brief, on-device.