One engineer who takes a product from an empty repository to a running deployment, and is still there when it needs to survive real traffic.
Most projects do not fail in the frontend. They fail in the seams: the API that was designed around one screen, the auth model bolted on in week six, the deploy nobody can reproduce. Hiring separate people for each layer makes those seams somebody else’s problem, which usually means nobody’s.
I build the whole stack, so the seams are the job. Interface, API, schema and infrastructure get designed together, which is the only reliable way to keep them honest with each other.
That covers new products built from nothing and existing ones that need a layer rebuilt. I have taken multiple full-stack products from architecture through production deployment on my own, and I run the infrastructure they sit on.
Concretely, what is in the box. Anything not listed is worth asking about rather than assuming.
React and Next.js with the App Router, TypeScript throughout, server components where they earn their place. Accessible, responsive and fast on a mid-range phone, not only on the machine it was built on.
REST APIs in Node.js and Express, validated at the boundary with Zod, with the rules that matter living on the server where a client cannot route around them.
PostgreSQL, MySQL or MongoDB, modelled for the queries you will actually run. Migrations from the start, because the schema will change and it should change in version control.
Sessions or JWT, password hashing done properly, and role-based access enforced in one place rather than scattered across per-page checks. Includes multi-role products where routing, UI and API permissions all have to agree.
Docker and Docker Compose, Nginx, TLS, CI that builds and ships on merge, on a Linux VPS or your cloud account. Backups and a health check are part of shipping, not a follow-up ticket.
A runbook that covers deploying, restoring from backup and rotating secrets, written so the next person does not need me to read it.
The same five steps every time. The point of writing them down is that you can tell where a project is without asking.
Thirty minutes on what you are building, who it is for, and what has to be true for it to count as done. You leave with a written scope and a rough shape of the work, whether or not we go ahead.
Data model, API surface, auth model and hosting decided before any feature code. This is where the expensive mistakes get made, so it happens in writing first.
Work ships to a staging URL continuously, not in one reveal at the end. You see progress weekly and can redirect while redirecting is still cheap.
Auth and access control, input validation, rate limiting, error handling and the failure paths that only show up under real traffic. Treated as part of the build, not a later pass.
Containerised deploy, TLS, backups and a written runbook, into your infrastructure or mine. You get the repo, the credentials and a document that explains how to run it without me.
Every claim on this page points at something you can read. These are the three that matter most here.
Commit is a technical interview platform: live video and recordings, a synchronised in-browser code editor, and role-based access across candidate, interviewer, recruiter, developer and admin. It runs behind a reverse proxy with idempotent webhook processing, a retrying job queue with dead-lettering, and an automated backup sidecar.
Read the Commit case studyStorefront and admin panel in core PHP against MySQL: sessions, Argon2id password hashing, CSRF protection, rate limiting, cart and coupon logic, order lifecycle and file uploads, deployed as a multi-container Docker stack behind Nginx.
Read the e-commerce case studyAt NSEG Pvt Ltd I cut redundant API calls from fifteen or sixteen per page to a single request on initial render by lifting shared state into React Context, and built an admin dashboard with role-based access control over MySQL.
See the full resumeThree shapes cover almost everything. Which one fits is usually obvious within ten minutes of the first call.
You know roughly what you want built
A written scope, a milestone schedule and one price agreed before work starts. Best when the requirements are stable enough to write down.
Ongoing product work
A set number of days a month on a standing backlog, re-prioritised as you learn. Best when the roadmap is still moving.
One defined problem
A performance problem, an auth rebuild, a deployment that needs to stop falling over. Scoped in days, not months.
There is no fixed price list here, because a number quoted before the scope exists is a guess dressed up as a quote. These are the things that actually decide it:
The questions that come up on nearly every first call.
Both. Taking over an existing codebase starts with a read-through and a written assessment of what is there before any estimate, because reading unfamiliar code is the part people routinely underestimate.
Yes. I build from Figma handoffs regularly. If there is no design, I can build from a reference or ship a clean, restrained interface and keep the budget on the parts users feel.
You do, from the first commit. Work happens in your repository where you have one, and ownership transfers with the handover either way.
Every project ends with a runbook covering deployment, backup restore and secret rotation, so you are not dependent on me. Where you want ongoing work, a monthly retainer is the usual shape.
Ahmedabad, India, working remotely with clients anywhere. Core hours are 10:00 to 20:00 IST, which overlaps the European working day comfortably and the US morning at the edges.
Tell me what you are building and what has to be true for it to count as done. You get a straight answer on fit and timing, including when the answer is no.