Srivalli Katyayani

Full-Stack Developer

Vignans Foundation for Science Technology and Researchfull_time, internship, freelance

Open to roles

Problem Solving

BudgetBuddy – Student Expense Tracker

College students juggle UPI payments, canteen bills, recharges, and travel costs with no simple way to see where money goes. Most expense apps need installation, internet, or sign-up — overkill for a quick daily check. Students need a zero-friction tool that works offline, starts instantly, and answers one question fast: am I going to run out of money before month-end? I built a command-line tracker with zero setup, since most students already live in a terminal for coursework and don't want another app eating storage or asking for data. Process I started with the four required features (add, view, total, top category) using lists of dicts as the brief required — no database. First pass had a flaw: any bad input (wrong date format, non-numeric amount) aborted the action and dropped the user back to the main menu. I tested this by deliberately entering garbage into every prompt and found it broke the experience fast. I rebuilt input handling so every field loops until valid instead of failing once. I also wrapped the main loop in a try/except for Ctrl+C and EOF, since a raw traceback looks broken even if the logic is fine. For the bonus, I went beyond a simple budget check: spending now ties back to the top category with a 0-100 health score, so the warning explains itself instead of just flashing a number. Results Tested 6 edge-case scenarios end-to-end: invalid dates, non-numeric amounts, wrong categories, invalid menu choices, and Ctrl+C/EOF mid-input. Result: 0 crashes across all 6 — every case now re-prompts cleanly instead of throwing an error. Feature count went from the 4 required to 8 total (4 core + 4 insight-driven additions: percentage breakdown, category ranking, budget health score, and a recommendation that reads real data instead of a hardcoded string). Next time I would add CSV persistence so data survives between runs. Reflection I'd add CSV persistence first — right now data resets every time the program restarts, which is the most obvious limitation for real daily use. I'd also expand categories beyond the four listed in the brief (e.g. entertainment, shopping) since real student spending doesn't fit neatly into four buckets. Given more time, I'd write actual unit tests instead of manually scripting input sequences to check for crashes — manual testing worked here, but it doesn't scale as the feature set grows.

9 media filesView

The FlowPilot Sprint : 110 Strangers, 10 Days, 6 Opportunities

FlowPilot had zero brand recognition with a 110-person cold list spanning startup founders, ops leaders, agency owners, lapsed trial users, and referrals. I had 10 days to generate qualified demo opportunities. The real problem wasn't volume — it was that equal-effort contact is mathematically irrational. At ~25 minutes of real effort per prospect, I could only deeply engage 40-50 people well. Without prioritization, a lapsed trial user with existing trust gets the same generic email as a cold founder who'd never heard of FlowPilot, and follow-ups decay unmanaged. Process I built a 5-factor scoring model (ICP Fit, Buying Authority, Warmth, Reachability, Urgency Signal), scored all 110 prospects out of 100, and split them into Hot/Warm/Cold tiers. I weighted Warmth highest (30 pts) on purpose: in 10 days, trust is scarcer than fit, so a mediocre-fit prospect who'd trialed FlowPilot beat a perfect-fit stranger. Each tier got a different outreach motion — 1:1 email + LinkedIn for Hot, a lighter sequence for Warm, templated low-touch nurture for Cold. I scripted a discovery call flow and 3 objection responses before any calls happened, and tracked every touch in a CRM with live formulas. What didn't work: my first Hot/Warm cutoff was an arbitrary round number; I rebuilt it after the actual score distribution showed a natural gap at 75. Results 110 of 110 prospects scored and tiered. 96 (87%) got at least one outreach touch. 11 discovery calls scheduled, 6 qualified opportunities generated — all 6 from Previous Trial Users, only 18% of the list. That segment converted at roughly 6x any cold, perfect-fit segment. Average score: 67.9/100. The clearest result: trust compressed the sales cycle more than fit did. Agency Owners and Ops Leaders, despite strong fit scores, produced zero qualified opportunities in 10 days. Reflection I'd add firmographic data (funding stage, headcount, tech stack) before scoring instead of relying on title and segment alone — it would sharpen ICP Fit significantly. I'd also test more than one message angle per tier; right now one template serves very different readers (a founder and an ops director aren't the same person). Most importantly, I'd investigate why Agency Owners and Operations Leaders converted at zero despite good fit scores, before running another sprint on the same list — that gap is more valuable to understand than any single win.

7 media files · 1drv.msView

QueueDoc — Real-Time Clinic Queue & Token Management System

76% of India's 1.5M clinics still run on paper tokens, leaving patients waiting 2-3 hrs with zero queue visibility. A clinic seeing 40-60 patients/shift faces dozens of "how long now?" interruptions hourly, pulling staff off real queue work. Consultation times vary 2-3x per patient, so flat-average wait estimates are wrong for most of the queue. Existing token systems solve issuance, not the harder problem: syncing two live screens with zero refresh while staying accurate as urgent cases, delays, and no-shows reshape the queue live. QueueDoc solves exactly that. Process Worked backward from 3 constraints — sub-10s check-in, zero-refresh sync, real wait-time math — not features first. Architecture: Node/Express + Socket.io over MongoDB, so state survives a crash. Tokens use an atomic MongoDB counter ($inc) — zero collisions across concurrent check-ins. Wait time: rejected flat (people x avg) math since pace isn't constant. Built an Exponential Moving Average over the last 5 consultations, recalculating within ms of any change. Concurrency: two tabs clicking "Call Next" within ~100ms caused a race condition. Replaced an in-memory flag with a DB-level atomic update (findOneAndUpdate + status check), removing double-advances. Bug found in testing: delay broadcast updated the banner but not wait times — caught by testing against a populated queue. Results Receptionist check-in completes in under 2 seconds per patient — 5x faster than the 10-second target. Both screens update with zero manual refresh, confirmed under repeated concurrent multi-client testing with 0 duplicate or skipped tokens. Wait-time estimates run on a live 5-consultation rolling average rather than a static guess, recalculating within milliseconds when an urgent patient is inserted or a delay is broadcast — verified via the audit trail's timestamped event deltas, showing token-call gaps as low as single-digit seconds during live testing. Reflection My race-condition fix uses a single-instance DB-level atomic lock — correct for one server process, but it wouldn't hold across multiple instances behind a load balancer, since the lock isn't distributed. With more time, I'd move to a Redis-based distributed lock for real production scale across multiple front desks. I'd also convert my manual concurrency tests into automated load tests with more simulated clients, and pilot the receptionist flow with one real non-technical user — every test so far has been run by me as the developer, so I likely can't see friction a first-time user would hit.

8 media files · queuedocc.onrender.comView

This is Srivalli’s work on Wooble.

Build a profile that shows what you can do — and share it anywhere.

Build yours