People were dropping off mid-journey, and not for one reason. Third-party vendor errors we didn't control, bank API failures and delays, a journey that ran too long, forms that felt heavy, consent screens that read as scary. Each shed a few percent. The first version completed at 16%, and the losses were scattered across the whole flow.

There was no single fix. The drop-off was death by a thousand cuts, and a chunk of it sat with bank and vendor systems we couldn't directly change. The only way through was to measure everything (drop-off per screen, every error class) and then attack each cause with the right tool, ours and theirs.

I instrumented drop-off on every screen and watched where people left. On our side: fixed our errors, trimmed forms to only what was mandatory, and rephrased the consents that data showed were scaring people off. I resequenced the journey, moving heavier consents later, where sunk-cost momentum makes people far more likely to agree than they would up front. For the bank side, I worked directly with their teams to reduce and mitigate failures, and added clear communication around the rest. And I filled the unavoidable waits (like the account-opening API) with Lottie animations, previews of features they'd soon unlock, and small facts about banking and Jupiter, so the dead time built excitement instead of doubt. Working hand-in-hand with analytics and product, all of it together took completion from 16% to 45%, and I later re-architected the flow into a decoupled platform other products could plug into.

A year of shipping features had quietly bloated the app. Boot times had crept up. In some outlier cases on older devices, launch could stretch to 14 seconds. Every screen transition also sat behind a full-screen loader. The cumulative effect was an app that felt low-quality, even where the code underneath was sound.

There was no single thing to blame. Several seemingly unrelated issues (tiny hindrances scattered across the experience) added up to a perception that everything was wrong. A few were genuinely concerning; most were perceived, the sum of small frictions eroding trust in the app's quality. No low-hanging fruit. Fixing it meant a deep cleanse and a platform-level reshaping. An overhaul, not a patch.

It started with data. We instrumented everything, found the real bottlenecks, optimised, then instrumented again, chasing the highest-impact wins. The numbers kept pointing toward the architecture itself: a framework migration that would let us shed a pile of legacy bloat and polyfills weighing down launch. It wasn't a small effort: legacy code to move, dependencies to untangle, so we planned it carefully and migrated. With the newer architecture in place we cut the dead weight, then layered on more: caching, a disciplined launch-time checklist, behind-the-scenes prefetch. On the perceived side, static loaders became engaging animated states, errors became contextual and non-blocking, and we pre-warned users when a bank's systems looked likely to be down, so failures stopped feeling like surprises.

Insurance claims arrive as unstructured documents (scanned reports, bills, prescriptions), and every one has to be checked against a thicket of policy rules before it's approved or rejected. Done manually it's slow and inconsistent; done by AI alone it's unaccountable. Healthcare can't accept either.

I architected a retrieval-augmented pipeline that does the heavy lifting and hands a human the final call. A document goes through OCR, then an LLM extracts structure from the raw text. That extraction is embedded and matched against a vector store by semantic similarity to retrieve the most relevant context. A second LLM step reasons over that context to pick the most meaningful match, a rule-based engine applies the policy logic to produce a standardized decision, and the result lands with a claims agent as a pre-reviewed approve/reject they can verify and submit. Only once the agent signs off do changes reach the member.

Several product teams were independently rebuilding the same capabilities (video consults, chat, login, doctor lists), each in their own silo. Everyone felt the drag; no one had named it as a single, fixable problem.

I proposed Webmodules: a framework of plug-and-play mini-apps any Mfine product could embed. I designed the architecture and shipped the infrastructure plus the first modules: login-auth, patient-profile, doctor-list, chat. Convincing engineers was easy once it was named; I made the case to PMs by tying it to the features already in the pipeline. It was adopted across the company.

The bet: deliver groceries from neighbourhood micro-stores in under thirty minutes, years before Zepto or Instamart made that normal. As the second engineer, with no designers and no PMs, the entire technical surface was mine to build.

I built all of it: the customer app (QR payments via Razorpay/Instamojo), the Electron point-of-sale for the stores, the admin panel with role-based access, and the inventory, order and microservices behind them. I wireframed the flows myself, and spent real time in the stores, tagging items, arranging shelves, watching what customers reached for first.