I went all-in on serverless for a side project. The first month was magical — zero ops, auto-scaling, pay-per-use. Then the cold starts hit, the debugging got painful, and the bill stopped making sense. Here’s what nobody tells you.
Serverless is genuinely great for certain workloads. But the hype machine has convinced developers it’s the answer to everything. It’s not.
The promises vs reality
Promise: “You never think about servers again!” Reality: You think about servers less, but you think about timeouts, cold starts, memory limits, and execution duration constantly.
Promise: “It scales automatically!” Reality: It scales automatically… including your bill. One recursive Lambda function and you’re looking at a surprise invoice.
Promise: “You only pay for what you use!” Reality: True for low traffic. At moderate-to-high traffic, a $20/month VPS often beats hundreds in Lambda costs.
Cold starts are real
Your API endpoint takes 200ms normally. But after 15 minutes of no traffic, the next request takes 2-5 seconds. For a user clicking a button, that’s an eternity.
Workarounds exist (provisioned concurrency, keeping functions warm), but they add cost and complexity — defeating the “simple and cheap” selling point.
Debugging is a nightmare
Something fails in production. Your debugging experience:
With a server: SSH in, check logs, reproduce the issue, fix it.
With serverless: Open CloudWatch, search through 47 log groups, find the invocation ID, realize the error happened in a different function that was triggered by an event from another function, spend 30 minutes correlating timestamps across services, wish you had a server.
Distributed tracing tools help, but they’re another service to set up, pay for, and maintain.
Vendor lock-in is real
Your Lambda functions use:
- API Gateway for routing
- DynamoDB for data
- SQS for queues
- S3 for storage
- EventBridge for events
- Step Functions for orchestration
Want to move to GCP? Rewrite everything. Want to run locally? Good luck simulating all of that.
“But we use the Serverless Framework!” — You’re still calling AWS-specific APIs in your code.
The bill surprise
Serverless pricing is per-invocation and per-duration. This is cheap at low scale. But:
- A function that runs 1M times/month at 500ms with 512MB memory ≈ $10/month
- Scale that to 100M invocations ≈ $1,000/month
- A $40/month VPS handles the same load easily
The crossover point is lower than most people think.
When serverless is the right call
- Sporadic workloads — a function that runs twice a day (cron jobs, webhooks)
- Event processing — image resizing, file processing, triggered by uploads
- MVPs — when you have zero traffic and zero budget
- Glue code — small functions connecting services together
When it’s the wrong call
- APIs with consistent traffic — a server is cheaper and faster
- Anything latency-sensitive — cold starts kill user experience
- Complex applications — the debugging overhead isn’t worth it
- Teams without cloud expertise — the learning curve is steep
The honest recommendation
Start with a simple server (a $5 VPS, a Railway app, a Fly.io machine). If you hit a specific scaling problem that serverless solves, extract that piece. Don’t start serverless and work backwards.
Related: Best Hosting for AI Side Projects · Best Cloud GPU Providers