Early-stage teams routinely over-build their cloud. They stand up Kubernetes for an app three people use, wire up six environments, and spend the first quarter on infrastructure instead of customers. As an Azure-focused studio, we push clients the other way: start lean, stay observable, and only add complexity when a real constraint forces it.
The baseline we actually deploy
- Container-based compute (App Service or a single VM/VMSS) — not Kubernetes — until scale genuinely demands orchestration.
- Key Vault for every secret, injected at deploy time. Nothing sensitive in the repo, ever.
- Managed database with automated backups, so a bad migration is recoverable in minutes.
- Application Insights from day one — you cannot fix what you cannot see.
- One infrastructure-as-code definition, so the environment is reproducible and reviewable.
Secrets belong in Key Vault, full stop
The most common security problem we inherit is not a sophisticated attack — it is an API key committed to a repo two years ago. Put every secret in Key Vault, reference it at build or runtime, and rotate on a schedule. This one discipline eliminates an entire category of incident.
Observability is not optional
When something breaks in production — and it will — the difference between a five-minute fix and a five-hour outage is whether you have traces, logs, and metrics already flowing. App Insights costs almost nothing at low volume and pays for itself the first time you can point at the exact failing request.
Add complexity on evidence, not anticipation
Autoscaling, multi-region, read replicas, a service mesh — every one of these is the right call eventually and the wrong call too early. Wait for a metric to tell you it is time: p95 latency creeping up, a region with real users, a database pegged at capacity. Anticipatory complexity is just cost and surface area you pay for before you need it.