Abhay DarjiLead Software Engineer
Start a conversation
01 Home 02 About 03 Work 04 Stack 05 Writing 06 Contact
Start a conversation
Open to new conversations

Abhay Darji

Lead Software Engineer

I build software end to end - the interface, the services behind it, and the cloud it runs on - and I lead the teams that ship it. My focus is speed that survives contact with production: accelerated by AI wherever it removes friction, and held to a standard wherever it counts.

Start a conversation Read the writing Résumé
~/delivery-loop
01Understandframe the problem before writing code
02Designchoose the provable path over the clever one
03Scalesize the data, caching and queues for real load
04Buildaccelerate with AI, verify by hand
05Reviewstandards that hold under deadline pressure
06Shipa pipeline deploys it, not a person
07Measurefind the problem before a user reports it
0Years shipping software
0Technologies in reach
0Articles published
∞Things left to learn
What I do

I don’t stop at one layer
of the stack.

Interfaces, APIs, services, infrastructure, pipelines and the monitoring around all of it. Whatever the problem needs, that is the part I go and learn well enough to own.

01

Build across the stack

Front to back and out to the edge - component architecture, API design, data flow, cloud infrastructure. The boundaries between those layers are where most bugs live, so I make a point of not treating any of them as somebody else’s problem.

02

Ship fast, on purpose

AI-assisted development removes the mechanical work - scaffolding, boilerplate, refactors, first-draft tests - and that time goes straight back into design and review. A shorter path from idea to production, without a longer list of things to fix later.

03

Lead and multiply

Cutting scope into work people can genuinely own. Holding a review standard without becoming the bottleneck. Making sure the newest engineer in the room understands why, not just what to type.

04

Scale it and keep it running

Designing for the traffic you will actually get - caching layers, query cost, pagination, queues and graceful degradation - then proving it with structured events, performance budgets and alerts that fire on real failures instead of noise.

How the work moves

Fast is a discipline,
not a shortcut.

AI has genuinely changed how quickly software can be built - but only for people who already knew what good looked like. I use it hard on the mechanical half of the job and not at all on the half that requires judgment. That combination is what makes short timelines survivable.

Accelerated

The mechanical half

Scaffolding, boilerplate, repetitive refactors, first-pass tests, migration scripts, documentation drafts, unfamiliar syntax. Hours of typing compressed into minutes.

Deliberate

The half that decides

Architecture, trade-offs, security, data modelling, performance, and every line that reaches production. Generated code is a proposal - reviewing it is still the job.

From idea to production
Frame it properly Constraints, users, what cannot break, what the deadline actually is. Most delivery problems are ambiguity that reached a developer too early.
Design for change Boring, provable patterns. Clear ownership of state and data. A shape that still makes sense when the requirements move - and they will.
Build with leverage AI handles the repetition, I handle the decisions. Everything gets read before it gets merged.
Size it for the load Query cost, caching strategy, pagination, concurrency limits and what degrades first under pressure. Scale is a design decision, not a later optimisation.
Gate it automatically Lint, test and build run on every change. "It works on my machine" stops being a sentence anyone can say.
Watch what happens next Structured logging and alerts from day one, so the first person to know about a failure is the team, not a user.
The leverage

The tools that deleted
the busywork.

I am not precious about typing every line by hand. I am extremely precious about understanding every line that ships. Pick one to see where it actually sits in my day.

Deep reasoning

Claude

The one I reach for when the question spans a whole repository rather than a single file. Multi-file refactors, architecture reviews, and the second opinion that catches what I stopped seeing three hours ago.

  • Reading an unfamiliar codebase and explaining how it actually fits together
  • Multi-file refactors where the change has to stay consistent across modules
  • Arguing with me about an architecture decision before I commit to it

Used daily · reviewed line by line before anything is merged

Fast exploration

ChatGPT

Breadth rather than depth. Unfamiliar APIs, a rough idea turned into a concrete plan, and throwaway prototypes that answer a question in ten minutes instead of a day.

  • Scoping an approach before committing engineering time to it
  • Getting oriented in a library I have never used
  • Drafting the version I intend to delete

Used daily · treated as a starting point, never a specification

Cross-checking

Gemini

A different model reading the same problem. When an answer matters and I do not want to trust the first thing I hear, a second opinion from a different family of models is genuinely useful.

  • Verifying an approach that one model was suspiciously confident about
  • Large-context analysis across long documents and specifications
  • Catching the confident-but-wrong answers that all of them produce sometimes

Used for verification · disagreement between models is a signal worth chasing

In-editor flow

Copilot & Cursor

The lowest-friction layer. Inline completion where the intent is already obvious from context, and repo-aware edits across several files without ever leaving the editor.

  • Completing the code I was already going to write, faster
  • Repo-aware changes that touch four files and one test
  • Staying in flow instead of switching windows to ask a question

Always on · accepted only when I would have written the same thing

Local & private

Ollama

Open models running on my own machine, for anything that is not allowed to leave it. No request limits, no network dependency, and nothing leaving the laptop.

  • Working with code that cannot be sent to a third-party service
  • Staying productive on a bad connection or behind a locked-down network
  • Comparing open models without signing up for anything

I wrote a full setup guide — see the Ollama article

Non-negotiable

The rule

Not one of these decides architecture, approves a security choice, or merges its own work. They generate; I decide, verify and stay accountable. That line is the entire reason speed does not turn into rework.

  • Generated code is a proposal, not a decision
  • Anything reaching production is read and understood first
  • If I cannot explain it in review, it does not ship

The tools changed the pace. They did not change who is responsible.

The other half

AI in the product,
not just in the editor.

Using AI to build faster is one thing. Building software that has intelligence inside it is a separate discipline - and most of it turns out to be ordinary engineering problems wearing a new hat. Latency, failure modes, cost, trust.

01 Interface

Streaming responses

Token-by-token rendering, cancellation and partial state - plus the undo, retry and edit paths that let someone correct an answer rather than abandon it.

02 Data

Retrieval over your own content

Chunking, embeddings, ranking - and the citation UI that lets someone verify an answer instead of being asked to trust it.

03 Safety

Guardrails and fallbacks

Input validation, enforced output shapes, moderation, and a defined path for the moment the model returns something useless. It will.

04 Scale

Built for the load

Queueing, concurrency limits, backpressure and graceful degradation, so a spike in traffic slows the feature down instead of taking the product with it.

05 Economics

Cost and latency control

Caching, model routing, prompt-size discipline, and knowing what a single request actually costs before ten thousand users make it.

06 Confidence

Evaluation, not vibes

Test cases, regression checks and a way to tell whether a prompt change genuinely improved things or simply changed them.

◆
The unglamorous truth

A demo needs a good prompt. A product needs error states, rate limits, observability, a cost model and a way to roll back. The second list is the one I am useful for.

Selected work

Domains change.
The way I build doesn’t.

Regulated hiring, health insurance, multi-tenant healthcare SaaS, consumer well-being. These are the ones I have gone deep in, not the full list. The subject matter is context I pick up; the engineering underneath is what I actually bring.

01 Workforce & compliance

Care sector job portal

A hiring platform for Australia’s care sector, where nobody starts work until their clearances check out.

Australia 02 Insurance

Health insurance platform

Primary care, dental and vision cover sold to individuals, companies and their employees — with the commercial machinery behind it.

United States 03 Healthcare SaaS

Hospital membership programs

A multi-tenant SaaS platform running yearly membership programs for hospital chains. Live in production, with more than ten clients.

United States · live 04 Consumer health

Well-being platform

A personalised platform helping people build healthier habits across six dimensions of well-being.

Personalised product
See selected work
Shipped on the side

JSONWorks. The tab
that became a product.

Format, validate, repair, diff and convert - a hundred and eighty developer tools that run entirely inside the browser tab. Nothing you paste is uploaded, logged or stored.

  • 01Precise error positions Points at the token that broke the parse, and says what it expected instead.
  • 02One-click repair Trailing commas, single quotes, comments, unclosed brackets - fixed on the token stream.
  • 03Private by construction Client-side only, a worker for big files, installable as a PWA. Pull the plug; it still runs.
Open JSONWorks Browse all tools
0tools
0bytes uploaded
100%in the browser
Ways in

Four shapes this usually takes.

Not a fixed menu - just the requests that come up most often. If yours looks different, that is usually the more interesting conversation.

01

Build it from zero

A product that does not exist yet. I set the architecture, the delivery pipeline and the conventions early - and size the data model and infrastructure for the scale you are aiming at, so the second year is not spent undoing the first.

 02

Fix what has stopped being fun

A working system that has become slow, fragile or frightening to change, usually because it outgrew the shape it was built in. I find the real bottleneck and make it fast and safe to change again, without a rewrite nobody can afford.

 03

Lead the delivery

Owning scope, architecture, review standards and release readiness for a team - and being the person who resolves the ambiguity before it turns into three weeks of rework.

 04

Raise the level

Reviewing an architecture, auditing a codebase, setting up observability, or working with engineers who want to get better faster than trial and error allows.
The toolkit

Sixty-seven tools,
one filter away.

Instead of a wall of logos, the stack is a searchable console: filter by category, type to narrow it down, and see what each tool actually does in practice rather than that I have heard of it.

Open the stack console
10FrontendReact · Next.js · Gatsby · Capacitor / Ionic · Tailwind CSS 6Backend & APIsNode.js · GraphQL · REST APIs · AppSync · Directus 12Cloud & infraAWS Lambda · Lambda@Edge · CloudFront · Amazon S3 · AWS Cognito 7Delivery & qualityCircleCI · GitHub Actions · ESLint · Prettier · Biome 7AI & assisted deliveryClaude · ChatGPT · Gemini · GitHub Copilot · Cursor
From the notebook

Writing

Long-form notes on the things that actually cost teams time - technical debt, observability, authentication, URL design and search. Written for engineers, not for a keyword.

All articles
Open line

Have something worth building?

Whether it is an architecture you want a second opinion on, a codebase that has stopped being fun to work in, or a role you think fits - I read every message myself.

Start a conversation Connect on LinkedIn