Node.js development
The strongest argument for Node is not performance. It is that one engineer can own a feature from the database to the interface without switching languages — and on a small team, that is worth more than any benchmark.
Discuss your projectWhen we reach for it
- Teams already writing TypeScript on the front end, where sharing types end to end removes a whole class of bug
- API and integration work — talking to many external services concurrently, which is exactly what the event loop is good at
- Real-time features: websockets, live updates, collaborative surfaces
- Serverless functions, where cold start time matters
When we don’t
- CPU-bound work — image and video processing, heavy numerical computation — which belongs in a worker in another language
- Estates already standardised on .NET or Java, where adding a second runtime buys nothing and costs hiring flexibility
- Data science and machine learning pipelines, where Python’s ecosystem is not close to matched
This half is the useful one. A firm that has never declined to use a technology has never chosen one.
What we have learned about the parts of Node.js that bite — written from projects rather than from documentation.
One language, shared types
The practical benefit of TypeScript on both sides is not elegance, it is that the contract between front end and back end is checked by the compiler. Rename a field on the server and the front end fails to build rather than failing in production at 4pm on a Friday. On a small team without a dedicated integration testing layer, that is a substantial share of the bugs that would otherwise reach users.
We define the schema once — usually with Zod — and derive validation, types and API documentation from it. Documentation that is generated from the code cannot drift from the code, which is the only kind of API documentation that stays true.
The single-threaded reality
Node handles thousands of concurrent connections comfortably as long as none of them asks it to do sustained computation. A single expensive synchronous operation blocks everything, and the symptom is not a slow endpoint, it is the entire service becoming unresponsive.
So anything CPU-heavy goes to a queue and a worker process, and the worker is not necessarily Node. This is a boring, well-understood pattern, and the projects that get into trouble are the ones that never drew the line at all.
Dependencies are the risk
The npm ecosystem is Node’s greatest advantage and its most reliable source of incidents. A typical application has a very large transitive dependency tree, any of which can be abandoned, compromised or licensed in a way your legal team would object to.
We keep direct dependencies few and deliberate, prefer the standard library where it is adequate, run automated vulnerability and licence scanning in CI, and pin versions with a lockfile that is actually committed. None of this is clever; all of it is the difference between a routine update and an emergency.
Node.js, applied
The shapes of system this technology is actually good at, rather than the ones it is capable of.
Usually alongside
- TypeScript
- Fastify
- Express
- Prisma
- Drizzle
- Zod
- BullMQ
- PostgreSQL
- Redis
- REST and GraphQL APIs with generated documentation
- Background workers and scheduled jobs on a real queue
- Integration layers between systems that were never designed to talk
- Real-time features over websockets
- Serverless functions and edge handlers
Node.js, answered
Is Node.js fast enough for production workloads?
For the work most business applications actually do — waiting on a database, calling other services, serialising JSON — comfortably, and its concurrency model suits that shape of work well. Where it is the wrong tool is sustained computation: image or video processing, large numerical work, anything that occupies the CPU for a meaningful period. That work goes to a queue and a worker, and the worker does not have to be Node. Projects get into trouble when nobody draws that line, not because the runtime is slow.
Node.js or Python for the backend?
Node if your front end is already TypeScript, because sharing types across the boundary removes a real class of bug and lets one engineer own a feature end to end. Python if the work is data-heavy, statistical or machine-learning adjacent, where its ecosystem has no serious competitor. If neither applies strongly, pick the one your team can hire for and maintain — that consideration outlives any technical difference between them.
How do you handle security in the npm ecosystem?
Few, deliberate direct dependencies rather than a package for every small task; the standard library where it is adequate; automated vulnerability and licence scanning that fails a build on a known critical issue; and a committed lockfile so builds are reproducible. We also review what a new dependency actually pulls in before adding it, because the transitive tree is where the exposure lives. This is unexciting work and it is the difference between a routine update and an incident.
Where this shows up
- BuildCustom Software DevelopmentCustom platforms, marketplaces and SaaS. We write the parts that are specific to your business and buy the parts that aren’t.Read more
- BuildWeb Application DevelopmentDashboards, portals and internal tools that hold up under real data volumes — not a prototype that falls over at ten thousand rows.Read more
- RunCloud & DevOpsDeploys that are boring on purpose. Infrastructure as code, real environments, and a bill you can read line by line.Read more
Building with Node.js?
Whether it is a new build, a takeover or a second opinion on an architecture someone else chose — the first conversation is free and we will tell you if the stack is wrong for the job.