skip to content
aman.verma— available for work

open to opportunities

Aman Verma I build backend systems that hold up when things break.

Software Engineer I at NAVIOMGurugram, India

  • Backend architecture
  • Distributed systems
  • Multi-tenant SaaS

I own the platform layer of a greenfield cross-border logistics product at NAVIOM — the workflow engine, the rules engine, and the partner integrations every other service is built on. Before that, eighteen months on LinkedIn’s data infrastructure, moving a high-volume financial pipeline from Samza to Flink.

I also build whole products end to end and take on select freelance work — backends, web apps, and MVPs that need to actually ship.

Platform layer / NAVIOM4 packages
6 product services
workflow-engine
cases · SLA · approvals
rules-engine
versioned · p95 < 150ms
integration-adapter
retries · fail-closed
vault
secure file storage
partner APIsredis sliding window
Six services consume four independently versioned packages; all partner traffic leaves through one adapter with a cross-instance circuit breaker.
current
NAVIOM
platform layer, greenfield
previously
LinkedIn
data infrastructure, via MAQ
shipped
NxaCare
live multi-tenant SaaS
education
IIIT Guwahati
B.Tech, CSE
[01]Experience

Four roles, all of them shipping production backends.

Platform work on a greenfield product today; high-throughput stream processing on LinkedIn's data infrastructure before that. Freelance and internship work before that again — all of it backend, all of it in production.

NAVIOM

Software Engineer I

periodJul 2026 — Present
locationGurugram
industryCross-border logistics
  • TypeScript
  • NestJS
  • Next.js
  • PostgreSQL
  • Redis
  • RabbitMQ
  • GCP
  • Docker

Designing and building the core platform systems for a greenfield cross-border logistics product — built from an empty repository. I own the layer everything else is assembled from.

Platform packages

Four versioned internal packages — Workflow Engine, Rules Engine, Integration Adapter Framework, and Vault — consumed by the product services.

Each package ships independently with its own versioning, so product teams upgrade on their own schedule instead of moving in lockstep with the platform.

4
packages
6
consuming services

Workflow Engine

A case management system that turns operational exceptions into owned, SLA-tracked tickets.

Designed and built end to end: auto-assignment routes each exception to an owner, maker-checker approvals keep a second pair of eyes on consequential actions, and closure is evidence-gated so a case cannot be marked resolved without proof.

Integrations & rules

A unified partner Integration Adapter, and a versioned Rules Engine on the hot path.

The adapter handles retries and fail-closed routing, with a Redis sliding-window circuit breaker that holds state across instances — so one partner degrading does not take the fleet with it.

The Rules Engine is versioned, which means a decision made last month can still be explained with the rules that were live at the time.

p95 < 150ms
rules evaluation
75
unit & integration tests

AI-assisted delivery

Introduced an AI-assisted delivery workflow built on Claude Code, with human review and CI gates kept firmly in place.

Repo-level context, custom skills, and MCP-backed spec-to-test scaffolding and PR review. Nothing merges without a person and the pipeline agreeing.

MAQ Software

Client: LinkedIn

Software Engineer I

intern → full time

periodJan 2025 — Jun 2026
locationNoida
industryData infrastructure
  • Java
  • Apache Flink
  • Apache Kafka
  • Python
  • Kubernetes
  • PostgreSQL
  • Linux

Eighteen months on LinkedIn’s data infrastructure — high-throughput distributed stream processing, and the tooling to move it safely. Started as an intern and converted to full time.

Samza → Flink migration

Migrated a high-volume financial stream-processing pipeline from Samza to Apache Flink, and built the tooling that scaled the migration across repositories.

−45%
Kafka I/O memory
+20%
throughput
−70%
manual effort

MegaRefresh — model lineage

DAG-based model-lineage discovery and metadata collection.

Made reproducibility, tiering, and policy-gated publishing possible across the model estate — you can answer where a model’s inputs came from before you publish it.

850+
models covered
Read the migration case study

Avant Enterprises

Developer

Freelance

periodAug 2024 — Sep 2024
locationRemote
industryProject management software
  • Django
  • React
  • JavaScript
  • REST APIs

A short freelance engagement shipping project-management modules and customer-facing dashboards, working directly with the stakeholders who used them.

Modules & dashboards

Shipped project management modules and customer-facing dashboards, and worked directly with stakeholders on fixes and new features.

Reported a 25% improvement in task completion after the workflow changes landed.

Scholify

Software Engineering Intern

periodOct 2023 — Jun 2024
locationRemote
industryEdtech
  • Python
  • JavaScript
  • Redis
  • PostgreSQL
  • AWS EC2
  • RDS

Backend services for a scholarship campaign platform, plus the AWS infrastructure under them.

Services & infrastructure

Designed microservices and REST APIs for the Go-Pro scholarship campaign, including PhonePe payment integration.

Cut API response times by 20% with Redis caching over PostgreSQL, and handled releases on EC2 with auto-scaling, load balancers, and RDS migrations in production.

[02]Selected work

Two systems, taken apart: what broke, what I decided, what changed.

The first is a product I own end to end and the clearest proof I can ship a whole thing. The second is the hardest single problem I have worked on. Both are written the way I would talk through them in an interview.

01

NxaCare

LIVE

Multi-tenant SaaS productBuilt with NxaOne(opens in a new tab)

A clinic management platform that runs the whole operation — appointments, treatment plans, prescriptions, billing, and patient chat — across ten-plus modules, serving a staff admin panel and a separate patient app.

The problem

Small clinics run on paper diaries and phone calls. The hard part is not any single feature; it is that scheduling, payments, and billing all have to agree with each other while several people touch them at once — and that every clinic on the platform has to stay sealed off from every other one.

My role

I built the appointment-booking system, architected the payment layer, and automated the operational workflows behind it.

  • Node.js
  • React
  • PostgreSQL
  • Redis
  • BullMQ
  • Socket.IO
  • Stripe
  • Razorpay
  • Docker
Visit nxacare.com(opens in a new tab)
NxaCare / booking + payment pathrequest flow
concurrent
booking requests
availability engine
schedules · capacity · slot lock
one bookingno double-booking
payment factory
webhook signature verified
stripe
razorpay
circuit breaker fails over between gateways
bullmq workersnotifications · invoicing · appointment lifecycle
Concurrency is resolved before a slot is held, payments sit behind one interface with gateway failover, and everything non-urgent leaves the request path.
Outcome
product modules
10+
product modules
tenant-scoped models
19+
tenant-scoped models
front ends, one API
2
front ends, one API

Live at nxacare.com and running real clinic operations. Usage figures are the clinics’ to share, not mine.

Decisions I made

01
An availability engine, not a calendar

Booking reconciles doctor schedules, slot capacity, and concurrent requests so two patients racing for the same slot cannot both win. Double-booking is prevented at the source rather than reconciled afterwards.

02
Two payment gateways, one interface

Stripe and Razorpay sit behind a factory pattern, so the rest of the app never learns which processor it is talking to. Webhooks are signature-verified, and a circuit breaker fails over between gateways when one starts misbehaving.

03
Work that happens without a request

Notifications, invoicing, and appointment lifecycle jobs run on BullMQ queues instead of blocking the request path — so a slow email provider never becomes a slow booking.

04
Tenants that cannot see each other

Multi-tenant isolation runs through 19+ data models, so a clinic’s patients, schedules, and invoices are scoped to that clinic rather than filtered in the UI after the fact.

05
One platform, two front ends

A staff admin panel and a patient-facing app sit on the same API, so a booking made by a receptionist and one made by a patient travel the same code path and obey the same rules.

06
Billing that actually gates the product

Subscription billing with tiered plans, usage quotas, and feature gating — the plan a tenant is on determines what the product will do for them, enforced server-side.

What this demonstrates
  • Product ownership end to end
  • Concurrency & data integrity
  • Payments integration
  • Multi-tenant architecture
  • Async job processing
Android app · Published03

Knowledgify

Built with NxaOne(opens in a new tab)

An education app for diploma students, live on the Play Store with a community layer for peer learning.

Built the app and the Firebase backend behind it.

10,000+ installs
4.1★ on Google Play
  • Java
  • Android SDK
  • Firebase
Play Store(opens in a new tab)Source(opens in a new tab)
[03]About

What I am good at, and how I work.

Systems that fail well

Circuit breakers, retries, fail-closed routing, checkpoint-aware rollback. I design for the day the dependency is down, not the day it works.

Correctness under concurrency

Slot locking, payment webhooks, exactly-once-shaped stream processing. The problems where being roughly right is the same as being wrong.

Platform code others depend on

Versioned internal packages with upgrade paths, consumed by six services. Written to be depended on, not just to work once.

Shipping the whole thing

System design through deployment: schema, API, queues, CI, infra. I have taken products from an empty repository to production.

I work on the unglamorous middle of products. The scheduling, the retries, the part that decides what happens when a partner API stops answering. Most of what I have built lately is platform code, the libraries other engineers depend on, where a careless change is someone else’s outage.

That shapes how I work. I would rather ship a versioned package with a boring upgrade path than a clever abstraction nobody can reason about six months later. I like problems where correctness is load-bearing: concurrent bookings, payment webhooks, checkpointed stream jobs. Those are the ones where the details actually decide whether it works.

I also build whole products end to end. Most of that happens through NxaOne, a small product studio I co-build with a few people I trust. We shipped NxaCare, a clinic platform running real operations, and Knowledgify, an Android app with ten thousand installs. Doing both keeps me honest: infrastructure work teaches you what breaks at scale, and product work reminds you that someone has to use the thing.

Stackwhat I reach for

Day to day

  • TypeScript
  • NestJS
  • Node.js
  • PostgreSQL
  • Redis
  • Next.js

At scale

  • Java
  • Apache Kafka
  • Apache Flink
  • RabbitMQ
  • Protobuf / Avro

Shipping

  • GCP
  • AWS (EC2, RDS, Lambda)
  • Docker
  • Kubernetes
  • GitHub Actions
  • CI/CD
  • Linux

Also fluent

  • Python
  • Spring
  • Django
  • React
  • MongoDB
  • gRPC
  • C/C++

Working with AI

  • Claude Code
  • MCP
  • RAG
  • Agentic workflows
  • AI-assisted review

Practices

  • System design
  • Distributed systems
  • Data modelling
  • Unit & integration testing
  • Shell scripting
Education

B.Tech, Computer Science & Engineering

Indian Institute of Information Technology, Guwahati

locationGuwahati, Assam
periodDec 2021 — May 2025
[04]Services

What you can hire me to build.

I take on a small amount of freelance work alongside my full-time role, and larger scope goes through NxaOne, the product studio I co-build. Each of these is something I have already shipped, not something I am willing to try.

01

Backends & APIs

REST and gRPC services, data modelling, schema design, auth, queues, caching, and the deployment around them.

Platform services at NAVIOM · microservices and PhonePe payments at Scholify

02

Full-stack product MVPs

An idea taken from empty repository to something real users log into, from schema through UI through infrastructure.

NxaCare, a live multi-tenant SaaS · Knowledgify, 10,000+ installs

03

Payments & integrations

Gateway integration, webhook signature verification, idempotency, reconciliation, and failover between providers.

Stripe and Razorpay behind one interface at NxaCare · PhonePe at Scholify

04

Web apps & dashboards

Internal tools and customer-facing dashboards where the hard part is the data behind the screen, not the screen.

Project management modules and dashboards for Avant Enterprises

05

Platform & internal tooling

Versioned internal packages, migration tooling, and the automation that turns a one-off job into a repeatable one.

Four internal packages at NAVIOM · migration tooling on LinkedIn data infra

Something not on this list?

If it is a backend, a product, or an integration problem, ask anyway. If it is not a fit, I will say so.

start a project
How working together worksbefore you ask
availabilityA small amount of freelance work alongside my full-time role
larger scopeTaken on through NxaOne, the product studio I co-build(opens in a new tab)
working styleRemote, direct with stakeholders, written updates
first stepTell me what it is and what it needs to do, and I will tell you honestly if I am the right fit
[05]Contact

Tell me what you are building, or what you are hiring for.

Recruiters, hiring managers, founders, and fellow engineers all welcome. I reply to anything with a real project or role behind it.

Or mail me directly — aman247av@gmail.com

Gurugram, India · available remotely