Next Project Contacts
A server rack in a dark machine room, its front a dense field of looped patch cables and indicator lamps.

Backend

Node.js for APIs, jobs and integrations.

APIs, jobs and integrations on Node. One language across the stack, explicit module boundaries, and background work that does not live inside a web request.

Contacts Technology map

Node is our default for product backends, mostly for a boring reason: the same people can move between the API and the interface without changing language, and the contract between them can be one shared type instead of two hopeful ones.

A bank of small brass valves on a dark pipe run, one handle turned open.

What decides the outcome here

  1. What we build on it

    HTTP and GraphQL APIs, webhook receivers, integration layers between systems that were never designed to meet, scheduled jobs, and the queue workers behind anything a user should not have to wait for.

  2. Modules with edges

    A backend becomes unmaintainable when every file can import every other file. We split by domain — billing, accounts, catalogue — and let those talk through defined interfaces. It costs a little discipline early and it is the reason a feature can later be extracted or replaced without a rewrite.

  3. Work that belongs in a queue

    Sending mail, generating documents, calling a slow third party, recalculating a report: none of that belongs inside the request that triggered it. It goes to a queue with retries, a dead-letter path and an alert when the backlog grows. We use Redis for that in most projects.

  4. Failure is designed, not discovered

    Every outbound call has a timeout. Every retry is idempotent or it is not a retry. Every error that reaches a user is a message someone wrote deliberately. Logs carry a request id all the way through, so a support ticket can be traced instead of reproduced.

  5. Honest limits

    Node is a poor fit for sustained CPU-heavy work — image pipelines, large numerical jobs, anything that pins a core for seconds at a time. That work goes to Python or Go as a separate service, and we say which parts we would split before we start.

    Typed throughout with TypeScript; deployed by the pipelines under CI/CD.

Discuss the next step

Tell us what you want to build or improve. We reply with a plan, an indicative budget and a start date.

Contacts Browse the service map