Kshitiz Negi

AI Engineer

Dit Universityfull_time, internship

Open to roles

PythonMachine LearningTensorflowpandas

Queue Cure Live Digital Queue Manager for Clinics

Traditional clinic queue systems are inefficient, paper-based, and lack transparency. Patients experience long wait times with no visibility into queue status, while receptionists manually manage patient flow. Queue Cure solves this by providing a real-time digital queue management platform for both clinic staff and patients. Process The development of Queue Cure began with researching how small clinics manage patient queues and identifying common pain points such as paper-based token systems, long waiting times, and the lack of queue visibility for patients. Based on these findings, the decision was made to build a web-based solution that would allow receptionists to manage queues digitally while enabling patients to track their status in real time. During development, multiple approaches were explored for updating queue information. An initial approach relied on manual page refreshes to display queue changes, but this created delays and provided a poor user experience. To address this, a real-time synchronization mechanism was implemented so that queue updates would instantly appear across all connected devices. Results Queue Cure transforms traditional paper-based clinic queues into a real-time digital system. Patients can track their queue position and estimated wait time from their smartphones, while receptionists manage the queue through a centralized dashboard. The solution reduces manual effort, improves transparency, minimizes waiting-area congestion, and enhances the overall patient experience through instant queue updates. Reflection If given more time, I would enhance Queue Cure by adding appointment scheduling, AI-based wait-time prediction, patient notifications through SMS or WhatsApp, and analytics dashboards for clinics. I would also improve scalability to support multiple branches and larger patient volumes, while conducting user testing with real clinic staff to further refine the user experience and workflow efficiency.

3 media files · figma.comView

IPL Crunch '26: End-to-End Analytics Pipeline & Hypothesis Testing Engine

Analyse real IPL ball-by-ball match data to uncover meaningful patterns, answer cricket-related analytical questions, generate data-backed insights, and communicate findings through visualizations, analysis, and storytelling. Process My analysis began by challenging common cricket assumptions such as “winning the toss guarantees an advantage” and “matches are decided only in the death overs.” Instead of relying on opinions, we treated these beliefs as testable hypotheses using IPL ball-by-ball data. I designed a modular, config-driven Python pipeline rather than a single notebook to ensure reproducibility, maintainability, and cleaner separation between data processing and visualization. Initially, parsing 1,239 raw JSON files on every run took nearly 45 seconds, slowing experimentation and debugging. To solve this, I implemented a PyArrow Parquet caching layer, reducing load time to under one second. To avoid cherry-picked conclusions, we systematically tested eight hypotheses so insights were evidence-backed. Results We analysed 1,239 matches (~300K balls) and generated 12 premium charts. Toss winners win 51.6% of matches, which is statistically insignificant (p=0.263). I chose to report this null result because it refutes the quote, "toss is 50% of the game." Middle overs showed the largest winner/loser gap (Δ=7.8 runs) vs death (Δ=4.1). I chose to emphasize this because it proves games are won in overs 7–15. Shubman Gill leads batters (3,065 runs) and YS Chahal leads bowlers (99 wickets) for 2022–2026. Posting 200+ scores only wins 74.9% of matches (p<0.0001), debunking the "200 is a safe total" myth. Reflection First, I would invest in a schema-validation layer during loading. I initially ran the player statistics engine on the entire historical dataset, returning incorrect all-time leaders. I chose to pivot and hardcode a season list in config because it resolved the 5-season constraint (2022–2026) immediately, but a schema check would have caught it earlier. Second, I would build an interactive Plotly dashboard. I chose static matplotlib charts because they ensure exact print-layout control, but it limits real-time exploration. Finally, I would expand our hypothesis generator from 8 tests to 30.

13 media files · figma.comView

This is Kshitiz’s work on Wooble.

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

Build yours