Six months ago we ran our API on a single beefy server. It worked. It was simple. We knew exactly what it cost.

Today we run it on serverless functions, and we'd make the same call again but not for the reasons you'd expect.

What "serverless" actually solved for us

The pitch is usually about scale. We didn't have scale problems. We had operational problems.

Our team is five people. Two of us were spending half a day a week on server health, log rotation, deploy coordination, and the occasional 3am page. That's roughly a quarter of an engineer, gone, every week. Serverless removed almost all of it.

What it cost us

Three things, in order of how much they hurt:

Cold starts. First request to a function after idle takes 600–900ms. We mitigated with provisioned concurrency on the hot paths, but that erased some of the cost savings.

Local development. "It works on my machine" gets harder when the platform isn't on your machine. We invested in good emulation tooling.

Cost predictability. A single buggy retry loop can quietly cost you $200 in an afternoon. We added per-function budget alerts.

Who shouldn't do this

If you have steady traffic and small team scope, a single server is probably cheaper, simpler, and faster. Serverless wins when traffic is spiky and operational time is your scarce resource. We were the second case.