Durgesh Kumar
Full-stack developer and founder building real-world product
New to Contra
Durgesh is ready for their next project!
During my internship at Neosophical Labs, I single-handedly built Sabse Bada Fan (https://sbf.ahoum.com/)(SBF), a live multiplayer quiz game, taking it entirely from an initial idea to a fully launched application. I designed the system to handle over thousands of people playing at the exact same time without slowing down, and I made sure the live leaderboards update instantly for everyone. To make the game accessible everywhere, I integrated Capacitor to seamlessly package the web platform into native Android and iOS mobile apps. Finally, I built an automated background system that perfectly runs our scheduled live quizzes and handles all the scoring completely on its own without any human effort.
0
1
I built this because I was annoyed.
I was paying monthly for a study library seat, and I still couldn't reliably tell if a seat would be free when I showed up. No way to check online, no way to book ahead just calling around or walking in and hoping. I figured if this was frustrating me, it was frustrating thousands of students across India who rent library/reading-room seats the same way.
So I built Studoo (https://studoo.aithro.in/)and Padhloo (https://padhloo.aithro.in/)two connected products at Aithro (https://aithro.in/products)-
Padhloo (student side): search study spaces by city/price/amenities, see a live seat map, request a specific seat for 1-12 months, and track your bookings, dues, and payments in one place. It also gamifies actually showing up — QR check-in/out, study streaks, points, badges, a leaderboard — so students stay consistent, not just book-and-forget.
Studoo (owner side): the dashboard library/reading-room owners use to list their space, manage seat inventory and pricing per slot, approve or reject booking requests, chase due payments automatically, and see real analytics (occupancy, revenue, which slots to reprice). Free tier + two paid plans. You can see product demo video here - https://youtu.be/9Yex73MIYqQ?si=jfWqLxisRTM9N_28
I designed and built the full product end-to-end — the booking/approval workflow, the seat-and-slot inventory model, the QR-based geofenced attendance system, the payments/dues tracking, the subscription tiers, and the whole gamification layer (points, streaks, badges) on the student side.
Where it stands:
Got our first paying customer, a real library owner in Patna paying for the Growth plan, which is the moment this stopped being a side project and started being a business.
Reached the Grand Finale of Empresario 2026 (IIT Kharagpur E-Cell), selected out of 3,000+ global registrations.
Won the Platinum Jubilee Innovation Challenge (Deep Tech) at IIT Kharagpur's 75th anniversary event.
What I'm good at, based on building this: turning a messy real-world workflow (owner approves seat → student pays offline → both sides need to trust the same numbers) into a system that's simple enough for a small business owner with no tech background to actually use — while still handling the edge cases (partial payments, overlapping slots, expiring bookings, geofenced check-ins) correctly under the hood.
If you're a small business or founder who needs a web app or an AI-automation workflow built and shipped fast, not just prototyped that's exactly the kind of problem I like solving. Happy to talk about your project.
0
3
Project: AuRizz (ControlPlane.ai (http://ControlPlane.ai)) — a responsible-AI gate for enterprise LLMs
Built for the Accenture Innovation Challenge (Round 2), this one tackles a problem most companies rolling out AI don't think about until it bites them: if you're running several different LLM-powered features at once — a customer support bot, an internal knowledge assistant, a tool inside a regulated decision workflow — each one needs a completely different level of scrutiny. A support bot can tolerate more risk and needs to respond fast; a regulated decision-support tool needs to be slow, careful, and willing to hold a response for human review rather than guess.
AuRizz is a middleware layer that sits between an enterprise's LLM provider and its users and decides, per use case and in real time, whether a generated response should go through as-is, get redacted, get held for a human, or get blocked outright.
What made this a genuinely hard build, not just an API wrapper:
Policy-driven, not hardcoded. Every behavioral difference between use cases, which checks run, their thresholds, what happens on failure lives in YAML config, not in application code. Switching a deployment's risk posture is a config edit, not a redeploy.
Confidence as a first-class signal. Every check returns both a risk score and a confidence in that score — a high-risk-but-unsure reading routes to human review instead of auto-blocking, which is the actual fix for alert fatigue.
Multi-provider by design. Works with Anthropic, OpenAI, Gemini, or Groq behind one interface, with automatic runtime fallback if a provider fails -switching providers is a one-line config change, not a rewrite.
A real audit trail. Every decision is written to a hash-chained, tamper-evident log, and human overrides are appended as new records rather than edits — so the fact that the system said block and a human said allow is preserved, not erased.
Built to be tested. 104 tests run the full pipeline — detectors, aggregation, decision rules, the audit chain — with no network calls or API keys required, because everything is built against interfaces, not vendor SDKs directly.
I worked on this with a teammate, I focused on architecture, pipeline and ai integration parts, and we split the detector logic, policy engine, and audit system between us.
Stack: Python, FastAPI, React, TypeScript, Pydantic, SQLite, multi-provider LLM integration (Anthropic/OpenAI/Gemini/Groq)
Status: this is a working prototype, not a deployed product — the source is public and the full pipeline runs locally with real API calls or offline in the test suite, but it hasn't been hosted or put in front of real traffic yet.
If you're building anything where AI output needs a guardrail — content moderation, compliance-sensitive automation, multi-agent systems that need oversight — this is exactly the kind of system design problem I enjoy.
0
8
SpeakYield - voice-first agri-commerce platform for Indian farmers
This one came out of a government hackathon problem statement, but the problem itself is real and ugly: a smallholder farmer in Maharashtra selling onions knows yesterday's price at exactly one mandi, usually from the same commission agent who's also buying from them. They can't see the market 40km away, can't see what a processor or exporter would pay, and often sell right after harvest at the seasonal low because they need cash now, not because it's the best time to sell. Every step of that chain - price, buyer trust, quality grading, transport, payment - quietly leaks money out of the farmer's pocket.
I built SpeakYield to close that gap, and built it voice-first because the people this is for often can't or won't use a text-heavy app. A farmer can literally say "I want to sell 12 quintals of onion, I need ₹40,000 right now" in Marathi/Hindi, and the app:
Parses that into a structured request and reads it back for confirmation before anything commits - nothing moves on a guess
Shows every nearby buyer's price as net-in-hand, after transport, commission, and fees - not the misleading headline mandi rate
Recommends sell-now / split / hold based on the farmer's actual cash need, not just a price chart
Ranks competing buyer offers by what the farmer actually banks, weighted by the buyer's payment-reliability history
Runs the full deal lifecycle — offer, logistics, milestone payments, dispute filing — on one transparent, tamper-evident record
What I built: the full stack — Next.js/TypeScript frontend, FastAPI backend, the voice pipeline (speech-to-text → LLM intent parsing with strict schema validation → text-to-speech read-back), the buyer-matching and net-price ranking engine, and the deal/ledger system. Solo project, ~12 commits from architecture to a working two-sided prototype (farmer view + buyer view), with CI, linting, and end-to-end tests.
Stack: Next.js, TypeScript, FastAPI, Python, LLM-based voice intent parsing, PostgreSQL/Redis (production design)
I like this kind of problem specifically because it's not "build a CRUD app" — it's translating a messy, high-stakes, low-trust real-world transaction into software that has to work for someone with a ₹6,000 phone and patchy network, not a power user.
If you need someone who can take a genuinely fuzzy problem (multi-party trust, real-time matching, voice/AI interfaces) and turn it into a working product fast, that's exactly this.
0
12