01 Home 02 About 03 Work 04 Stack 05 Writing 06 Contact
Start a conversation
Home/Contact
Open to conversations

Tell me what
you're building.

An architecture you want a second opinion on. A codebase that has stopped being fun to work in. A role you think fits. A question about something I wrote. All of it is welcome - and it reaches me directly, not a queue.

Three ways to reach me

I keep the list short on purpose. Fewer channels, faster replies.

Email abhaydarji24@gmail.com LinkedIn in/abhay-darji-2405  ↗
Location Gujarat, India · IST (UTC+5:30) · comfortable working across US time zones

What a good first message looks like

A sentence on what you are building, a sentence on where it is stuck, and what you want from me - a review, a conversation, or a hire. That is genuinely enough to get a useful reply.

Response time

Usually within a couple of working days. If it has been longer than that, a nudge on LinkedIn is welcome rather than rude.

Send a message

Fields marked * are required.

Please tell me who you are.
That email address does not look right.
A short subject helps me prioritise.
A little more detail, please - at least 20 characters.

Your message goes straight to my inbox. No newsletter sign-up, no third-party marketing.

Before you write

Questions I get asked a lot

Building software end to end and leading the people who build it. In practice that means product interfaces, the APIs and services behind them, and the cloud infrastructure underneath - plus the delivery pipeline, observability and review standards that keep all of it stable. I am not precious about which layer a problem lives in.

I start by understanding the constraints, not the features - who the users are, what cannot break, what the team already knows, and what the timeline really is. Then a plan that is deliberately boring: proven patterns, clear ownership of state and data, a data model and infrastructure sized for the scale you are actually aiming at, and a delivery pipeline in place before the first feature ships.

By being ruthless about which half of the work is mechanical. Scaffolding, boilerplate, repetitive refactors, first-draft tests and unfamiliar syntax get AI assistance, which compresses hours into minutes. Architecture, security, data modelling and anything reaching production get read line by line. Generated code is a proposal, not a decision - and the review is what keeps velocity from turning into rework.

Consistently. I am in India (IST, UTC+5:30) and have spent years working with stakeholders across US time zones. Written clarity, decision records and asynchronous review carry most of that weight - meetings carry the rest.

Happily, when time allows. Send a short description of the system and the specific question you are stuck on. A focused question gets a far more useful answer than "what do you think of this repo".

I am always open to a conversation about interesting engineering problems, wherever they happen to be. Domain matters far less to me than whether the work is genuinely hard and the team cares about doing it well.

Deliberate. Email, LinkedIn and this form cover everything, and they leave a written trail that both of us can refer back to. If a call makes sense, we will arrange one once we have said hello.