On-screen

Narration

Anna: Sarah's engineers want Kubernetes. Her CFO wants the bill to stop growing. Both are arguing about the same decision from different ends.
Greg: And it isn't one decision. It's a sequence of them, revisited as the company grows, because the right answer at six people is usually wrong at sixty.
Anna: So we'll walk it in stages. What to do in the first year, when serverless earns its keep, what containers really cost, and when running your own hardware finally makes sense.
Greg: The trap is picking an architecture for the company you hope to become.

On-screen

Narration

Anna: When founders say "we need to pick cloud or on-prem," they're really deciding where compute, storage, networking and identity will live.
Greg: Exactly—and the answer can differ per layer. SaaS keeps you hands-off, PaaS gives you guardrails, and IaaS is the build-it-yourself toolbox.
Anna: Add in acronyms like SRE and questions about colocation versus true on-prem, and it's easy to lose clarity. Start by mapping what customers expect, what regulators demand and what your team can realistically operate.

On-screen

Narration

Anna: A few terms first, because these get used loosely. SaaS, PaaS and IaaS are software, platform and infrastructure as a service. As you move along that line you gain control and take on responsibility in equal measure.
Greg: Site Reliability Engineering, or SRE, is the discipline of keeping services available through automation and operational rigour.
Anna: Colocation means renting space and power in someone else's data centre. On-premise means the hardware sits in your own building, and so does the air conditioning problem.
Greg: And reserved instances trade a long-term commitment for a discount, where pay-as-you-go buys flexibility instead.

On-screen

Narration

Anna: Think of it in phases. For the first year, velocity wins. Keep the team shipping features and lean on managed services with generous free tiers.
Greg: By year two the picture changes. Usage is more predictable, so you can weigh reserved cloud spend against the fixed cost of leased hardware and the people to look after it.
Anna: From year three, hybrid patterns tend to emerge. A latency-sensitive workload or a data residency requirement justifies colocated equipment, while everything else stays cloud-native.
Greg: The mistake is jumping to phase three early, and paying the operational overhead years before the savings arrive.

On-screen

Narration

Anna: Serverless removes two jobs nobody on a small team has time for: patching infrastructure and planning capacity. Scaling just happens.
Greg: And paying per use keeps experimentation genuinely cheap. A food delivery beta with a hundred or so users might run fifty dollars a month, which means a failed experiment costs almost nothing.
Anna: The usual objection is lock-in, and it's fair, but it's manageable. Design around open APIs, export your data on a schedule, and script the replay into an alternative service.
Greg: Test that replay occasionally. An escape route you've never used is a hope, not a plan.

On-screen

Narration

Anna: In the first twelve months, speed beats everything—use the managed services that let you ship without hiring SREs.
Greg: Right, because you literally can't afford to hire SREs yet. A senior SRE costs $180k+ in salary alone, before tooling or on-call bonuses.
Anna: By year two, finance wants predictability. That's when you compare reserved cloud instances to colocated gear and understand your utilisation curves.
Greg: And as you approach Series B, you revisit the architecture—maybe customer data has to stay in-region, or latency targets push you toward an edge footprint.

On-screen

Start here → Need usable prototype in <5 minutes?
        │               ├─ Yes → Stay serverless / SaaS
        │               └─ No
        ↓
Team smaller than 3 engineers?
        │               ├─ Yes → Lean on managed services
        │               └─ No
        ↓
Strict compliance / data residency?
        │               ├─ Yes → Plan hybrid / colocation footprint
        │               └─ No → Keep optimising cloud setup

Narration

Anna: Here's a short decision path. Do you need a usable prototype in under five minutes? If yes, stay on serverless or SaaS and stop thinking about it.
Greg: If not, next question. Is the team smaller than three engineers? If so, lean on managed services, because you don't have the people to run a platform and build a product at once.
Anna: Then, do you have strict compliance or data residency obligations? If yes, start planning a hybrid or colocation footprint.
Greg: And if none of those apply, you're not choosing a new architecture. You're optimising the cloud setup you already have.

On-screen

Narration

Anna: Containers look like a packaging decision and turn out to be an operating decision. You need observability, image pipelines, security scanning and registry hygiene.
Greg: Those are real skills, and most pre-Series A teams don't have them in-house yet.
Anna: If you go ahead anyway, treat the platform as a product with its own budget. Cluster upgrades, policy automation, chaos testing, all of it competing for the same engineers who are meant to be shipping features.
Greg: It's a bit like deciding to roast your own coffee beans when nobody has worked out how to use the office machine yet.

On-screen

Narration

Anna: Self-hosting genuinely can cut per-unit costs, but only under conditions people forget to check: utilisation stays high and the rate of change slows down.
Greg: And before you claim the saving, budget for the rest of it. Redundant hardware, spares on a shelf, remote hands at the data centre, compliance audits.
Anna: The bigger shift is the responsibility boundary. Patching, access reviews, backups and capacity upgrades all become yours, end to end, at three in the morning included.
Greg: Write that shared responsibility down explicitly. Teams that skip this step discover the gaps during an incident rather than during planning.

On-screen

Narration

Anna: AWS Activate, Azure for Startups and Google Cloud credits can cover six figures of spend. Plan your workloads deliberately so that runway does real work.
Greg: But track the expiry dates and graduation thresholds. AWS Activate credits, for instance, run out after two years or when you raise a Series A, whichever comes first.
Anna: Mix in services with genuinely generous free tiers so you aren't burning credits on commodity things. Cloudflare's free CDN, Auth0's seven-thousand-user tier, that sort of thing.
Greg: And put the expiry in the finance calendar. The sudden post-credit bill is a well-known way to ruin a founder's Tuesday.

On-screen

Narration

Anna: Three questions to answer honestly before committing. Do you have repeatable continuous delivery, with automated tests and security scanning already working?
Greg: Can you monitor, patch and respond to incidents around the clock without burning out a three-person engineering team?
Anna: And are there regulatory or customer requirements that genuinely rule out managed services, as opposed to requirements someone assumes exist?
Greg: If your on-call rotation is really Sarah glancing at her phone during dinner, you have your answer. That's not a criticism of Sarah. It's just not a rotation.

On-screen

Narration

Anna: Serverless is a gift when you're still searching for product-market fit. No patching, no capacity planning—just deploy functions.
Greg: And the bill stays tiny while usage is modest. That food delivery beta with a hundred testers might cost $50 a month instead of thousands in idle servers.
Anna: The trade-off is vendor coupling, so script periodic API reviews, export datasets and rehearse migrations so an exit option stays alive.

On-screen

Narration

Anna: Tie the architecture review to funding milestones. At seed, at Series A, at Series B, check that the stack still matches your burn rate and the talent you actually have.
Greg: Run a total cost of ownership model that includes people, tooling and vendor support, and put a number on the opportunity cost of slower delivery.
Anna: That last one gets left out, and it's often the largest.
Greg: Then prototype the exit ramps. Document how you would move a workload between serverless, managed and self-hosted, so switching later is a deliberate choice rather than a panic.

On-screen

Narration

Anna: Three failure modes worth naming. The first is over-engineering early, building bespoke Kubernetes before anyone has confirmed there's demand for the product.
Greg: The second is forecasting spend without data transfer and egress costs. Moving data between regions or providers is where cloud bills surprise people.
Anna: And the third is assuming cloud means infinite scale, which it does, right up to your credit limit.
Greg: Auto-scaling without a ceiling is a way to convert a traffic spike, or a bug, into a very large invoice. Set budgets and limits deliberately.

On-screen

Narration

Anna: Managed services sit in the middle—they remove toil but still let you shape the environment.
Greg: That serverless approach we just mentioned? Managed platforms are the next step when you need more knobs without rebuilding plumbing.
Anna: Think managed Kubernetes, relational databases or desktop-as-a-service, all defined through infrastructure as code so the setup is reproducible.
Greg: Just remember: even if the provider handles hardware, your team still carries the pager for misconfigurations and app bugs.

On-screen

Narration

Anna: Containers promise cost control, but they demand engineering maturity.
Greg: Without observability, vulnerability scanning, hardened base images and a registry strategy, you're just moving risk from AWS into your unfinished build pipeline.
Anna: Treat the platform like a product—budget time for upgrades, policy automation and yes, the coffee-machine moment when you realise you built something no one can maintain.