About
I am a software developer based in Hyderabad, India with 7+ years of professional experience building web applications, APIs and mobile apps across several languages and frameworks.
Full-stack engineer with seven years of shipping and supporting real systems.
Most of my work has been on applications that were already live and already mattered to someone: enterprise clinical systems, CRM and reporting dashboards, learning platforms, internal business tools and consumer mobile apps. That shapes how I work — I spend time understanding the existing architecture, data model and business rules before changing anything.
On the back end I have worked primarily with .NET (ASP.NET MVC, ASP.NET Core, Web API) and PHP (Laravel, CodeIgniter), designing REST APIs, writing SQL against SQL Server and MySQL, and integrating authentication providers. On the front end I have built interfaces with React, Angular, TypeScript and Tailwind CSS, and on mobile with Flutter alongside native Android and iOS work.
A significant part of my experience is the unglamorous half of software: debugging production issues, reading unfamiliar code, tracing a slow query, adding logging where there was none, and maintaining applications long after the original team moved on. I have also taken on freelance engagements where a company needed someone to get productive in an existing codebase quickly and deliver under a tight deadline.
I work across the stack by preference rather than by necessity. Being able to follow a bug from a UI symptom through the API layer into a query plan — and fix it at the right level — is the most useful thing I bring to a team.
Works across the whole stack
Front end, back end, API, database and mobile. I can own a feature from interface through to schema rather than handing it across boundaries.
Productive in existing codebases
Much of my work has been on systems I did not write. Reading code, mapping dependencies and making safe, targeted changes is a core skill.
Comfortable with production
Investigating live issues, reading logs, reproducing defects and shipping fixes without breaking adjacent behaviour.
Breadth across domains
Clinical/healthcare, CRM, education and food delivery. Each domain came with its own rules, constraints and vocabulary to learn.
Journey
A progression rather than a dated timeline — each stage built on the one before it.
Foundations: language fundamentals, relational data and shipping working features.
Owning features end to end across UI, API and database.
Larger codebases, business rules, integrations and release discipline.
Regulated domains, access control and careful handling of sensitive data.
Cross-platform apps and the API design that supports them.
Deployment, hosting, pipelines and production diagnostics.
Using AI tooling to move faster while keeping engineering judgement in the loop.
New stacks, new domains, and writing down what is worth keeping.
Principles
How I decide what to build, and how to keep it working.
Before changing a system I want to know what it does today: the business requirement behind the ticket, the existing architecture, what depends on what, and which constraints are real. Most bad changes come from solving a problem that was described rather than the one that exists.
Technology choices follow the problem, the team and the timeline — not whatever is currently fashionable. A boring solution that the team can maintain usually beats an elegant one that only its author understands.
A clear contract between front end and back end lets both sides move independently and makes a second client — a mobile app, an integration, an internal tool — a small addition rather than a rewrite. Consistent resources, predictable errors, explicit versioning.
Authentication and authorisation belong on the server and in one place. Validate input at the boundary, apply least privilege, keep secrets out of client code and configuration files, and be deliberate about how sensitive data is stored and logged.
Code is finished when it can be operated: structured logging, meaningful error handling, a deployment that can be repeated, and enough visibility to diagnose an issue without reproducing it locally first.
Working across several stacks and domains means regularly being the least knowledgeable person in the room about something. Learning deliberately — and writing down what is worth keeping — is part of the job.
Tooling
AI tooling has changed how quickly I can move through the mechanical parts of development. It has not changed who is responsible for the result. I use it where it compounds effort and verify everything it produces the same way I would review a colleague’s pull request.
Coding
Scaffolding, boilerplate and repetitive transformations — reviewed before it lands.
Debugging
Generating hypotheses for an unfamiliar failure, then testing them against the actual system.
Documentation
First drafts of README files, API notes and handover documents.
Code review
A second pass over a diff to surface things worth a closer look.
Test generation
Drafting cases around edge conditions that are easy to overlook.
Refactoring
Mechanical restructuring where behaviour must stay identical.
Research
Getting oriented in an unfamiliar library or API faster.
Learning
Working through a new stack with something to ask questions of.
What does not change: understanding the requirement, choosing the architecture, judging trade-offs, and being accountable for what ships. AI accelerates the work; it does not own the outcome.