Choosing Node.js Hosting for a SaaS: What Actually Mattered vs. What I Thought Would

The Problem #

Choosing where to host a production Node.js API as a solo developer meant weighing a handful of platforms, and I initially framed the decision almost entirely around hosting cost per month — which turned out to be the wrong primary axis for how the decision actually played out afterward.

Context #

This is a small-to-medium API with real users depending on it (dispatchers, drivers), maintained by one person who also has to handle deploys, incident response, and everything else — there's no dedicated ops time to spend fighting infrastructure.

What I Tried #

Compared several providers mostly on price-per-instance-hour and picked the cheapest option that met the basic requirements.

What Went Wrong #

The cheapest option had a deploy process that required more manual steps than I'd accounted for, and its free/cheap tier had cold-start behavior that occasionally meant a driver's first request after idle time hit a multi-second delay — a real UX problem for a time-sensitive delivery app, not just an inconvenience.

The Solution #

Moved to Render specifically for git-push-to-deploy simplicity and more predictable instance behavior, accepting a higher monthly cost in exchange for fewer manual deploy steps and fewer cold-start surprises — a trade-off that's clearly correct for a solo developer's actual constraint (time and attention), even though it looks worse on a pure price comparison.

# render.yaml — deploy is "push to main", not a manual runbook
services:
  - type: web
    name: delivery-api
    env: node
    buildCommand: npm install
    startCommand: npm start

Why It Works #

For a solo developer, the scarce resource isn't the marginal hosting dollar — it's attention. A hosting choice that removes manual deploy steps and cold-start unpredictability trades money for exactly the thing that's actually constrained, which is the correct trade for this specific situation even though it wouldn't necessarily be for a team with dedicated infrastructure time.

Lessons Learned #

"Cheapest that meets the requirements" isn't the same question as "cheapest given what my actual time is worth as the only person who'll fix it at 11pm." I priced the wrong variable the first time.

What I Would Do Differently #

I'd weight deploy simplicity and operational predictability explicitly against price from the start, instead of defaulting to price as the primary axis and re-deriving the real priorities after hitting friction.

Related Concepts #

Git-based deploy workflows, cold starts on managed platforms, solo-developer operational trade-offs.