Serverless computing for startups
Serverless is often argued about as though it were a philosophy. It is narrower than that: you stop paying for capacity and start paying for execution, and you give up control of the runtime in exchange. Whether that trade is good depends almost entirely on how spiky your workload is and how small your team is.
The arithmetic behind the argument
A server provisioned for a job that runs two hours a night is idle for 92% of what you pay for. That is the case serverless answers well, and it is why the pattern fits so much of what an early-stage product does: scheduled jobs, webhook handlers, image processing, notification fan-out, admin tasks, anything triggered rather than continuous.
Read the top row just as carefully. A service with steady round-the-clock traffic uses everything it is billed for, and moving it to per-execution pricing usually costs more, not less, while adding constraints it did not have.
Where it genuinely helps a small team
The saving that matters to a startup is rarely the infrastructure bill — at early-stage volumes both options are small. It is the work you do not do: no instances to patch, no capacity to size before you know the traffic, no autoscaling policy to tune, no one on call for a host that has run out of disk. For a team of four, that is a meaningful fraction of an engineer.
Scaling to zero has a second effect worth naming: a feature nobody uses costs nothing. That changes what it is reasonable to ship and leave running, which for a product still looking for its shape is worth more than the unit economics.
What it costs you later
Cold starts
A function that has not run recently pays initialisation before it does any work. For an asynchronous job this is irrelevant. For a request a person is waiting on, it is the difference between fast and occasionally slow, and “occasionally” is the hard part to diagnose.
Local development stops being local
Once the application is a set of functions joined by managed queues, triggers and permissions, it can no longer be run wholly on a laptop. Teams end up with per-developer cloud environments, which works but is a cost and a discipline nobody budgets for at the start.
Debugging moves to logs
There is no process to attach to. Whatever you did not log, you cannot inspect — so structured logging and tracing stop being good practice and become the only way to see what happened.
Portability
Functions are portable; the triggers, queues, identity model and event formats around them are not. This is a real lock-in and mostly an acceptable one at an early stage, provided it is a decision rather than a discovery.
A reasonable default
Most products end up mixed, and that is the right answer rather than a compromise: a conventional always-on service for the request path where latency is visible to a user, and serverless for everything triggered, scheduled or bursty around it. Choosing per workload takes an afternoon. Choosing one for the whole system takes a rewrite to undo.
Where this fits
The service is Serverless Computing, and the sector context is Startups. It is one option inside Cloud-Native Applications; if the question is which workloads should go where before anything is built, that is Cloud Advisory Services.
