Fullstack Software Engineer · AI Systems
Abhishek Kumbhar
I build products end to end: the frontend, the APIs and data behind it, and the AI features in between. Mostly React, Next.js, FastAPI, and Postgres.
I build the product and the system underneath it.
Clinical terminology, owned end to end.
I own the backend services behind clinical terminology lookup and validation for two enterprise healthcare clients, from API design through production support, with LLM assistance that knows when to defer to a clinician. I joined as an intern building the document-processing and similarity-search pipelines underneath it.
- 0%+
- Job completion
- 0+
- Records / day
- −0%
- Clinician review queue
- Own backend services for clinical terminology lookup and validation across 2 enterprise healthcare clients: API design through production, PagerDuty incident response, and post-incident reviews (3 systemic fixes).
- LLM-assisted validation on OpenAI APIs with structured-output schemas and confidence-scored fallbacks, cutting the clinician review queue by 23% and catching ~7% of mis-mapped codes before ingestion.
- Celery + Redis async ingestion backing the clinical record API at ~10K records/day and 98%+ completion, with retry orchestration and dead-letter queues.
- Azure Pipelines + Octopus Deploy release flows with automated rollback and validation, cutting deploy time from 45 to under 10 min across 10+ weekly releases.
- As an intern: AWS Textract + Bedrock document processing (3K+ legacy records, ~89% extraction) and a FAISS sentence-embedding similarity search over 10K clinical notes (+29% lookup precision).
Background jobs that page when they break.
Backend automation and scheduled jobs for content delivery and email, hardened so failures surfaced and paged instead of quietly piling up.
- −0%
- Silent failures
- −0%
- Cron on-call pages
- 0
- Recurring workflows
- PHP/MySQL backend automation and cron-scheduled jobs covering 10 recurring content-delivery and email workflows.
- Added retry logic, error handling, and structured logging across jobs, cutting silent failures by 40% and cron-related on-call pages by 50%.
Trading systems, and the dashboards ops lived in.
Backend trading infrastructure across reconciliation, settlement, and risk, plus the internal dashboard that gave ops a real-time view. At that volume, getting correctness and throughput right is most of the job.
- 0+
- Daily transactions
- 0+
- Records / month
- 0
- Settlement queues, live view
- Backend trading workflow services in Python and Java across reconciliation, settlement, and internal banking, handling 2M+ transactions a day.
- Built the internal trade-reconciliation dashboard (Python + SQL views) that replaced daily email reports, giving ops a real-time view across 8 settlement queues.
- Distributed ingestion moving 50M+ market, pricing, and transactional records monthly, improving reconciliation accuracy by 28% and cutting reporting turnaround by 31%.
- Real-time risk monitoring and trade validation with async processing and automated alerting, cutting high-priority validation latency by 41%.
Things I’ve built end to end.
Seven projects I designed and shipped: a scholarship strategy board, an essay-coaching app, a local-services marketplace, a multi-agent workflow tool, a healthcare scheduler, a document-processing pipeline, and a real-time recognition system. Each one runs, schema through UI.
ScholarFit Strategy Board
Turns a matched scholarship list into a ranked shortlist of what's worth a student's time.
- 0
- Priority bands
- 0
- Scoring signals (fit · effort · ROI)
The problem
A matching engine can hand a student dozens of scholarships they qualify for, but the list comes back flat: every row looks equally worth doing. So they sink a weekend into a long shot, or into an award the fine print quietly rules them out of, and skip the ones they'd have won. The matches get them to the options. Nobody tells them where to start.
What I built
A ranking layer that builds on an existing match list rather than replacing it. Given a student profile and their already-matched scholarships, it reads each listing with Amazon Bedrock (Claude Haiku 4.5, forced tool-use for structured JSON) to extract what the sponsor actually rewards and classify the profile against it — strong, partial, or missing. From there the ranking is pure deterministic Python: a weighted-coverage Fit score, an Effort estimate drawn from the listing's real requirements, and a transparent ROI (award, normalized against the set, × fit ÷ effort) — a decision aid, never a fabricated win probability. Hard eligibility gates are read from the prose fine print (degree level, field, heritage, citizenship, first-gen status) that structured matching can't parse, so off-criteria awards are set aside, no-criteria sweepstakes are flagged as lotteries, and a relative 'Start here' surfaces the handful of best bets. It runs on a stateless AWS Lambda Function URL backed by a DynamoDB cache; a React + Vite story SPA walks the funnel (pool → matched → prioritized) and hands the chosen scholarship straight to EssayLens. Live at abhishekkumbhar.com/projects/scholarfit.
Why it matters
The interesting part is the split between the model and the code. The model only classifies: it reads each listing and the student profile and labels how well they line up. The ranking itself is plain Python, so the same inputs always give the same board, with no made-up odds. It sits on top of a matching engine instead of replacing it, never searching or re-matching, catches eligibility rules buried in prose that structured fields miss, and runs on Bedrock and serverless with a working handoff into EssayLens.
EssayLens
See how your essay fits the scholarship you're writing for.
- 0
- Rubric dimensions scored
- 0
- Essay modes
The problem
Students write scholarship and application essays with no real sense of whether their draft lines up with what that particular sponsor is looking for. A grammar checker fixes sentences; it never reads the scholarship's criteria or tells you when you're writing the wrong essay for the award.
What I built
A cross-platform Expo app (mobile + web) with a Flask API on Vercel. Paste a prompt, a draft, and (for scholarships) the sponsor's criteria. Pydantic-validated structured output returns a six-dimension rubric with a radar chart, a scholarship alignment score with sponsor themes (strong, partial, missing), line-level suggestions with tap-to-highlight in the draft, word-limit guidance, and one example paragraph rewrite, never a full essay. Genre-aware prompts cover scholarship, college, internship, and personal essays. Reports save on-device; a revision loop re-analyzes edits and shows score deltas on the gauge, radar, and rubric cards. Live at abhishekkumbhar.com/projects/essaylens.
Why it matters
The focus is sponsor fit, not generic writing polish: an alignment score, themes pulled from the sponsor's own criteria, and coaching questions that keep the student's voice intact. Under the hood it leans on validated model output, a revision loop you can watch improve between drafts, and guardrails that keep it a coach instead of a ghostwriter.
RepairMate
Find a provider, book them, pay, and leave a review, all in one app.
- 0
- Booking lifecycle states
- 0
- User surfaces (customer · admin)
The problem
Booking a trusted local service provider meant scattered listings, no real availability, and no safe way to pay.
What I built
A two-sided marketplace built end to end: a React frontend for provider discovery, booking and reviews on an Express REST API, a PostgreSQL model for users, providers, availability and bookings, JWT auth shared across customer and admin surfaces, geo-radius provider search, and Stripe-backed checkout driving the booking lifecycle (requested → confirmed → completed).
Why it matters
My broadest fullstack build: database schema up through the API to the UI, with auth, payments, and geo search all in one product.
Demo & media
Multi-Agent Workflow Automation
A DAG orchestrator that lets agents do the judgment work, with a human checkpoint and a Next.js console to watch every run.
- ~0%
- Task completion accuracy
- 0
- Agent workflows
The problem
Repetitive review and screening work needs judgment, but not always a human in the loop for every step.
What I built
A LangGraph + FastAPI multi-agent orchestrator with DAG-based execution, Redis task queues, vector memory retrieval, and human-in-the-loop checkpoints, plus a Next.js console for run inspection. It runs resume screening, document analysis, and PR review with structured-output validation and replay-on-failure.
Why it matters
AI agents wired into a working backend and UI, with orchestration, task queues, retrieval, and reliability patterns like replay and structured-output validation.
MedSchedular
Device signals feed a scheduling layer that turns medication timing into patient reminders.
The problem
Medication timing and care reminders are easy to miss, and rarely connected to the devices and signals around the patient.
What I built
An IoT-oriented healthcare scheduling project built around medication timing and connected-care workflows: device and event signals flow into a scheduling layer that builds structured medication timelines and triggers patient-facing reminders and alerts. Kept modular as the hardware and product details firm up.
Why it matters
Product engineering at the point where hardware meets healthcare: device-to-app signals, an event and scheduling layer, and a straightforward patient-facing reminder flow.
Demo & media
Document Intelligence
Upload a document, get structured fields back, and teach it when it's wrong.
- 0
- Pipeline stages (OCR · classify · extract)
The problem
Domain documents (PDFs, scans) had to be read and keyed by hand, with no easy way to correct or improve the model.
What I built
A FastAPI pipeline running Tesseract OCR and a trained scikit-learn / Transformers classifier over uploaded PDFs and images. Upload, classify, and extract endpoints return structured fields with per-class confidence to PostgreSQL, alongside a React upload-and-review UI where users re-label misclassifications, feeding corrections into a retraining set.
Why it matters
An AI-assisted product with the parts that matter in practice: an upload-and-review flow, confidence scores on every output, and a human-correction loop that improves the model over time.
Demo & media
Face-Recognition Attendance
Sub-second recognition from a live webcam, with a manual fallback when it's unsure.
- <0s
- Identification latency
The problem
Manual attendance was slow and error-prone; automated capture had to be fast and trustworthy.
What I built
A JavaFX/JFoenix desktop app for enrollment, live capture and session review, bridged to a Python (dlib) recognition service over structured subprocess I/O, with confidence-threshold gating, a manual-entry fallback, MongoDB persistence, and exportable session rosters.
Why it matters
A real-time system spanning a desktop UI, a Python ML service, the IPC between them, and a datastore, with practical touches like confidence fallbacks and roster exports built on top of the computer vision.
Demo & media
Things I built outside the web stack.
Hardware I assembled and low-level graphics I wrote from scratch, mostly to understand how things work a layer down.
Pixhawk Drone, built from scratch
Assembled and configured on a Pixhawk flight controller: wiring, calibration, and real flight. Flown at the inauguration of a Women Entrepreneur event during my Bachelor's (~2020).
PixhawkFlight controllerAssemblyCalibrationRobo Soccer, competition robot
Built during my Bachelor's for a Robo Soccer competition: mechanical assembly, control logic, and movement behavior. Early hands-on robotics and practical problem-solving.
RoboticsControl logicMechanical assembly
Ganpati Bappa, Win32 in C
Native Windows graphics from scratch: the message loop, GDI primitives, and coordinate systems, hand-rendered in C.
CWin32 SDKGDI
Independence Day, Win32 in C++
A themed scene built with native Windows APIs and hand-composed geometry, down to the low-level rendering fundamentals.
C++Win32 SDKGDI
Base Converter, Win32 desktop
A small native utility: numeric base conversion wired up with raw Windows controls and low-level UI code.
C++Win32 SDK
How the stack fits together.
Frontend
Web and mobile interfaces, from a marketplace UI to a cross-platform essay coach.
Connects with
Let’s talk.
I’m based in Chicago and open to relocating.