Blocked event loop
Synchronous work in a request handler, so one heavy operation stalls every other request on the process.
[ Development / Node.js Development ]
Node services that hold up under real load.
Node makes it easy to ship an API in an afternoon and easy to block the event loop without noticing. I build the version that survives its first traffic spike and tells you clearly what broke when something does.
TypeScript by default · Tests included · Fixed scope
TypeScriptby default
Testsincluded, not extra
Observablelogs, metrics, traces
You ownthe repository
[ What goes wrong ]
How Node services fail in production.
Rarely dramatically. Usually a slow degradation nobody can explain from the outside.
Memory that only climbs
A leak that forces a restart every few days, managed with a scheduled reboot instead of a fix.
Unhandled promise rejections
Errors swallowed silently, so failures show up as missing data rather than alerts.
No connection pooling
Database connections opened per request until the database refuses new ones.
No validation at the edge
Untrusted input reaching business logic, which is both a bug source and a security problem.
Logs you cannot search
Unstructured console output, so diagnosing an incident means reading text by eye.
[ How it works ]
Scope, build, operate.
01 — Week 1
Scope
What the service does, expected load, what it talks to and who runs it afterwards. Written scope and fixed price before code.
02 — Week 2+
Build
Typed, tested and instrumented from the start, shipped in reviewable pull requests to a staging environment.
03 — Launch
Deploy & watch
Containerized, deployed through a pipeline, with health checks, metrics and alerts wired up before real traffic arrives.
[ What actually changes ]
How I build Node services.
The difference between a prototype and a production service is almost entirely in the second column.
The service
- REST and GraphQL APIs — versioned, documented and authenticated with something better than a shared key.
- Input validation at the boundary — schema-validated, so untrusted data never reaches business logic.
- Background workers and queues — slow work off the request path, with retries and dead-letter handling.
- Real-time features — websockets or server-sent events, with reconnection handled properly.
- Database access — pooled, indexed and migrated reversibly.
Production readiness
- Structured logging — JSON with request correlation, so an incident is searchable rather than readable.
- Metrics and tracing — latency, error rate and throughput visible before customers report a problem.
- Graceful shutdown — in-flight requests finished on deploy instead of dropped.
- Health and readiness checks — so orchestrators route traffic only to instances that can serve it.
- Load verification — tested at expected peak before launch, not discovered during it.
[ Example engagement ]
Nightly restarts replaced with an actual fix.
An API restarted every night by cron to clear a memory leak nobody had traced. Profiled under production-like load and fixed in a single change.
Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.
1root cause found
0scheduled restarts since
37%lower p99 latency
3 daysto diagnose and fix
[ Free · no obligation ]
Something failing in production?
Describe the symptom — memory growth, latency spikes, mystery restarts. You get an initial assessment and a fixed price to fix it properly.
[ Pricing ]
Pricing that fits your budget.
Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.
Fixed project price
Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.
Monthly retainer
For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.
Hourly for small jobs
For a single bug or a short task where writing a full scope would cost more than simply doing the work.
Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.
[ Questions ]
Common questions.
Which framework do you use?
Whatever fits and whatever you already have. For new services I lean toward small, well-understood frameworks over large ones, because the framework is rarely the interesting part of the problem.
JavaScript or TypeScript?
TypeScript for anything with a lifespan beyond a prototype. The cost is a little friction up front; the benefit is entire categories of runtime error that simply stop happening.
Can you fix an existing service?
Yes, and production diagnosis is a good part of this work — memory leaks, event-loop stalls, latency spikes and mystery restarts.
Node or Python for our API?
Node suits real-time features and teams already writing TypeScript on the front end. Python suits data and machine learning work. Both are fine choices, and I build in either.
Do you handle deployment?
Yes. Since I do the infrastructure side too, the service and its runtime environment get designed together rather than handed over separately.
[ Related services ]
Related development work.
Python & FastAPITyped, async Python APIs and data services.React DevelopmentComponent work, state architecture and performance fixes.Next.js DevelopmentApp Router, rendering strategy and Core Web Vitals done right.Docker & ContainersContainerise an existing app so environments finally match.CI/CD & GitHub ActionsAutomated build, test and deploy pipelines with real rollbacks.AWS Server SetupProduction-ready VPC, compute, database and CI/CD from scratch.
[ Let's talk ]
Tell me what you're building.
Describe it in a few lines and you'll get a straight answer on scope, cost and timeline — same working day, from the person who'd actually build it.