From first commit to paying customers.

The part of onedash that runs AI. A merchant asks for something in chat; an agent turns it into a command, waits for approval when the action matters, and hands long model work to a durable workflow that survives failures.

Problem

Model calls are slow, cost money and sometimes fail halfway. A retry that pays for the same generation twice, or an agent that changes a live store without asking, is a bug the merchant pays for.

How it works

• Chat to command. Every request becomes an agent command with a receipt, so there is always a record of what was asked and what was done.
• Approvals. The merchant approves each action, or gives a standing approval for a kind of action within limits they set.
• Durable workflows. Long jobs are split into parallel parts, each kept under the provider’s 120-second timeout.
• No repeated paid work. Every run carries an idempotency key and keeps its state in PostgreSQL, so a restart resumes instead of starting over.
• Queues and audit. Work moves through an outbox to SQS workers, and every step writes audit events.

Chat messagemerchant asks

→

Agent commandwith a receipt

→

Approvalask or standing

→

Workflow rundurable job

→

Resultaudit events

My part

Designed the runtime across checkpoints CP-09 to CP-19 in Sep 2026, each closed with a handover and an audit, then wrote the services, the skill catalogue and the tests.

Outcome

Running on onedash staging behind the editor’s chat and the store agents.

139unit tests

16integration tests

14live API checks

32skills at launch

Built with

PythonPostgreSQLSQSAWS ECSself-hosted models

My master’s thesis at IIT Roorkee, supervised by Prof. S. K. Gupta: how much stock to order when demand keeps changing and the past is only a rough guide to the future.

Problem

Classic inventory policies assume demand follows a known distribution. When demand drifts or jumps, a policy fitted to the average does fine on typical days and badly on the worst ones, which is where stockouts and write-offs come from.

How it works

• Learn from a window. A rolling window of recent demand forms the empirical distribution D̂_t, updated every period.
• Guard the neighbourhood. The order minimises the worst expected cost over every distribution within a Wasserstein distance ε_t of that window.
• Shrink with evidence. The radius falls as data grows, ε_t = ε₀ / √|D̂_t|, so the policy is cautious early and confident later.
• Stress tests. Simulated against three adversarial shifts: ambiguous growth, push shocks and contaminated demand, compared with a non-robust baseline.

x_t+1 = x_t + q_t − d_t  ·  ε_t = ε₀ / √|D̂_t|

My part

The formulation, the streaming algorithm, the simulation code and every experiment.

Outcome

Tail cost (P95) fell in all three settings for a small rise in mean cost: robustness costs a little on an average day and saves a lot on a bad one.

−7.73%P95 cost, ambiguous growth

−5.44%P95 cost, push shocks

−2.21%P95 cost, contaminated demand

+1.3–2.2%mean cost, same settings

Built with

Pythonconvex optimisationsimulationstatistics

A healthcare assistant built at MDG Space with Ananya Krishnan: one chat window with three specialist bots behind it, for first aid, mental health and general diagnosis.

Problem

People look up symptoms, first aid or mental-health help in a hurry and get generic search results. And a message that signals a crisis should reach a person who can help, not just a chatbot reply.

How it works

• First aid. TF-IDF matching over a curated set of first-aid answers.
• Mental health. Sentence embeddings (all-mpnet-base-v2) match each message to an intent; when a message signals distress, Twilio alerts a close contact’s phone.
• Diagnosis. A medical knowledge graph in Neo4j. Aho-Corasick dictionaries find diseases, symptoms and departments in the question, a classifier picks the question type (cause, symptom, treatment, prevention, who is at risk) and a graph query answers it.
• The app. A Flask server, Firebase sign-in, and chat sessions saved with timestamps.

My part

Built it with Ananya Krishnan, across the three bots, the knowledge graph and the server.

Outcome

A working assistant that answers from a graph instead of guessing, and escalates distress to a real person.

2,675graph nodes

8,257graph edges

0.93F1, crisis classifier

98.1%150-query benchmark

Built with

PythonFlaskNeo4jSentence TransformersTF-IDFTwilioFirebaseJavaScript

Upload your documents, ask questions in chat, and get answers drawn from the pages themselves instead of from what a model happens to remember.

Problem

A general chatbot answers from its training data, not from your documents, and it makes things up with confidence when it doesn’t know.

How it works

• Sign-in. Firebase Auth; every API call carries a token checked by the Firebase Admin SDK.
• Indexing. PDFs go to Firebase Storage; their text is extracted page by page and indexed in Weaviate with the title, owner and page number.
• Answering. A question becomes a vector search over that user’s documents only, and the closest passages go to a Groq-hosted model.
• Honest fallback. If nothing close enough is found, or the question is unclear, it says so instead of guessing.
• Housekeeping. Deleting a document removes the file and its vectors; chats are kept as sessions.

My part

Built it end to end: the React frontend, the Python API, indexing and retrieval.

Outcome

Answers grounded in the user’s own pages, with each user’s documents kept apart.

Built with

ReactTypeScriptPythonFirebaseWeaviateGroq

A small tool: paste a YouTube link and get the whole transcript as plain text, ready to read, search or paste into notes.

Problem

Getting what was said in a long video means scrubbing through it or copying captions line by line.

How it works

• Frontend. React, TypeScript and Tailwind, one screen.
• API. A Flask endpoint reads the video ID from both youtube.com and youtu.be links and fetches the captions.
• Clear errors. An invalid link, a video with captions turned off and any other failure each get their own message.

My part

Both halves, frontend and backend.

Outcome

Transcripts of long talks and lectures in seconds.

Built with

ReactTypeScriptViteTailwindPythonFlask

Wordle rebuilt in React, with one addition: players can add their own five-letter words to the pool.

Problem

A small exercise in game state that has to agree everywhere: the guesses, the colour of each letter, and the keyboard.

How it works

• Grid. Six guesses, each letter scored green, yellow or grey, with repeated letters handled correctly.
• Keyboard. Keys take the best colour known for that letter so far.
• Custom words. New words are checked for exactly five letters, A to Z, before they join the pool.

My part

All of it.

Outcome

A playable game that friends could load with their own words.

Built with

ReactTypeScriptViteTailwind

An image classifier that sorts ovarian cancer tissue images into subtypes. My first computer-vision project.

Problem

The subtype guides treatment, and reading slides takes a specialist’s time. Slide images are huge, stained differently from lab to lab, and some subtypes are rare.

How it works

• Tiles. Large slide images cut into tiles, keeping only those with tissue.
• Model. A pretrained convolutional network fine-tuned on the tiles, with flips, rotations and colour changes so stain differences don’t fool it.
• Imbalance. Class weights so rare subtypes count.
• Per image. Tile predictions combined into one answer per image.

My part

The whole pipeline: preprocessing, training and evaluation.

Outcome

A reported accuracy of 88.45%.

Built with

PythonPyTorchCNNOpenCV

A Kaggle competition run by Optiver: predict how Nasdaq-listed stocks move during the closing auction, the last ten minutes that set each day’s closing price.

Problem

Closing prices matter to everyone who trades, and the auction is short and noisy. The task: predict each stock’s move against an index over the next 60 seconds, from the order book and the auction book.

How it works

• Features. Order imbalance, bid and ask sizes, weighted prices, spreads, and how each changed over recent seconds, per stock.
• Models. Gradient-boosted trees.
• Validation. Split by time, never at random, so the model never sees the future it is predicting.

My part

Feature engineering, models and validation.

Outcome

A weighted MAE of 0.0735, and a lasting habit of checking for leakage first.

Built with

PythonpandasLightGBMNumPy

An Android app for personal safety, built at MDG Space in late 2022: help is one hard shake away, even when there is no time to unlock the phone and find a button.

Problem

In an emergency, opening an app and navigating menus takes time a person may not have.

How it works

• Shake to open. A background service watches the accelerometer; a hard shake, over twice the force of gravity, brings the app forward at once.
• Starts with the phone. It runs again after a restart, so protection doesn’t depend on remembering to open it.
• Evidence. Camera and microphone access to record what is happening.
• Help and information. Emergency, Help, Information and Services screens for helplines and next steps.

My part

Wrote the app in Java with another MDG member: the shake-detection service, navigation and screens.

Outcome

A working prototype, and the first time I wrote software for a real safety problem.

Built with

JavaAndroid SDKsensorscamera

Upload a photo of an outfit and find pieces that look like it, or go with it.

Problem

People see a look they like but can’t name the pieces, and text search doesn’t work for style.

How it works

• Find the items. YOLO detects and crops each piece of clothing in the photo.
• Describe the style. A CNN turns each crop into an embedding of its colour, pattern and cut.
• Match. Nearest-neighbour search finds similar pieces, and pairs seen in complete outfits suggest what goes together.

My part

The detection and embedding pipeline.

Outcome

A prototype that turns a photo into a set of matching pieces.

Built with

PythonYOLOCNNPyTorch

A tool for competitive programmers that runs C++ one line at a time and shows what each line does to variables, arrays and the call stack.

Problem

When a solution fails on a hidden test, most people debug with print statements. Watching the state change line by line finds the bug faster, and makes recursion and data structures easier to learn.

How it works

• Trace. The program is compiled with debug information and stepped through a debugger, recording variables and stack frames at every step.
• Replay. The steps can be played forwards and backwards, with the current line highlighted.
• Draw. Arrays and recursive calls are drawn as they change.

My part

The execution tracer and the step-by-step view.

Outcome

A visual debugger for contest-style programs.

Built with

C++GDBJavaScript

Questions I followed far enough to learn something, without turning them into products.

Media generation

Compared image and video generation providers on quality, speed and cost, and the post-processing an output needs before anyone can use it.

Transfusion support

A concept note, prepared with a transfusion-medicine professor, on software to support transfusion decisions: what data it would need, where it could help clinicians, and where it must not decide for them.

Maths evaluation

Image-based mathematics problems, such as maximum flow on directed networks, written to test whether a model can read a diagram and solve it correctly.