Nobody can size a launch.
BizzDeck sells software to restaurants. Before launch, every traffic number in the plan was a guess. Ten restaurants in month one, or a hundred? Nobody knew, and pretending otherwise would have been the most expensive decision on the project.
The traditional answer is to provision for the optimistic guess and pay for the fear. Rent a server big enough for the launch you hope for, then watch it sit mostly idle while you find out what the real number is. We went the other way and made the bill follow the truth.
Before product-market fit, the enemy isn't load. It's paying for load that never came.
Idle is the real cost.
A server bills you for existing. At 3am, with zero orders anywhere in the system, the meter runs at full speed. Restaurant traffic makes this worse than usual: a lunch spike, a dinner spike, and long stretches of near-silence in between. On an always-on box, most of what you pay for is the silence.
So the backend became functions. Each request pays for its own execution and nothing else. When no restaurant is open, the compute bill is effectively zero. Not discounted, zero. When a food festival triples dinner traffic, capacity is simply there, without anyone having planned for it in a spreadsheet three months earlier.
Cold starts, without the sales pitch.
The first request after a quiet spell pays a startup tax. Anyone who tells you this doesn't exist is selling something. The honest version: it exists, it's manageable, and where it lands matters more than how big it is.
The paths a human stares at, like opening the menu or placing an order, got kept small and warm. The paths a machine calls, like payment webhooks and report generation, can absorb a slow first hit because the caller retries anyway. Splitting the two took an afternoon of thought and saved every later conversation about "is serverless slow".
The bill follows the kitchen.
This is what "scales with service hours" means on the BizzDeck dossier. It isn't a performance boast. It's an accounting statement.
When I'd say no.
Serverless is not a default; it's an answer to a specific question. Steady, predictable, high-volume load is usually cheaper on a plain server. I've moved workloads off functions for exactly that reason. Long-lived connections, heavy in-memory state, latency budgets measured in single milliseconds: all better served by something that stays running.
The question it answers well is the launch question: unknown demand, spiky shape, a founder who would rather spend on finding customers than on hosting the absence of them. That was BizzDeck in month one.
The month after launch.
The first month's compute bill was small enough to look like a rounding error, because the traffic was small, which is the point. The platform found its footing without hosting costs breathing down its neck, and when the busy evenings arrived, nothing needed re-architecting to serve them.
An architecture that scales to zero is really a runway extension. For a launch whose only certainty is uncertainty, that's the feature that matters.