Services
Work with a target, not a retainer.
Every engagement starts with a number we agree on — a latency target, a concurrency target, a cost ceiling — and ends with your team able to run what I built.
What I do
Four kinds of work
Legacy replacement and migration
An old system still runs the business and cannot go down. I model the replacement, write the migration that carries the records across with their validation intact, and keep the legacy estate read-only while it happens.
See the migration approach used on a 38-database compliance system Legacy replacement and migration: scope, fit, and questions
Multi-tenant platforms
One codebase, many tenants, and no way for one of them to see another's data. Tenant-scoped queries, per-resource RBAC, configurable forms, and the audit trail a regulated customer will ask for.
See tenant-scoped RBAC and a JSONB form engine serving 24 cities and counties Multi-tenant platforms: scope, fit, and questions
APIs and integrations
REST APIs designed against real client requirements, plus the third-party work around them — payments and reconciliation, auth, mail, and government or partner systems.
See per-client rate limiting on a search API over 4 TB of JSON
Infrastructure and deploys
The AWS layer under the product and the path code takes to reach it — queues, scheduled tasks, CI/CD, containers, and the monitoring that tells you before a user does.
See notifications and recomputation moved onto SQS, SES and EventBridge-triggered ECS tasks
Fit
Who this is for
Said plainly, so neither of us spends a call finding out.
A good fit
- An existing engineering team with a concrete backend target
- A legacy system to replace, a multi-tenant model to harden, or a search or API layer under strain
- Node/TypeScript, PostgreSQL or MySQL, Elasticsearch, and AWS
Not a fit
- General staff augmentation or open-ended long-term support
- Pure front-end work
- Work with no agreed target at the end of it
Process
How an engagement runs
Four steps, from first read of the codebase to handover.
01
Read the system
Before proposing anything I go through the code, the schema, and the traffic. Most performance problems are a data model decision made two years ago.
02
Agree the target
We write down what has to be true when this is done — a latency number, a concurrency number, a cost ceiling. Everything after is measured against it.
03
Ship in slices
Changes go out behind flags, smallest risk first. You see progress in production weekly, not a big-bang merge at the end.
04
Hand over properly
You get the runbook, the dashboards, and a team that understands the change. I am not trying to make myself permanent.
Questions
Before you write
Are you available right now?
I am Software Development Engineer II at Shuru full time, and I take a small number of contract engagements alongside it. Whether I can start depends on the month — ask and I will tell you straight.
What size of engagement works?
Scoped pieces of work with a clear target: a legacy system that has to be replaced, a search layer that has to get faster, an integration that has to ship. Not open-ended staff augmentation.
Do you work with existing teams?
Usually, yes. Most of this work is inside a codebase someone else owns, alongside engineers who will keep it after I leave. The handover matters as much as the change.
Where are you based?
Mumbai, India, working remotely. I have run remote engagements across time zones since 2019 and overlap where the team needs it.
What stack do you work in?
Node and TypeScript with NestJS and Express, PostgreSQL and MySQL, Elasticsearch, AWS, Docker. Python where parsing or migration is the job. I do not take pure front-end work.
Next