Node.js development
Most Node conversations arrive as one of three: an API to build, a realtime feature holding many open connections, or an inherited service that has become hard to change. Node is genuinely good at the first two. Heavy computation belongs in a compiled runtime or Python, and we settle that before anything gets written.
01Capabilities
Four server jobs where Node earns the slot
Node.js is a runtime, not an architecture. This page is about whether your server should run on it. If the real question is the language or the type system rather than the runtime, JavaScript and TypeScript are the pages for that. Four shapes of work account for most of what we build here.
- APIs
Product APIs and back ends
REST and GraphQL services sitting behind a product interface, usually next to a React front end as part of a web build. Many short requests that are mostly waiting on a database or a third party is the ordinary shape of product traffic, and it is the shape Node handles well on modest hardware.
- Realtime
Realtime and event-driven features
Live dashboards, chat, presence, notifications, and price or status updates pushed over WebSockets, the kind a fintech trading screen or an operations console needs. Holding thousands of mostly idle connections open is what an event loop is genuinely good at, and it is the case where Node wins on merit rather than convenience.
- Integration
Integration and gateway layers
The layer between your product and everything it talks to: payment providers, messengers, ERPs, and the carrier and marketplace APIs behind logistics platforms. This is platform integration work, where the engineering is idempotency, retries, rate limits and reconciliation rather than the happy path.
- Extraction
Services split out of a larger system
Pulling a function that needs to scale, deploy or fail on its own out of a bigger application and running it as its own service. Node's small footprint per process makes that cheap, and the rest of your stack does not have to be JavaScript for it to work. We build them under an ISO 27001:2022 certified information-security management system.
02Case studies
Two systems with this runtime underneath
Two production systems, one in commodities trading and one in foodtech.
See all case studies
TradingSoftware for trading with Smart contractsOur client, an experienced commodities trader, came to unicrew with a detailed PRD (Product Requirements Document) to develop the trading platform.
FoodtechDigital Transformation in Food IndustryOur client is an innovation-oriented group of food companies based in Germany that produces and distributes a wide range of products for well-known retail businesses and food services.
03Fit
Where the server work should actually live
Node.js is a good default for work that is mostly waiting and a bad default for work that is mostly computing, and that single distinction settles most of these conversations before anyone's language preference enters the room. Every row below names the move we recommend, from Node.js itself to Go, Python or the stack your team already runs.
| Your situation | What we recommend |
|---|---|
| A product API with many short requests, mostly waiting on a database, a queue or a third party | Use Node.jsThis is the case the event loop was built for, and it holds concurrency well without much hardware. |
| Realtime work: live updates, chat, presence, many connections open but idle | Use Node.jsIts strongest technical case, and the one we would defend on the engineering rather than on convenience. |
| Heavy computation in the request path: media processing, large exports, cryptography, big numeric work | Move that partOne long calculation blocks everything queued behind it. Put it in a worker, or start from Go (Golang) or .NET. |
| A throughput-critical network service you want to ship as one deployable binary | Different pageUsually Go (Golang). Predictable memory, real threads and a single static binary beat Node here, and the operational story is simpler. |
| The real product is a data pipeline or a machine-learning feature | Different pageOur Python page. The libraries, the tooling and the people all live there, and a Node reimplementation buys you nothing. |
| A small internal tool, one owner, and nobody who wants to be on call for it | Your existing stackBuild it on whatever your team already runs. A new service, a new pipeline and a new rota cost more than the tool is worth. |
Scope
What we own on a Node engagement is the runtime decision and what follows from it. Where the heavy work goes. What the service does under load. Whether your own team can still change it after we stop. unicrew has been building server software since 2012, with 100+ senior in-house engineers across six countries. The work runs under an ISO 27001:2022 certified information-security management system. Where a smaller job solves the problem, that is the job we recommend.
04Delivery
The order we put a new service through
Four things we do early, because all four are expensive to retrofit into a service that is already live.
- Find out where the time actually goesBefore the architecture conversation, we measure what the service is doing while a request is open. If the answer is computing rather than waiting, the runtime is the wrong argument, and we settle that in week one rather than in month five.
- Pin down the dependency surfacenpm is the largest supply-chain and upgrade liability in a Node project. We prefer boring, widely used packages, keep a written inventory of the ones that actually matter, and put audit and update checks in the pipeline instead of meeting the problem at the next advisory.
- Types and contracts at the boundariesTypeScript across the service, with one definition of the API shape shared with the front end rather than copied into it. On an inherited JavaScript codebase we add types at the edges first, which buys refactoring safety without a big-bang conversion.
- Make it operable under loadStructured logging, tracing, health checks, and explicit limits on concurrency and payload size. A Node service under pressure degrades quietly instead of crashing loudly, so without instrumentation the first person to notice is a user. Test automation goes in alongside, through the same QA practice as our own projects.
05Client voices
Two clients on working with us
06Stack
The pieces a service like this is wired to
The decisions that usually arrive with this one, each with a page of its own.
07Questions
What buyers ask before choosing a runtime
Answered the way we would answer them live. If yours is not here, it is a good first message.
Yes, and on a live product it is often the sensible shape. Our engineers own the runtime decision too, because Node gets picked for the wrong reason more often than most technologies. An architect outside the delivery team reviews the design, and the work goes through the same QA practice as our own projects. Team extension is managed teams; handing over the outcome is custom software development.
It comes down to what the service spends its time doing and who will maintain it. If the work is mostly waiting and your people already write JavaScript, Node keeps one language across the stack and one definition of the API. If it is throughput-critical, or you want a single binary with predictable memory, Go (Golang) is the better call, and we build that service in Go. Mixing both is normal.
For work that is mostly waiting, yes, and that covers most product APIs. The failure mode is not throughput. It is one heavy calculation blocking every request queued behind it. So we look for that work explicitly, move it to a worker thread or a separate service, and set concurrency limits from the start. Scaling out is straightforward once the process holds no state of its own.
Yes, and deliberately rather than reluctantly. The first pass is a dependency audit, because an abandoned package is the most common live risk in an inherited Node project. Then tests around the paths that carry money or data, and TypeScript at the boundaries. Where the runtime and framework versions are themselves the blocker, that is a modernization conversation rather than a feature one.
A scoping call with an engineer rather than a salesperson. If the service already exists we ask for read access to the repository and whatever monitoring you have, because an hour in the code is worth several in discussion. What comes back is written: the runtime decision, what we would build or change first, and what stays untouched. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Deciding which runtime the server belongs on?
Tell us what the service has to do, what it talks to, and what your team already writes. You will get an engineer's read on it, with the runtime matched to the work. Handing over the whole outcome is custom software development.