Container platform decisions

Introduction

For a POC, the decision between Azure Container Apps and AKS does not have to be final. The important thing is to get the product running in a way that teaches the right habits: build an image, deploy it repeatably and avoid configuring servers by hand.

Knowledge scope

This is common CTO knowledge. It applies beyond the startup journey, but the public playbook places it where it usually becomes important for an early-stage company.

Why it matters

Platform decisions become expensive when complexity creeps in unnoticed. A simple container route is often right early, but multiple services, scheduled jobs, deployment coordination and networking requirements can eventually make a stronger platform model worthwhile.

How it fits the playbook

This reference supports the Company Ready -> POC Started stage of the startup CTO playbook. It gives the public context for the decision without exposing the deeper assessment method behind the agentic operating model.

Design considerations

• Keep the SPA frontend separate and simple, commonly served by nginx or equivalent static hosting.
• Use a single backend container shape where possible, with commands or entrypoints for different worker roles.
• Delay AKS until orchestration complexity, deployment coordination or operational control justifies it.
• Capture the point where Container Apps stops being simpler than a managed Kubernetes approach.
• Make platform decisions explicit before Production promises depend on them.

What good looks like

The company can explain why the current container platform is simple enough for today and what signals would justify moving to a more capable platform.