Complete web applications
React interface, Spring Boot services, schema underneath. One person accountable, no hand-off gaps for bugs to hide in.
- React components on REST APIs you own
- Persistence and schema design
- Tested, documented, deployed
Full stack developer — React on the front, Java and Spring Boot at the back. Four years across telecom 5G, HR tech and e-commerce, and a specialism most teams don't have in-house: finding out where the time actually goes.
Read it upward: the base is the request, each row is one level deeper into the stack. The wide red frame at the top is a lock 28% of the request is spent waiting on — not the database everyone blamed. That's the job.
Mohali, India · IST (UTC+5:30), overlapping EU and US mornings · Replies within one business day
Most start with the first. The second is what they call me about when something has already gone wrong.
React interface, Spring Boot services, schema underneath. One person accountable, no hand-off gaps for bugs to hide in.
Slow endpoints, memory climbing until restart, throughput collapsing under load. I profile it and show you the code path responsible — with evidence.
Incremental extraction, no big-bang rewrite. On my last e-commerce migration this cut response time 31% without a feature freeze.
Getting your system to talk to someone else's — the work that always overruns, because the other side's spec is wrong.
Finding problems before your users report them, and keeping the codebase from becoming the reason releases are slow.
Open any one for the detail. Client names are withheld — I'll share them on a call.
A Java monolith with slow responses, memory leaks under sustained traffic, and concurrency bugs that only appeared in production. Thin coverage and an unreliable pipeline made every release a risk.
5G network automation generates high-volume operational data across systems never designed to talk to each other — internal platforms, vendor tooling and telecom inventory, each with its own transport and format.
Production infrastructure for a telecom operator at national scale, under real vendor scrutiny. The work is unglamorous: making systems that don't want to talk to each other exchange data reliably, without a person in the loop.
A parsing engine used by HR platforms to turn resumes and job descriptions into structured data. Accuracy varied by format, production issues surfaced only via customer tickets, and thread contention was quietly capping throughput.
This is the engagement that shaped how I work: most of the value came from measurement — profiler, heap dump, monitoring — not from writing new features.
A Java thread dump tells you what every thread is doing, but not what's wrong — the answer is in the edges between threads. The hosted analysers all want you to upload the dump, which contains your internal class names, hostnames and business logic.
A thread parked on a condition or inside Object.wait() has already released its monitor. Treating those as blocking edges is the standard way to report deadlocks that don't exist — so only true monitor entry creates an edge, and a regression test holds that line.
Try it live — paste a dump and see →
A booking platform is really two applications sharing a database. Customers search destinations and buy tickets; operators create flights, set schedules and change pricing. Blur the boundary and you get a customer who can reprice a flight.
The clearest example of end-to-end ownership: one person responsible from the interface a customer touches down to the access rules in the database. That's the shape most of my freelance work takes.
The shape I reach for when a service must stay responsive while something behind it is slow — and, on the bottom rail, the measurement layer that tells you which.
Most teams build the top four columns and skip the bottom rail. Then nobody can say why the service got slow. I build the rail first — it's how the 31% was found, and how I knew it was real.
Everything here is something I've used on shipped production work. I'd rather tell you honestly where I'm strong than claim the whole ecosystem.
Pick the one that matches how well-defined the work is. If you don't know what's wrong yet, the audit is the cheapest way to find out.
For teams whose Java service is slow, leaking, or falling over — and who don't yet know why.
1–2 weeks · Fixed fee
For a defined outcome: a new service, a migration, an integration, a version upgrade.
4–12 weeks · Fixed price per milestone
For teams needing reliable backend capacity without another full-time hire.
Minimum 2 months · Monthly rate
Thirty minutes. You describe the symptom; I ask the awkward questions about load, data volume and who else touches the code.
FREE · SAME WEEKI profile before I propose. A written document: the real cause, what I'd change, what I won't touch, and a price. You own it either way.
2–4 DAYSCode in your repository from day one, a demo each week, a short written update every Friday. No month-long silences.
ONGOINGDocumentation, before-and-after numbers from the same profiler, a walkthrough with your team, thirty days of bug-fix support.
+30 DAYS INCLUDEDYou do, fully, from the first commit. I work in your repository under your account. I'm happy to sign your NDA and work under your contract rather than mine, and to assign IP on payment.
That's most of what I do — every role I've held has been inside an existing enterprise codebase with its own conventions. I follow yours rather than importing my own, and I won't push for a rewrite unless the measurements support one. On my last migration they did, and I have the before-and-after profiles to show it.
I don't. The audit promises a diagnosis, not a number — you get measurements and a ranked list of causes. Only after that will I quote fixed-price work against specific findings, because by then both of us know what's actually wrong. The 31% was measured before and after with the same profiler, not estimated.
I build React frontends and the Spring Boot services behind them, so I can take a web application end to end without a hand-off. My depth is on the backend — that's where four years of production work sits, and it's why I'm useful when an app is slow rather than just unfinished. If your project is frontend-heavy with intricate design work, I'll say so and suggest pairing me with a specialist. I don't do native mobile.
Mohali, India, on IST (UTC+5:30) — solid overlap with European teams and US East Coast mornings. Async by default: Slack or your tool of choice, a written update every Friday, calls scheduled rather than dropped on you. I reply within one business day, and work in English and Hindi.
On fixed-price milestones, an overrun caused by my estimate is mine to absorb. If the scope genuinely changes — new requirements, or a dependency that turned out different from its documentation — I'll flag it with the cost impact before doing the work. No surprise invoices.
Thirty minutes, no pitch deck. "The API got slower and we don't know why" is a perfectly good starting point. If I'm not the right person, I'll say so on the call.