Setting the file. One moment.
Skill 24 · Architect For Startups
Subchapter 24.15
references/iac-scaffold.mdMarkdown5 KBView on GitHub
| Stage | IaC Recommendation | Why |
|---|---|---|
| Pre-seed solo founder | Skip IaC. Console + CLI. | You’re iterating daily. IaC slows you down at this stage. Document what you clicked. |
| Pre-seed with 2+ engineers | Minimal IaC (CDK or Terraform for the main stack only) | Reproducibility matters when 2 people touch infra |
| Seed | IaC required for production resources | You need a second environment and can’t recreate from memory |
| Series A+ | Everything in IaC, no exceptions | Audit trail, repeatability, team onboarding |
| Factor | CDK (TypeScript) | Terraform | SAM |
|---|---|---|---|
| Startup default | ✅ If team writes TypeScript | ✅ If multi-cloud possible or team knows it | ✅ If pure serverless (Lambda + API GW) |
| Learning curve for web devs | Low (it’s TypeScript) | Medium (new DSL) | Low (YAML + familiar) |
| Footgun risk | Medium (generates complex CFN) | Low (explicit) | Low (simple scope) |
| Operational overhead | Low (CDK CLI) | Medium (state management) | Lowest |
| When to switch away | Never needed for most startups | If going all-in AWS (CDK advantage) | When you add non-serverless resources |
Opinionated startup default:
sam local)| Anti-Pattern | Why It Hurts | Do This Instead |
|---|---|---|
| Separate repo for IaC | Context switching, drift between app and infra | Monorepo: /infra next to /src |
| One stack per resource | Deployment takes forever, circular dependencies | One stack per LIFECYCLE (stateful data, stateless compute, networking) |
| Custom constructs/modules before needed | Abstraction without understanding = debugging nightmare | Use L2 constructs (CDK) or official modules (Terraform). Write custom only on third use. |
| IaC for developer sandboxes | Over-engineering for ephemeral environments | cdk deploy --context env=dev with cheaper defaults, or just use console for scratch |
| Parameterizing everything | 50 parameters nobody understands | Hardcode sensible defaults. Parameterize only what CHANGES between environments |
stack-1: foundation (VPC if needed, DNS zone, shared secrets)
→ Deploys once, changes rarely
→ Even for pre-seed: just DNS zone + maybe a VPC
stack-2: data (databases, S3 buckets, DynamoDB tables)
→ Deploys rarely, NEVER destroyed (data loss)
→ Enable deletion protection on everything here
stack-3: compute (Lambda functions, ECS services, API Gateway)
→ Deploys frequently (every PR merge)
→ Safe to destroy and recreateKey rule: Never put databases and compute in the same stack. A botched compute deploy should never risk your data.
If you’re scaffolding for the first time, include ONLY:
Makefile with: deploy, destroy, diff, logsdev and prod (not staging, qa, perf, etc.)Skip until needed:
aws-actions/configure-aws-credentials — simple YAML)