Backend & API Development
I design and build backend systems: REST and GraphQL APIs, microservices, real-time features over WebSockets, background job pipelines, and the database schemas underneath them.
Stack is Node.js (NestJS or Express) or Python (FastAPI, Django), on PostgreSQL or MongoDB. I have built the backend for a payment gateway, a real-estate CRM, an AI video pipeline and a distributed task system — the kind of work where getting the data model wrong is expensive.
Node.js or Python — which should you use?
It depends on what the service actually does, and I will give you a straight recommendation rather than defaulting to whatever I feel like writing.
Node.js with NestJS is my default for API-heavy products, especially where the frontend is already TypeScript — one language across the stack, shared types, and a mature ecosystem for the boring things (queues, auth, ORMs). Python with FastAPI wins when the service touches data science, ML models, or a Python-only library, and Django wins when you want an admin panel and an ORM out of the box rather than assembled.
If your team already knows one of them, that usually outweighs everything above. A stack your developers can maintain beats a marginally better one they cannot.
Do you build microservices or a monolith?
A monolith, usually — and I will say so even though microservices sound more impressive on a proposal.
Microservices solve an organisational problem: multiple teams needing to deploy independently. If you have one team, they mostly buy you distributed-systems failure modes in exchange for nothing. I have built and operated microservice architectures with gRPC and message queues, including splitting a monolith when the split was genuinely warranted, so this is not inexperience talking.
Where I do reach for separate services early is around genuinely different workloads — a video rendering worker, a payment processor, an ingestion pipeline — because those have different scaling and failure characteristics from your CRUD API.
What about real-time features?
Live updates, presence, notifications and collaborative editing over WebSockets (Socket.io) or gRPC streams, with the state and reconnection handling that makes them survive a flaky mobile connection.
The hard part of real-time is rarely pushing the message — it is what happens when a client misses one. I build these with an authoritative server state and a reconciliation path, so a dropped connection resolves to correct data instead of a silently stale UI.
How do you handle the database?
The schema gets designed before the endpoints, and it gets designed for the queries you will actually run. Most performance problems I get called in to fix are schema problems wearing a caching costume.
PostgreSQL by default, with real constraints and foreign keys — the database is the last line of defence for data integrity and I use it as one. MongoDB where the document model genuinely fits. Migrations are versioned and reversible, and I do not make schema changes by hand on a production console.
What you get
- API with documented endpoints (OpenAPI/Swagger or GraphQL schema)
- Database schema with versioned, reversible migrations
- Authentication, authorisation and role handling
- Background job processing and scheduled tasks
- Integration and endpoint tests for the critical paths
- Dockerised local setup so a new developer can run it in one command
- Deployment pipeline and environment configuration
Tools I use for this
A good fit if
- A product that needs an API built properly the first time
- A frontend team without a backend engineer
- An existing backend that has become slow, fragile or impossible to change
- A mobile app needing a server and API behind it
- A monolith that genuinely does need splitting, with someone who has done it
Not a fit if
- Pure data engineering or analytics pipelines — Spark, dbt, warehouse modelling is a different specialism
- Machine learning model training; I integrate and serve models, I do not build them
- DevOps-only engagements with no application work — a dedicated SRE will serve you better
- Projects wanting a backend in Go, Rust, Java or .NET; I would be learning on your budget
Work that shows this
Paymish Payment Gateway
A secure, low-latency payment gateway processing $2M+ monthly, with multi-bank integrations, fraud detection and 99.99% uptime.
Read the case studyTaskOpad
A comprehensive task management system for individuals and teams.
Read the case studyCatch-up
An automated SaaS platform to source clips, generate commentary in your voice, render an avatar, and publish.
Read the case studyQuestions clients ask
Can you work with our existing frontend team?
Yes — this is a common arrangement. I build and document the API, agree the contract with your frontend developers up front (usually an OpenAPI spec or GraphQL schema before implementation), and give them a staging environment to build against. Async collaboration across timezones works fine as long as the contract is written down.
Do you write tests?
For the paths where a bug costs real money — payments, auth, data integrity, anything with a webhook — yes, and they run in CI on every push. I do not chase a coverage percentage across the whole codebase; that spends your budget on tests for code that was never going to break.
How do you handle API security?
Input validation at the boundary, parameterised queries, rate limiting, secrets in environment configuration rather than the repository, dependency scanning in CI, and least-privilege database credentials. For anything touching payments or personal data I will also walk you through what the application does and does not protect against, in plain language, so you can make an informed call on where to spend more.
Can you document an API nobody documented?
Yes, and it is a good first engagement if you are unsure about working together. I read the codebase and produce an accurate OpenAPI specification plus a written map of what exists — often surfacing dead endpoints and undocumented behaviour along the way. It is fixed-scope and low-risk on both sides.
Need backend & api development?
Tell me what you're building and what's in your way. I reply within 24 hours with honest questions and a rough estimate — no sales sequence.