I have a love-hate relationship with cloud computing. Let me start by making something clear: I’m not anti-cloud. AWS is actually my default cloud provider. I use Route 53, I’ve built plenty of things using AWS, and I’m not against Azure, GCP, Oracle Cloud, or any of the alternatives either.
AWS is simply what I’ve encountered most throughout my career, so using it also has professional value. If I’m going to get asked about AWS during interviews or encounter it at work, there’s value in knowing the ecosystem. AWS also has some incredible technology.
My issue isn’t really with the cloud itself. It’s with the assumption that putting something in the cloud automatically makes it the right architecture.
I think developers, especially people building side projects, sometimes start paying for scale long before they actually have something that needs to scale.
The Cloud Is Still Somebody Else’s Computer
We sometimes talk about “the cloud” as though compute itself has fundamentally changed. It hasn’t. Somewhere there is still a CPU, RAM, storage, and networking. Your database ultimately lives on storage somewhere. Your application executes on processors somewhere. Your files occupy disks somewhere.
The cloud gives us an incredible abstraction over those resources. What you’re really buying is convenience, elasticity, geographic distribution, managed services, redundancy, APIs, automation, and the ability to scale infrastructure without buying and installing another physical server yourself.
Those things are extremely valuable. There are workloads where I absolutely want them. There are companies where trying to reproduce those capabilities yourself would be ridiculous.
But they aren’t free.
Sometimes I think we pay for capabilities that solve problems we don’t actually have yet.
Get the Users First
This has increasingly become my philosophy for personal projects: Get the users first. Pay for scale second.
I’ve built a lot of projects. Some become things I use regularly. Some become public passion projects. Some sit there for months. Some eventually get abandoned. That’s normal, especially when you’re someone who likes building things and experimenting with new ideas.
But there’s something slightly ridiculous about paying every month for production-grade cloud infrastructure supporting an application with approximately zero users.
I’ve done versions of this myself. You build something and immediately think, “Well, if I’m going to deploy it, I should deploy it correctly.” Now you need application hosting, a managed database, storage, networking, logging, monitoring, secrets management, backups, security services, and maybe redundancy.
Then maybe Kubernetes gets involved because apparently our side project serving six HTTP requests this month requires a highly available container orchestration platform.
Suddenly your architecture is beautiful.
Your bill is also beautiful.
And nobody is using the application.
Self-Hosting Changed My Perspective
This is one reason self-hosting has developed a special place in my development workflow. Once you own the hardware, the economics become very different.
I already have servers. I already have storage. I already have networking. I already have compute. Ignoring the initial hardware investment, the incremental cost of putting another small project on infrastructure I’m already operating can be extremely low.
Of course, it isn’t actually free. I’m paying for electricity. Hardware eventually fails. Drives need replacing. I have to maintain the systems. I’m responsible for backups, updates, networking, and all the other boring things a cloud provider normally helps abstract away.
There is also a legitimate security conversation here. Hosting public services from your home introduces risk.
I’m not going to pretend otherwise. You need to think about isolation, authentication, network segmentation, patching, exposure, backups, monitoring, and what happens if something gets compromised. But those are risks that can be managed.
For the right project, I increasingly prefer this progression:
Idea → Self-host → Find users → Identify scaling problems → Move what needs to move
IDEA
│
▼
SELF-HOST
│
▼
DOES ANYBODY ACTUALLY USE THIS?
│
├──── NO ────► Keep experimenting cheaply
│
└──── YES
│
▼
Is infrastructure
becoming a problem?
│
└──── YES ────► Start moving appropriate
pieces into the cloud
That’s almost the opposite of how we’re sometimes taught to design systems. And for personal projects, I think that’s okay.
Your Database Doesn’t Need Infinite Scale on Day One
Databases are a great example. If I’m building some experimental application that has five users, or zero users, do I really need to architect the database around what happens if I suddenly have five million? Probably not. I can host a database myself.
If the project starts attracting users, that’s a fantastic problem. At that point I can start thinking about migration. Maybe I move the database to a managed cloud database. Maybe I move storage. Maybe compute moves. Maybe only certain workloads move.
The architecture can evolve with the application. That’s an important distinction:
Starting self-hosted doesn’t mean staying self-hosted forever.
Likewise, starting in AWS doesn’t mean every component needs to remain there forever. Infrastructure isn’t a marriage.
The Funny Thing About Architecture Interviews
There’s another part of cloud computing that I’ve always found amusing. We conduct system-design interviews where we’ll spend considerable time discussing the “correct” cloud architecture. Use this managed service. Put this here. Deploy that there. Use EKS for this workload. Design around multiple availability zones. Add these security controls. Follow AWS’s Well-Architected Framework.
And then you join a large company and discover that huge parts of the infrastructure don’t look anything like the architecture you just described during the interview. There are good reasons for that. The first is history. Some large companies built their infrastructure before many of today’s managed services even existed. You can’t redesign ten years of infrastructure every time AWS launches something new.
But there’s another extremely important reason: Cost.
Best Practice Has a Budget
AWS has a lot of excellent guidance. The Well-Architected Framework exists for good reasons. Security matters. Reliability matters. Operational excellence matters. Performance matters. Cost optimization matters. Sustainability matters.
But architecture doesn’t exist independently of economics. You can absolutely construct an incredibly resilient, observable, secure, highly available architecture. And AWS will happily send you the bill for it.
That’s why I think there’s an important distinction between industry best practice and best practice for this organization, at this scale, with this risk profile and this budget. Those aren’t always the same thing.
A company choosing not to use a particular managed service doesn’t automatically mean its engineers don’t understand cloud architecture. Maybe they evaluated it. Maybe the existing infrastructure works. Maybe migration risk is too high. Maybe the managed service doesn’t fit their workload. Or maybe the economics simply don’t make sense. That’s architecture too.
Now Multiply Everything by 50
This becomes especially interesting for people like me who build lots of things. Imagine I have 50 experimental projects. If I decide every one deserves its own elaborate production-style cloud environment before it has users, the economics can become absurd.
Let’s deliberately use an aggressive illustrative example. Suppose I somehow average $500 to $1,000 per project per month once I include the architecture and services I’ve decided each application “should” have. At the upper end, 50 × $1,000 = $50,000/month. That’s $600,000/year. Two years gets you to roughly $1.2 million.
And what did I purchase? Infrastructure for fifty experiments. Maybe five become useful. Maybe two attract users. Maybe one eventually becomes a real business. Maybe none do. Meanwhile, I could have bought an almost comically overpowered home lab for a fraction of that money.
Again, I’m not saying AWS costs $1,000 per project. It doesn’t have to. You can run tiny workloads extremely cheaply. The thought experiment is about something different:
What happens when you prematurely give every experiment the architecture of a successful product?
At sufficient scale, architecture becomes economics.
The Cloud Should Solve a Problem You Actually Have
That’s where I’ve landed. Don’t use cloud infrastructure because you’re “supposed to.” Use it because it solves a problem.
Maybe you need elasticity. Maybe you need global distribution. Maybe your availability requirements exceed what you can reasonably provide yourself. Maybe you have enough users that managing your own database has become operationally stupid. Maybe your team has grown and centralized infrastructure is necessary. Maybe compliance requirements change the equation. Maybe downtime now costs more than infrastructure.
Maybe you’re an enterprise with hundreds or thousands of engineers and letting everyone deploy workloads underneath someone’s desk obviously isn’t going to work. Great. Use the cloud. That’s exactly what it’s good at.
But if you’re one developer with 50 ideas and 48 of them don’t have users yet? Maybe don’t build infrastructure for the imaginary million users. Build for the users you actually have. Then earn your scaling problems.
There Will Always Be a Place for Self-Hosting
I don’t think the future is cloud versus self-hosted. It’s both. Some things belong in AWS. Some things belong on my Unraid server. Some things belong on my MacBook. Some things probably start in my house and eventually move into AWS. And some things may start in AWS and eventually make more economic sense somewhere else.
The important part is being intentional about it. My philosophy has increasingly become:
Use the cloud when the cloud is solving a real problem. Don’t pay for hypothetical scale just because someday you might need it.
Get the users. Find the bottlenecks. Understand the workload. Then spend the money. Because there’s nothing particularly impressive about building infrastructure capable of serving ten million users when your application’s current user count is zero.
Sometimes the best architecture isn’t the architecture that scales the furthest. It’s the architecture that lets you afford to keep experimenting long enough to build something worth scaling.