The part of the product nobody demos and everybody depends on: the API, the schema, the auth model and the jobs that have to keep running at three in the morning.
A backend is judged on what happens when things go wrong. The webhook that arrives twice. The job that fails halfway. The session that should have been revoked ten minutes ago. Demos never cover these, and they are most of the difference between software that works and software that works on a Tuesday.
I build APIs where those paths are designed rather than discovered. Validation at the boundary, permissions enforced in one place, idempotency on anything a third party can retry, and failure handling that leaves a trail you can read afterwards.
That comes with the database. Schema design, migrations and the indexes your actual queries need, rather than an ORM’s defaults applied hopefully.
Concretely, what is in the box. Anything not listed is worth asking about rather than assuming.
Endpoints shaped around what clients need rather than what the tables look like, with input validated at the boundary through Zod and errors that say what went wrong without leaking internals.
JWT or server sessions, password hashing with a modern algorithm and transparent upgrade of legacy hashes, and admin-controlled revocation where you need to end someone’s session on demand.
Permissions defined once and enforced consistently across routing, UI and API, including multi-role products where several roles see overlapping but different slices of the same data.
PostgreSQL, MySQL and MongoDB. Schemas modelled for real query patterns, migrations in version control, and indexes chosen from the queries rather than guessed.
Signature verification, deduplication by event id and explicit state machines so a retried delivery cannot double-apply. Retrying job queues with dead-lettering for the work that must not be silently dropped.
Health checks, structured logging, audit trails for sensitive actions, strict environment validation at boot, and automated backups with a restore path that has actually been tested.
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 processes webhooks idempotently with Svix signature verification, dedupe by event id and a received to processed to failed state machine, so a retried delivery cannot double-apply. Behind it sit a retrying background-job queue with dead-lettering, audit logs on sensitive actions, strict environment validation and a scheduled backup sidecar with disaster-recovery tracking.
Read the Commit case studyThe e-commerce build hashes with Argon2id and transparently upgrades legacy hashes on the next successful login, centralises sessions, CSRF and rate limiting in one security helper, and idles sessions out after thirty minutes.
Read the e-commerce case studyAt NSEG Pvt Ltd I implemented JWT session authentication with admin-controlled revocation, so an administrator can invalidate a user’s active session on demand, alongside role-based access control over which routes each user type can reach.
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.
Yes. The API is a product in its own right. You get documented endpoints, predictable error shapes and a staging environment to build against while it is still being written.
My production work is REST, and for most products that is the right answer. If you already run GraphQL I can work within it, but I would not introduce it without a reason you can state.
Yes. A short engagement scoped in days is the usual shape: a read-through, a written list of what is actually wrong ordered by risk, and then the fixes you decide are worth making.
Slow queries get diagnosed from query plans rather than guessed at. That usually ends in indexes, a schema change or removing an N+1 the ORM was hiding, and the fix is measured before and after.
Yes, and it is usually a mistake to separate them. Containerised deploys with Docker and Nginx on a Linux VPS, CI that ships on merge, TLS, health checks and automated backups.
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.