Two questions before any architecture.
When I am sketching a new system, two questions come before everything else. How big is this thing going to get? And how soon are we going to know? When both answers are firm, the architecture writes itself. When the second answer is honestly, we will find out in a few weeks, you cannot pick a stack that only works in one of the directions.
BizzDeck is a SaaS for restaurant operators. The founders had a credible plan to grow it and an honest answer to the second question, which was that the next month or two depended on conversations they had not had yet. That is the kind of shape serverless was originally meant to handle, and so that is what we used.
Idle is the price you pay.
With containers, you are paying for the floor. The boxes are running whether anyone shows up or not. With serverless, you are paying for the ceiling. The spikes when everyone shows up at once. The bet is which one is closer to the shape your real traffic takes.
Every architecture has a bill. The work is choosing which bill you would rather see.
For a founder still in pre-revenue, the idle bill is the one that hurts most. It arrives every month whether anyone has signed up or not. Serverless replaces it with a cold-start bill, which is something you can size, measure, and design around.
All the way down.
Compute, database, cache, queue, even the storefront. Every layer got picked for the same reason. It goes to zero when nobody is using it. The catch is that this only works if every layer behaves that way. One component that quietly holds a floor will wipe out the savings on the other four. So the discipline is not use serverless. It is use it everywhere or do not bother.
Each lane was documented as a contract rather than a vendor. The implementation behind two of those contracts changed during the build and the rest of the system did not notice. Spending an extra day on the contracts at the start bought a lot of optionality later.
The cold-start cost, named honestly.
The first request after idle takes a second or two. There is no real point pretending otherwise. The interesting question is which paths can afford that wait. Internal screens and back-office tools can. The operator is already at their desk and the experience is patient. Customer-facing paths cannot. For those I add a small, cheap warm route that keeps the lights on during business hours and lets them go dim at night.
Failure modes I refuse to forget.
Three things will quietly ruin a serverless bill if you are not watching. Egress costs from services talking across providers, which look free on the whiteboard. Queue triggers that fan out faster than the database can absorb, which take the system down at exactly the moment you wanted it to scale. And observability that does not survive that fan-out, so you cannot tell which of the two thousand executions actually failed. I size each of these explicitly and put an alarm on it before the second deploy.
What I would do if traffic landed tomorrow.
Having a way out is part of the design, not a sign that the design was wrong. If traffic does land, the first lane to move off serverless is the heaviest read path, where the cold-start cost stops being amortised across the day. The light paths and the back office stay where they are forever. The aim is never to be loyal to a paradigm. The aim is to be honest about which paradigm is paying back this month.
Serverless is not a worldview. It is a bet on which kind of bill you would rather sign.