About
Based in Ahmedabad, India — targeting L2 Application Support, Production Support, and Technical Support roles, particularly with European and German companies.
Behind the Investigations
I work in production-facing technical support for SaaS platforms — investigating customer-impacting incidents, analysing logs and databases, troubleshooting integrations, and working with engineering teams to drive issues toward resolution.
Day to day, that means understanding what happened in production, identifying the root cause, validating impact, and communicating findings clearly to both technical and non-technical stakeholders.
That instinct — trace the symptom back to its actual source, don't stop at the first plausible explanation — is also what's pulled me toward automation and AI-assisted tooling. When part of an investigation starts to feel repeatable, I want to see whether it can be built instead of redone by hand.
Focus Over Time
Not three separate skills so much as one continuous line — each stage grew out of spending enough time in the one before it.
01Where it starts
Every investigation still begins here — a customer-impacting issue that needs to be understood before it can be explained to anyone else. Triage, impact assessment, and getting a clear signal to the right person, fast.
02Where it deepens
Understanding a symptom isn't the same as finding the cause. Over time the support work pulled me further into the layer underneath it — querying data directly, reading logs instead of waiting for a summary, checking an API response instead of assuming it's fine.
03Where it's heading
The more incidents and investigations start to repeat, the more it's obvious which parts don't need to be done by hand every time. That's the direction I'm building in now — using AI-assisted tools to prototype the automation myself, rather than only asking someone else to.
Capability
Tracing a customer-facing symptom back to its actual root cause, then documenting it clearly enough that someone else could follow the same trail.
Querying production data directly with SQL / MySQL rather than waiting on a summary, to confirm what actually happened.
Reading logs, GCP output, and API responses (Postman, Firebase) to isolate where a request or process actually failed.
Recognising which parts of a repeated support or investigation process can be built once instead of repeated by hand.
Defining the problem, workflow, and decision logic myself, then directing AI-assisted tools to help build and test it.
From the Inside
I build automation for the kind of problems I've spent time being close to — not the other way around.
Working inside production support means spending a lot of time on things that repeat: the same category of question, the same shape of investigation, the same manual check before something ships. That's the perspective behind both prototypes on this site — each one starts from a support-side problem I recognised, not a technology I wanted to try out.
I'm not presenting either as a production system, and I'm not presenting myself as a software developer. On both, I define the problem, the workflow, and the decision logic — AI-assisted tools help turn that into working code, which I test and refine.