Skip to content
Applied AI + Full-Stack EngineerMumbai, IN2026

Applied AI engineer, 3+ years in production

I run LLM systems in production, and I build the whole product around them.

Right now that is EdTech. The analyser I built takes the first pass on around 5,000 student submissions a month, and I measure it against teacher judgement instead of assuming it is right — it agrees 7 times in 10 today, and no prompt, model or model-setting change ships until it clears that number. My team builds ten products across 117 schools, and four of them are entirely mine — frontend, backend, the database under them, the deploy, and whatever breaks in production afterward.

Frontend to deploy — hover to trace a layer

I OWN
The LLM layer and the full stack under it — 4 of 10 apps
BASED
Mumbai, open to relocating

Experience

Two jobs so far. The first was a video platform for creators in Bengaluru. The second is EdTech, where I am now.

Selected Work

These six are mine — I was the only engineer on each one. A few share a stack on purpose, so the thinking went into the problem and not into choosing tools again. Open the claims engine first if you only open one: there is no model anywhere near the part that decides the money. Where something started as a take-home or a hackathon, the card says so.

Feature 01Full-stack · Personal toolLive2026

AI Résumé Builder

Rewrites a résumé for one particular job advert, showing every change side by side before anything is exported.

Role
Frontend, API, tests, deploy.
Challenge
A résumé written for everything speaks to nobody. Rewriting it by hand for every job takes forever, and a model left alone will quietly change formatting you needed kept.
Key decision
The model has to return the résumé in one fixed shape — if it returns anything else, the app rejects the answer outright, because a quietly broken résumé is worse than no résumé at all. I also show every change next to the original instead of applying it automatically. That is slower, but the person still owns what their résumé says.
Outcome
The tests drive the real app in a browser with the model’s answers faked, so they check my code, not the model’s mood that day. Deploy only happens if they pass on that same commit. I use this for my own job applications.
Fig.01 — review before exportupload → rewrite → compare → PDF
Next.jsTypeScriptFastAPIGemini APIPlaywrightCloud Run
Feature 02Full-stack · Take-home, no brief given2026

RTO Shield

Rings a customer with an AI voice call to confirm a cash-on-delivery order before the parcel ships, so the seller is not left paying shipping both ways when it is refused at the door.

Role
I wrote the problem statement, picked the users, picked the stack.
Challenge
When a customer refuses a cash-on-delivery parcel, it travels back to the seller, and the seller pays for both legs of the trip. The trade calls this a return to origin, RTO. Nobody had asked the customer first.
Key decision
The phone service reports the same call more than once — early, again once the details land, and again if an operator pulls the record. I sent all three down one handler keyed on the call ID, so one call produces one outcome and the parcel only ships after a real confirmation arrives. I also kept the database swappable, so the tests run against a fake one held in memory while the live app runs on Firestore. That is one more piece to maintain, and it buys a test run that finishes in seconds.
Outcome
Send the same call result twice and the second one is logged as a duplicate instead of applied again. That case is a test, and a push that fails it does not merge. Every order in it is one I made up for testing. No real orders have gone through it, and I am not going to claim otherwise.
Fig.02 — one call, one outcomeorder → call → match → ship
FastAPIPythonNext.jsBolnaFirestoreDockerGitHub Actions
Feature 03Backend · Take-home2026

Claims Adjudication Engine

Works out what a health insurance claim should actually pay, and keeps a record of that decision which can be added to but never edited.

Role
Sole engineer. Calculation, API, database, tests.
Challenge
A claim has to be checked against a policy, then reduced by the deductible, the copay and the yearly limit, in that order. Get one step wrong and the payout is wrong. There is no partial credit on money.
Key decision
I kept the money maths as plain Python with nothing from the web framework touching it, so every rule can be tested directly instead of through an API call. That meant writing more setup code by hand rather than letting the framework carry it. Saving a claim and all its line items happens in one database function, so either the whole claim is written or none of it is.
Outcome
There is more test code in it than application code, which was deliberate on the part that decides money. The tests run from the rules on their own all the way through to checks against a real database.
Fig.03 — one calculation pathclaim → rules → amount → record
FastAPIPythonPostgreSQLSupabasepytest
Feature 04Full-stack · Personal project2026

Intervue

Lets someone book a mock interview using credits, sit it on a video call, and read written feedback once they hang up.

Role
Booking, credits, video, feedback, deploy.
Challenge
Practising interviews needs a real person on the other side, and the people who need the practice most are the least likely to know one. Feedback afterward is the whole point, and it rarely arrives in writing.
Key decision
The call writes its own transcript, and that transcript goes to Gemini to come back as written feedback. I tied that step to the booking rather than to the message that triggers it, so if the same message arrives twice it updates the same booking instead of paying the interviewer a second time. Each service checks the login for itself rather than trusting whatever called it, and booking and withdrawal are both capped per person.
Outcome
The deploy builds the image, starts it, and waits for a real answer from it before anything rolls out, so a broken build never reaches anyone.
Fig.04 — credits to feedbackbook → call → transcript → feedback
Next.jsFastAPIClerkPrismaStreamGemini APICloud Run
Feature 05Frontend and AI · Personal toolLive2025

LinkedIn Hashtag Refresh Engine

Takes an old LinkedIn post, drafts three fresh sets of hashtags aimed at different kinds of reach, and posts the chosen set as a comment.

Role
Frontend, model prompts, login handling, deploy.
Challenge
A post stops travelling once its hashtags go stale. Reposting it looks desperate, so the reach is simply lost.
Key decision
I first tried to read the post automatically. It kept breaking, and the fix that would have held cost money, so I dropped it and let people paste the text in instead. The login turned out to be the real work: LinkedIn expires it every 60 days, so I wrote that renewal by hand, with a fallback that flags the failure rather than silently retrying.
Outcome
Failures report to one place, so a broken login shows up as an alert instead of a confused user. Reading the post automatically is still not in it.
Fig.05 — paste, pick, commentpaste → 3 sets → pick → comment
Next.jsNextAuthGemini APIZodSentryDocker
Feature 06Full-stack · Hackathon · 3 hours2026

Financial Literacy Assistant

Explains budgeting, saving and investing to someone who has never done any of it before.

Role
Built alone, in one sitting.
Challenge
People starting from zero get advice full of terms they do not know, and the numbers in it are rarely explained.
Key decision
Every number is worked out in ordinary code, never by the model. The model only handles the wording. So if it is down or slow the explanation changes but the maths does not, which was worth more to me in three hours than a smarter answer that could quietly be wrong.
Outcome
The calculation code is tested on its own, away from the wording the model writes. It went on Cloud Run for the judges.
Fig.06 — maths outside the modelinputs → maths → wording → plan
Next.jsSupabaseGemini APIVitest

Open source

I have been on both sides of the same programme inside a year — a contributor in January, a mentor from June. Mentoring turned out to be the harder job.

About

Toolkit

The tools I reach for most, listed plainly, with no ratings and no percentages.

LANGUAGES — Python · TypeScript · JavaScript · SQL

Tell me what you are building