Skip to content
Full-Stack + AI EngineerFull-stack + AIMumbai, IN2026

Software engineer, 3 years in production

I design the database, write the API and the app, and put it live myself.

Right now that is school software my team builds, used by teachers in 117 schools. I own the API behind four of its apps and the database under all four, and I built the teacher coaching Android app on my own, from the first question about what it should do to the release.

View selected workGet in touchRésumé ↗

Index

01Experience02Selected Work03Open source04About05Toolkit06Contact
I OWN
The API and database behind 4 apps
I BUILT
The teacher coaching Android app
BASED
Mumbai, open to relocating

Experience

Two jobs, three years between them. The first was a video platform for creators in Bengaluru. The second is the school software I work on now.

Nov 2024 — Present

Shikha Learning Labs

Software Engineer
Shantilal Shanghvi Foundation
EdTech · Mumbai, India

Shikha Labs builds Sakhee, an AI tool for schoolteachers — planning a lesson, building an assessment, seeing how a class is doing. I am one of the engineers on it. The four apps I look after are web and Android, and a change to one table is a change all four have to live with, so that database gets argued about before it gets written. Two peer-reviewed papers have been published on this work: one on the history chatbots (CELDA 2025), and one on how the platform was designed with teachers (Springer CCIS 2026). My colleagues wrote them, including our founder and my own product manager. My part is the engineering.

  • I built the Android app for the AI Teacher Coach and took it to the Play Store myself, from working out what it needed to do through to testing it with teachers. About 200 teachers record around 400 classes a week on it. Before this, assessing how a teacher taught meant a mentor sitting through the whole class: a sixty-minute class cost a mentor sixty minutes, and it happened only when a mentor was free. The feedback now comes back in five to ten minutes, with nobody in the room.
  • I built the portfolio portal alone, web and Android, start to finish. 300+ students keep a public website of their best work on it, and an AI assessor reads the finished portfolio and reports on how their skills are developing, quoting their own work as evidence. A submission that fails retries on its own, and a job that runs twice saves the result once rather than twice.
  • Two pieces of Sakhee are mine and I wrote both on my own. One is the school calendar — terms, holidays, timetables — which I later moved into its own service, so the rest of the platform asks it instead of every app keeping its own copy of the dates. The other is the Google Drive link: a teacher’s files sync both ways with every version kept, and while they are still typing it waits for a pause before saving. An hour of editing leaves one version, not forty. The build and deploy pipelines for our four services are mine too.
  • A state authority is having a platform built to check school quality, and three of us built it. I built the front end: signing in, the different dashboard each kind of user sees, forms that save as you fill them so a bad connection does not cost an hour of work, a calendar of what is due, and the school report pages. A colleague wrote the part that does the scoring.
  • In schools where the connection drops several times a day, class recordings were going missing. The recording now saves on the phone first and uploads once the signal returns. A second problem was quieter and worse: on Android, unsaved audio was being deleted without anyone noticing, so nobody reported it, because nobody knew it had happened. Recordings were not failing to upload — they were gone before the upload was ever attempted. I traced it, and every file now has to prove it exists before anything writes over it.
  • I build whole products on my own here as well. The institute’s new website is mine end to end, still in development: 14 pages and an admin area where staff edit their own content, with a draft kept separate from what the public sees so a half-finished edit never goes out. There is a second one, a content platform for a state education department, where I am the only engineer.
Next.jsReact NativeFastAPIPostgreSQLRedisIndexedDBMicroservicesMonorepo

May 2023 — Sep 2024

Nuveb

Full-Stack Developer
Open OTT network for creators
Bengaluru, India

I built the creator side of a video platform: video, scheduling and payments, on Next.js and TypeScript over a Go backend. Much of the work was making pages that already worked load faster.

  • Pages were taking 8.5 seconds to load for 50,000+ visitors a month. The browse pages were rebuilding themselves on every request, for content that barely changed. I moved those to pre-built pages, keeping the rebuild only where the page was personal to the user. Load time came down to 2.5 seconds.
  • I profiled the image requests, which were sitting at 3.2 seconds across 10,000+ items, and the resizing step was the cost. Moving that work to the server brought them to 1.9 seconds.
  • The platform went from no creators to 10,000+ while I was there.
Next.jsTypeScriptNode.jsGo microservicesSharpReact Native

Selected Work

These six are mine. I was the only engineer on each one. Several share a stack, and that is on purpose, so the new thinking went into the problem instead of the setup. The claims engine is the one I would open first: there is no model anywhere near the part that decides the money. Where a project 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 is slow work, and a model left to itself will quietly change the formatting you needed it to keep.
Key decision
The AI has to return the résumé in one fixed structure. 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 chose to show every change beside the original instead of applying them automatically. That is slower to use, and it means 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 and not the model’s mood that day. The deploy only happens if they pass on that same commit. I use it for my own applications.
Live app ↗Source ↗
Fig.01 — review before exportupload → rewrite → compare → PDF
01 Upload résumé and job advert
02 Model returns one fixed shape
anything off that shape is rejected, not patched
03 Compare each change side by side
04 Export the accepted version
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, chose the users and 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 journeys. The trade calls that a return to origin, RTO. Nobody asked the customer first.
Key decision
The phone service reports the same call more than once: early, again when the details land, and again if an operator pulls the record. I sent all three down one handler that matches 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 recorded as a duplicate instead of being 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.
Source ↗
Fig.02 — one call, one outcomeorder → call → match → ship
01 Order comes in unconfirmed
02 AI voice call rings the customer
03 Every report matched on call ID
the same result arrives three times; this collapses it to one
04 Ship only after a confirmation
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 inside 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.
Source ↗
Fig.03 — one calculation pathclaim → rules → amount → record
01 Check the policy is valid
02 Apply cover, deductible, copay, limit
plain Python here, so each rule is tested on its own
03 Roll line items into one status
04 Write the whole claim at once
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 afterwards 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.
Source ↗
Fig.04 — credits to feedbackbook → call → transcript → feedback
01 Spend credits to book a slot
02 Video call writes its transcript
03 Feedback saved against the booking
a repeat message updates one record, not two payouts
04 Written feedback after hanging up
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.
Live app ↗Source ↗
Fig.05 — paste, pick, commentpaste → 3 sets → pick → comment
01 Paste the post text in
02 Three hashtag sets drafted
03 Pick one, posted as a comment
04 Login renewed on a 60-day expiry
renewal written by hand, with failures flagged not hidden
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.
Source ↗
Fig.06 — maths outside the modelinputs → maths → wording → plan
01 Enter income, spending, goal
02 Plain code does the maths
a model outage changes the wording, never the numbers
03 Model explains it in plain words
04 Budget and saving plan out
Next.jsSupabaseGemini APIVitest

Open source

I have been on both sides of the same programme inside a year. In January I was a contributor. From June I have been a mentor, and that turned out to be the harder job.

Jun 2026 — present

Social Summer of Code

Mentor
Two projects
41 contributors between them

Most of my time goes on the tasks, not the code. A task has to be written well enough that a stranger can pick it up, build the right thing, and finish it without needing me to explain it again.

  • EduFlow AI 23 contributors · around 100 open tasksA study platform the group is building out.On the harder tasks I ask the contributor to write down their approach and the user flow before they start building.
  • VidyAI++ (jai3546/AI_ROCKERS) 23 contributors · around 68 open tasksAn AI tutoring app the group is cleaning up.I wrote 5 of those tasks: a missing import that crashed the app, old pages still being served after a new release, 44 type errors the build was ignoring, and a build that fails when one database setting is missing.
MentoringTask writing

Jan 2026

Social Winter of Code

Contributor
Two projects
Two pull requests merged

On AlgoFi I started on a beginner-tagged task and finished on a harder one. Both projects were somebody else’s codebase, which is most of what the programme teaches you.

  • AlgoFi 11 contributors · 2 pull requests mergedA marketplace for digital collectibles.I built the dark and light theme for the whole app and made the choice survive a reload. 11 files, +419/−226.
  • BrowsePing 5 contributors · still open for reviewA browser extension for browsing together.I added the live typing indicators, 8 files and +365/−123 over 6 commits, and broke their dashboard plan into five smaller tasks other people could pick up.
Open sourceFrontend

About

Losing a teacher’s class recording is the worst thing this software can do.

I start with what breaks. The failures I trust least are the quiet ones, where nothing shows an error and nobody files a report, because nobody knows anything has gone wrong. A file disappears. Or a job runs a second time and quietly pays twice, and the only sign is a number that does not add up three weeks later. In two of the products below I built it so the same message arriving twice cannot do the work twice, rather than only writing a test and hoping.

The decisions I am proud of are mostly the ones where I gave something up. A feature cut because the version that would have held was out of budget. An extra layer kept because a fast test run is worth more than a tidy one. What I want next is a product company, in India or abroad, with a backend that has real users on bad connections. I am starting an MCA at IIIT Ranchi in 2026 to go deeper on the systems side.

Based in
Mumbai, India
Focus
Backend APIs and the databases under them
Python and TypeScript · PostgreSQL and Redis
Open source
SSoC 2026 mentor · SWoC 2026 contributor
EduFlow AI · VidyAI++ · AlgoFi · BrowsePing
Now
MCA, IIIT Ranchi
2026–2028 · weekend program
Before
B.Sc. Mathematics (Hons.)
Munger University · 2019–2022

Toolkit

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

01 — Building interfaces

Next.js · React · React Native

Web and Android apps that share one API behind them, including the ones that have to keep working when the connection does not.

02 — Building services

FastAPI · Node.js · Python

APIs, and the background workers that do the slow jobs. When these call an AI model, the answer has to come back in a fixed shape, or the call fails loudly instead of quietly passing something broken along.

03 — Working with data

PostgreSQL · Redis · Firestore · IndexedDB

Databases I design myself, queues for the slow jobs, and storage on the device that catches up with the server once it can reach it.

04 — Shipping & maintaining

Docker · GCP Cloud Run · Vercel · GitHub Actions

The app ships as a container, goes out to a few schools before the rest, and the tests have to pass before any of it moves.

05 — Workflow

Playwright · pytest · Git · code review

Tests that drive the real app in a browser, with its own API answers faked, so a failure means my code broke and not somebody else’s server. Small changes, and code review that actually reads the change.

LANGUAGES — TypeScript · Python · JavaScript · SQL

Tell me what you are building

I am looking for a Software Engineer II role and I am happy to relocate. Email is the fastest way to reach me, and I reply to everything that lands there.

sk729584@gmail.com

Elsewhere

GitHubLinkedInLeetCodeRésumé