Former cricket player

When a web app breaks, the first thing is to slow down and make the problem repeatable: what exactly did the user click, what data did they enter, and does it happen in every environment or only one? Then I narrow it down by following the request end-to-end—checking the browser console and network tab, then the backend logs/stack traces—until I can point to the exact step where things go wrong (UI, API, or database/external service).Ananth_Iyer_CV.pdf​ After that, I try to remove guesswork: I add a small amount of targeted logging, write a minimal test case, and if it’s a recent regression I’ll bisect changes to find the commit that introduced it. Once I fix it, I re-test the original scenario and add a regression test/monitoring so the same bug doesn’t come back—this is the approach I’ve used when dealing with real API integrations and edge-cases in my projects.

For full stack, preference is for a Python-based stack: FastAPI (or Django) for the backend, PostgreSQL for the database, and React/Next.js + TypeScript for the frontend. For shipping and reliability: Docker, GitHub Actions CI, and cloud deployment on AWS (or a simpler PaaS like Render/Fly.io) depending on scope.Ananth_Iyer_CV.pdf​ If keeping it simpler for smaller builds: FastAPI + SQLite, and a lightweight frontend (Next.js or even server-rendered templates) to move fast while staying maintainable.