This chapter synthesizes everything into actionable decision-making tools. When you get a new project, use these frameworks to systematically choose the right architecture and hosting.
The Decision Flowchart
┌─────────────────────────┐
│ New Website Project │
└────────────┬────────────┘
│
┌────────────▼────────────┐
│ Does it need a backend? │
└────────────┬────────────┘
│ │
NO YES
│ │
▼ ▼
┌────────────┐ ┌──────────────────┐
│Static Host │ │ How many users? │
│(CDN/Netlify│ └────────┬─────────┘
│ CloudFlare)│ │ │ │
└────────────┘ <1000 1K-100K >100K
│ │ │
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌──────────┐
│Single │ │VPS or │ │Cloud IaaS│
│VPS or │ │PaaS │ │or K8s │
│PaaS │ │ │ │ │
└───┬────┘ └───┬────┘ └────┬─────┘
│ │ │
┌─────────────▼──────────▼───────────▼──────────┐
│ What's your budget? │
└─────────────┬──────────┬───────────┬──────────┘
Minimal Medium Large
│ │ │
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌──────────┐
│Hetzner │ │DO/AWS │ │AWS/GCP │
│VPS + │ │+ managed│ │full stack│
│Docker │ │services│ │+ support │
└────────┘ └────────┘ └──────────┘
Scoring Matrix
Rate each factor 1-5 for your project, then match to the hosting type that scores highest:
Factor
Static
VPS
PaaS
IaaS
K8s
Serverless
Low budget priority
5
4
3
2
1
4
Need auto-scaling
5
1
3
5
5
5
Minimal ops work
5
2
5
2
1
5
Maximum control
1
5
1
4
4
1
Fast time-to-market
5
3
5
2
1
4
Compliance needs
2
4
2
5
5
3
Team > 5 devs
3
2
3
4
5
3
Variable traffic
5
1
3
4
4
5
Migration Paths
Typical growth path:
PaaS (Railway/Render) ──────────────────────────────────────────────▶ Time
│ │
│ "We're paying $200/mo for what a $40 VPS could do" │
▼ │
VPS + Docker Compose ───────────────────────────────────────────────▶ │
│ │
│ "We need auto-scaling, multiple services, zero-downtime deploys" │
▼ │
Cloud IaaS (AWS/GCP) + Containers ──────────────────────────────────▶ │
│ │
│ "We have 10+ services, 5+ teams, complex networking" │
▼ │
Managed Kubernetes ─────────────────────────────────────────────────▶ │
▼
Key Decision Questions
Ask these for every project:
1. What's the expected traffic? (requests/sec, concurrent users)
2. What's the budget? (monthly hosting budget, one-time setup budget)
3. What's the team size? (who maintains this after launch?)
4. What's the SLA requirement? (99.9%? 99.99%? "best effort"?)
5. Are there compliance requirements? (GDPR, HIPAA, PCI-DSS, data residency)
6. How variable is the traffic? (steady vs. spiky vs. seasonal)
7. What's the time-to-market pressure? (launch in a week vs. 6 months)
8. What's the data sensitivity? (public content vs. financial/health data)
9. Do you need specific geographic presence? (latency requirements, legal)
10. What's the expected growth? (10x in a year? Stable? Unknown?)
Anti-Patterns to Avoid
Premature Kubernetes: Using K8s for a single service with 100 users. Use a VPS.
Premature microservices: Splitting a monolith before you understand the domain boundaries.
Over-engineering for scale: Building for 1M users when you have 100. Optimize when you have data.
Ignoring managed services: Running your own PostgreSQL/Redis/Elasticsearch when managed versions exist and your time is expensive.
Vendor lock-in without awareness: Using proprietary services is fine — just know the exit cost.
No staging environment: Testing in production is not a strategy.
Manual deployments: If deploying requires SSH and running commands, you'll eventually make a mistake at 2 AM.