I build software -
and the teams that
build software.
I am a Lead Software Engineer. I work across the whole stack rather than defending one corner of it, I move quickly because I use every tool available to me, and I keep the standard high because speed without judgment is just debt arriving earlier.
I learned to build
by breaking things slowly.
My route into engineering was not a shortcut. I studied Computer Engineering at Sarvajanik College of Engineering and Technology under Gujarat Technological University, and most of what I actually know came from the slow part afterwards: writing code line by line, breaking things, debugging quietly at eleven at night, and rewriting the same solution until it stopped feeling fragile.
I started as a software engineer working full-stack from day one - web applications, hybrid mobile builds, cloud services, and a long tail of legacy code that needed modernising without breaking anyone's Monday. That range was not a strategy at the time. It turned out to be the most useful thing I have.
As I moved into senior work, the centre of gravity shifted. Less "can I make this work" and more "will this still make sense to someone else in two years". That is also when I started spending real time on the parts nobody demos - observability, access control, release pipelines, performance budgets, and the metadata decisions that quietly determine whether anything you build is ever found.
Leading changed the shape of the job again. I still review, still write code, still argue about component boundaries - but the highest-leverage thing I do most days is removing ambiguity before it reaches the people building. And the pace has genuinely changed: AI removes a startling amount of mechanical work, which means the constraint is no longer typing speed. It is judgment. That is the part I protect.
Career timeline
Module Lead Software Engineer
Brisktech
Leading technical direction and delivery - architecture decisions, scope, review standards and release readiness - while staying hands-on in the codebase. Accountable for the quality of what ships and the growth of the engineers who ship it.
Senior Software Engineer
Brisktech
Designed and built secure, scalable features end to end across web and mobile products. Owned architecture decisions, introduced observability and alerting into production applications, and guided other engineers through review and pairing.
Software Engineer
Brisktech
Built full-stack web and hybrid mobile applications, integrated cloud services, and helped modernise legacy systems. This is where the AWS and serverless foundation was laid - alongside the craft that still underpins everything I do.
B.E. Computer Engineering
Sarvajanik College of Engineering and Technology · Gujarat Technological University
Four years of fundamentals - data structures, networks, databases, operating systems - that still explain why things break long after the frameworks have changed names.
Six opinions I will
defend in a review.
None of these are original. All of them are expensive to learn the hard way, which is exactly how I learned them.
Boring is a feature
The clever solution is a loan against your future attention. Proven, predictable patterns win because they still make sense at 2am during an incident.
Optimise for the next reader
Code is written once and read for years. If someone has to reconstruct your reasoning from scratch, the code is not finished yet.
Own the whole path
From ticket to production and back through the logs. An engineer who only owns the middle of that path will keep being surprised by both ends.
Design for the load you will get
Scalability is a shape you choose on day one, not a sprint you schedule after the incident. Query cost, caching, pagination and what degrades first — decided early, cheaply.
Measure before you optimise
Every performance argument without a number is a preference. Profile it, then decide — and design for the scale you will actually reach.
Fear is a design signal
When a team says “let’s not touch that file”, the architecture has already told you where it is failing. Listen to it before the metrics do.
What AI changed
about how I work.
I am not going to pretend nothing changed, and I am not going to pretend it replaced the job. Both of those are marketing positions. Here is the actual split.
The floor of every task dropped
Scaffolding a module, writing a migration, learning an unfamiliar API, drafting tests, translating a pattern between stacks - work that used to consume an afternoon now costs twenty minutes. Reviews got sharper too, because a second opinion is always available before I open a pull request.
The part that needs a person
Deciding what to build. Knowing which trade-off you are actually making. Spotting the security assumption nobody wrote down. Reading a stack trace at 11pm and recognising the shape of it. Every one of those still comes down to whether the person holding the keyboard understands the system.
In my own work
Claude, ChatGPT, Gemini, Copilot and Cursor sit in the loop constantly. Nothing they produce reaches a branch without me having read and understood it first.
In the products
Streaming interfaces, retrieval over private data, guardrails, evaluation and cost control - the engineering that separates a working feature from a convincing demo.
In the team
Setting the standard for what may be generated, what must be reviewed, and how we keep a shared mental model when nobody typed every line by hand.
The constraint was never typing speed. It is judgment - and that is the part I protect.
What changed when I stopped
being only an engineer.
Clarity is the deliverable
Most delivery problems are not skill problems. They are ambiguity problems that reached a developer before anyone resolved them. My first job is to catch those upstream.
Review as teaching
A comment that only says "change this" fixes one line. A comment that explains the trade-off changes how someone writes the next hundred.
Protect the standard
Consistency is not bureaucracy - it is the thing that lets several engineers move at once without producing several architectures.