hello, I am
Full-stack engineer. I build React and Node systems that hold up past 100,000 users.
capabilities
Four areas of work. The common thread is production: real users, real data, and the failure modes that only ever show up there.
React and Next.js in front, Node.js and GraphQL behind it. Production applications where one person owns the interface, the service, and the deploy.
Services that deploy and scale on their own, behind contracts explicit enough that neither side breaks quietly.
Slow things made fast and silent failures made loud, measured in production before and after rather than estimated.
Serverless backends that stay up and say something useful when they fail, and AI features built with the same care as the rest of the system.
case file 01
React, Node.js, GraphQL, AWS Lambda, SQS, S3, DynamoDB
Full-stack scheduling for an enterprise tutoring platform: over 100,000 students per district, every one of them needing conflict-free assignments. Validation and consistency checks block conflicting or duplicate placements before they ever reach the database.
The diagram on the left is the real pipeline.
Large districts produced datasets big enough that the request died at API Gateway before the response finished. No query tuning could fix it, because the gateway timeout is a platform limit, not a slow query. The failure lived in the architecture, not the code.
A cron job builds the report file every two hours and writes it to S3, and the client receives a pre-signed URL instead of a payload. API Gateway is no longer in the data path.
That is what stopped report size from being an availability problem: the thing that timed out is no longer asked to carry the data.
Alongside the pipeline: an admin dashboard with downloadable schedule summaries, and the consistency layer that took scheduling errors down 90%.
case file 02: incident report
Node.js, AWS Lambda, DynamoDB, New Relic
Around 4,500 teachers were due payment. Product sent over a spreadsheet with about thirty names on it: paid nothing. In DynamoDB, the earnings attribute for exactly those teachers had never been written. No alert had fired and no error had been logged. As far as the system was concerned, nothing had happened.
The trace led through New Relic to the update function. It was invoked, it completed, and the write simply never landed. The reason nothing surfaced: no error capture at the process level, so the failure had nowhere to land and quietly vanished. You cannot debug an error that is never allowed to exist.
Error capture went in first, before any fix. The very next run confessed: DynamoDB was rejecting writes because the index's provisioned capacity was too low for payday load. Roughly thirty writes lost that race every cycle, silently, and the names changed each time.
The thirty were paid manually, verified name by name against the sheet. The provisioning was raised, and the failure never recurred.
What stayed with me is the prevention: errors that are captured where they happen, and logs that mean something. An incident should start from a query, not from a spreadsheet someone else noticed.
case file 03
Next.js, Supabase, Trigger.dev, Claude Haiku, MCP
Channel Dynamics serves institutional investors. I work across the whole surface: the public site, the portal's analytics and its filtering, and the observability wiring, so problems show up as traces instead of guesses.
A weekly job compiles leadership metrics into charts and one-line AI summaries. Trigger.dev runs it as a queue and fans it out into parallel tasks, because work that takes minutes does not belong inside a request.
The summaries are written by Haiku on purpose: they are one-liners, and one-liners do not need a frontier model. Right-sized is faster, cheaper, and just as sharp at that length. A dozen leadership inboxes, every week, on time.
A production MCP server puts the published research inside the customer's own Claude: seven tools to list, fetch, and semantically search reports.
The hard part is entitlements. A company-level flag, sector-level report entitlement, and per-user checks, with OAuth tied to the customer's real account. People only ever see what they are entitled to see, which in financial data is the entire product.
The MCP is newly launched and real customers are using it. Same principles as every other case file here: long work moved off the request path, access checked before anything else, and contracts explicit enough that an AI client can rely on them.
case files 04 + 05
case file 04
initial page load, landing routes
The bundle shipped the whole app on every route, so code the first paint never needed was parsed before anything drew. Route-level splitting and lazy loading fixed the paint; a second pass moved data fetching to TanStack Query with a deliberate cache, cutting redundant requests 40% and server load 20%.
lighthouse 65 to 92case file 05
modal, form field, table: everywhere
Teams kept rebuilding the same primitives, and the real cost was not the duplicate code: fixing one accessibility bug meant finding six copies of it first. One documented shared library later, feature cycles run 30% faster and frontend duplication is down 20%.
cycles down 30%case file 06
A portfolio that claims performance numbers has to be fast, or the claim is dead on arrival. So this site is built the way I build for clients: fully static, self-hosted fonts, zero blocking scripts, and every diagram is hand-projected SVG instead of a canvas library.
Open the devtools. The numbers on the right are from this page, measured the same way I measured the 3.5s app.
100
Lighthouse performance, desktop. 98 mobile
0
cumulative layout shift
0ms
total blocking time
100%
static, prerendered at build
Microservices only earn their operational cost if the boundaries are real. I settle the contract first and the implementation second, so a change on one side cannot quietly break the other.
see: case file 01Standardized API responses and reusable middleware for auth, validation, and errors. Consumers stop writing a special case for every route.
see: case file 05Structured logging with request correlation, so an incident starts from a query instead of a guess. Cheapest item on this list, biggest cut to resolution time.
see: case file 02Design through deployment, including the deploy. Running the thing in production changes the decisions you make while building it.
see: case file 06Grouped by layer, because that is how systems are built. Depth lives in the TypeScript and React and Node column; the rest is working fluency.
est. islamabadI work on the parts of a product users never see directly: the data layer that has to stay consistent, the endpoint that has to stay fast, the component everyone else builds on. Most of what I am proud of is invisible when it works.
The pattern across the case files is the same. Measure the thing that is actually failing, change the shape of the system rather than tuning around the symptom, then check the number moved. A gateway timeout is not a query problem. Duplicate components are not a code problem. Both are architecture answering the wrong question.
Recent client work includes Channel Dynamics, a market-intelligence platform for institutional investors.
Based in Islamabad, working remotely with teams anywhere.
Open to engineering roles and freelance work. Email is the fastest way to reach me, and I answer.