Backend and APIs
Backend and API development
Hono or NestJS over Postgres with Drizzle, typed from the schema through to the client.
An API written by the person who also writes the app that consumes it is a different artefact from one written across a ticket boundary. The response shapes are the ones the screens actually need, and the round trips that should have been one request are one request.
I build these as REST over Hono for new work, NestJS where a team already has it, with Drizzle over Postgres and Zod at the edges. On VM Academy the response types are generated out of the server repository and committed into the client, so a client one commit behind fails at compile time instead of failing quietly in production. That mechanism matters more than any framework choice on this list.
Auth, payments and email are the three things every product needs and every product underestimates. I have done passwordless sign-in with Better Auth, Firebase auth on older codebases, Stripe, Razorpay and Juspay on the payments side, and Resend for the transactional mail nobody remembers until launch week.
What you end up with
- A typed REST API with the response types shared with the client
- Postgres schema and migrations under version control
- Authentication, sessions and roles
- Payment integration and the webhook handling that goes with it
- A deploy you can run, with the environment documented
Where this has shipped
VM Academy
Personal, 2026
A multi-skill learning platform. Three repositories, one API, one database.
How it is built
Native Ninjas
Personal, 2026
A typed monorepo starting point: Expo, Hono and TanStack Router in one graph.
How it is built
Kasoti
Personal, 2026
A mock-test app for one exam candidate, built as a real monorepo anyway.
How it is built
Questions
Can you work against our existing backend?
Yes, and often that is the better arrangement. Self Ride was built from an empty folder against a GraphQL backend somebody else owned, and Multitax and LexVid were both feature work on established APIs. What I ask for is the schema and someone to answer questions, not control of the server.
REST or GraphQL?
REST for most products, because the cost of GraphQL shows up in caching, authorisation and the query your client did not mean to send. I have shipped GraphQL clients against backends that had already chosen it and it was fine. For a new API with one or two clients, REST with typed responses gets you the same safety with less machinery.
What about scale?
Almost nothing I have built needed a scaling answer on day one, and building for a load you do not have is the most expensive mistake a small product makes. One server and one database, sized properly, carries further than people expect. When there is real traffic, the fix is measurement first: the slow thing is usually one query or one missing index, not the architecture.
Tell me what you are building.
A sentence about the product and where it is stuck is enough to start. I answer every mail myself, including the ones where the answer is that I am not the right person.