Should you choose the cloud for your infrastructure?
In startups, the question doesn't even come up anymore: you go with AWS, GCP or Azure from day one. The cloud has become a doctrine, a reflex. But after 15+ years designing architectures — from two-euro VPS to multi-region serverless — I've learned one thing: the best infrastructure choice is the one that matches your stage. Not the one that looks impressive on an architecture diagram.
The cloud, a startup doctrine
Today, suggesting a deployment on a simple server in a technical interview is almost suspicious. The cloud has become the default choice — sometimes before you even have a first user. The reasons are understandable: it's what's taught, it's what investors understand, and cloud providers have relentless marketing. AWS alone offers over 200 services. The problem is that this reflex short-circuits actual thinking. You stop asking 'what do I need?' and start asking 'which AWS service handles this?'. And you end up with architectures that solve problems you don't have yet.
The real advantages of the cloud
Let's be honest: the cloud has undeniable strengths. On-demand scalability is real — when your traffic jumps from 100 to 100,000 requests per minute, you don't want to manage that manually. Managed services (databases, message queues, CDN) save you weeks of setup and maintenance. Multi-region high availability is nearly impossible to replicate on your own. And for certain use cases — from machine learning to big data to serverless — the cloud is simply unmatched. I'm not anti-cloud. I've architected entire systems on AWS and GCP, and I still do. But I refuse to believe it's the only valid answer.
The vendor lock-in and cost trap
The first trap is silent: vendor lock-in. You use Lambda, DynamoDB, SQS, Cognito, and before you know it, every component of your stack is proprietary. Migrating to another provider? That's a multi-month project. The second trap is financial. Early on, free credits and free tiers mask the reality. But as traffic grows, the bill follows an exponential curve. Just open the pricing page of a single AWS service and you'll understand: between tiers, thresholds, per-request costs, per-GB transfer fees, per-million invocations — very few people can tell you precisely what you'll pay at the end of the month. I've seen early-stage startups spending 3,000 to 5,000 euros per month on AWS for workloads that would run on a dedicated server at 50 euros. The third trap is complexity. Every added service is a service to monitor, secure and understand. The attack surface grows, so does technical debt, and onboarding new developers becomes an obstacle course.
The pragmatic alternative: start simple
For the majority of early-stage projects, the reality is simpler than you think. A Docker Compose on a Hetzner VPS at 20 euros per month can run an API, a PostgreSQL database, a Redis instance and a worker — with performance that's more than enough for your first few thousand users. It's boring, and that's exactly the point. No network latency between services, no cold starts, no billing surprises. Deployment fits in a 20-line script. Monitoring is a docker stats and a few alerts. When the project grows and real needs emerge — horizontal scaling, high availability, specialized services — then you migrate. But you migrate with concrete knowledge of your needs, not with assumptions.
My approach: surgical cloud
My philosophy is surgical cloud: use the cloud for what it objectively does best, and keep the rest simple. In practice, that means: object storage (S3) for files and assets — unbeatable in cost and reliability. A CDN (CloudFront, Cloudflare) for global static distribution. Targeted managed services — SES for transactional email, CloudWatch for monitoring, an authentication service when the need is real. But compute, database, cache? As long as the project doesn't justify cloud complexity, a well-configured server does the job. The idea isn't to reject the cloud — it's to choose service by service instead of going all-in. And when a project reaches the scale that warrants serverless or Kubernetes, I'm the first to recommend it. If you're unsure about your infrastructure strategy or want an outside perspective on your cloud architecture, let's talk.